Prototype

A prototype should answer a design question as efficiently as possible.

The questions asked of the SideWaze prototypes were descendants of the project’s research questions and were as follows:

  • How do sidewalk users want to contribute to the broader understanding of sidewalk condition? This workflow was tied to exceptional moments and specific locations: Can I quickly and easily report a situation that caused me frustration?
  • How do sidewalk users consider sidewalk condition information in their lives? This workflow was more preparatory than emergent: How can I accomplish my travel goals efficiently, pulling information from potentially multiple sources?

Fidelity and medium

While paper prototyping was considered useful (with qualification), its use was deferred until the evaluative phases of the limited interactivity digital prototypes. The decision to use a limited interactivity digital prototype was made as it represented a balance of resources, fidelity, aesthetics, and flexibility for quick iterations going forward. The prototype presents the ability to perform all primary goals identified.

The prototype will not be suitable for use outside of a controlled test environment; not only will much of the interface not support actual data being entered, no backend systems will exist to receive and share that data.

Architecture

The prototype adopted a platform agnostic visual design style. In particular, the smartphone app prototype was not intended to look like either an Android or an iOS app. Given prototype testing was likely to span users of both major platforms, this was a straightforward design decision.

Task support

The smartphone prototype supports the following tasks:

  • Learning about the app and its capabilities.
  • Categorizing and describing the sidewalk condition.
  • Providing a photo of the sidewalk.
  • Associating a location.
  • Timestamping the report.
  • Describing the impact.
  • Reviewing the report summary.
  • Submitting the report.
  • Confirming the report submission.
  • Looking at a map of sidewalk issues.
  • Viewing public transit information on a map.
  • Viewing information about a specific sidewalk issue.

Prototype limitations

The prototype has several limitations, including:

  • Representative mock map data is used. The prototype uses static images for map representations and, as such, there is no interactivity beyond that described for toggling transit data or simulating drilling down for more information about an issue on the map). The use of maps is a common pattern and users will almost certainly be able to imagine how the interactions will work without spending the time to add such functionality to the prototype.
  • Representative mock images and videos are used. The prototype does not pull images or video from the device. When taking a photo, the view is a static image. The goal with photo and video workflows for the prototype is merely to illustrate to the user that there would be additional steps to select or create media.
  • Geolocation is not active. The prototype does not use the user’s GPS or IP address to identify their location. As with the use of mock map data, this is a fairly common pattern within modern apps (both smartphone- and web-based), so it was deemed a low value investment for the prototype.
SideWaze app prototype main screen.
SideWaze app prototype main screen.
SideWaze app prototype screen showing the user a summary of their report just prior to submission.
SideWaze app prototype screen showing the user a summary of their report just prior to submission.
SideWaze app prototype screen showing the user a map with detail of a specific sidewalk condition issue.
SideWaze app prototype screen showing the user a map with detail of a specific sidewalk condition issue.

This page summarizes the following document:

M4 – SideWaze – Matthew ReynoldsDownload