Prototyping

Coverage

For our prototype, we decided to create a T prototype in order to equally depict the various features while also showing the application's functionality. Without creating a T prototype, we felt that our prototype would have lost uniqueness, resulting in a product that doesn't differ very much from the ones currently available on the market. Combining various features along with smooth functionality all in one place where users can plan and organize their trip is an essential part of the identity of StreetSmart.

Fidelity

Our primary goal for creating this app was to make traveling easier, safer, and more enjoyable for everyone. In order for us to achieve this, we knew right away that we had to create a prototype that was as close to the real thing as we could possibly create. We decided to make our prototype high-fidelity for a couple of reasons. First, using a high-fidelity prototype is a very good reference when it comes to seeing how designs and functions could potentially look or work. It made it a lot easier for us to go back and make improvements to our design when necessary. Second, a high-fidelity prototype is very inexpensive and a lot quicker to produce than a fully functional prototype. In addition, we ran into fewer problems when producing the prototype because the software was very easy to use, but was also able to keep a very accurate representation of how the application will actually function. Lastly, we wanted to ensure that our tests and evaluations were as accurate as possible. This would reduce the chances of the user losing interest due to not fully understanding or experiencing the different features that the app has to offer.

Interactivity

Functions that were fully interactive:

Initial Survey: When users first log into the application, they are presented with an initial survey. This survey in to learn about the user create personalized recommendations based on the answers they select. In this prototype, users are allowed to select different options that would accurately represent their interest. However, the answers are for visual representation and don't actually save. Completing the survey will then take the user to the home screen.
Home Tab Bar: After the users arrive at the home screen, they will see a tab bar at the very top with the labels Places, Map, and Journal. These tabs will navigate the user around the application to the different screens when they are clicked.
Settings: On the Places tab of the application, there is a settings button located in the middle right of the screen. Clicking this button will take the user to the settings page. However, for the purpose of this prototype, only the following buttons are interactive on the settings page:
- Frequently Asked Questions: Users can click on the Frequently Asked Questions (FAQs) button to take them to the FAQ page where they would be able to view the various reviews left by other users. However, this button is just for navigation in the prototype, which means that the FAQ page does not allow users to actually post reviews.
- Add a Location: Users can click on the Add a Location button to take them to the Add a Location page of the application. However, this button is just for navigation in the prototype, which means that the users are not actually able to post a location of a business for other users to view.
- Switch to Business: Allows users using the app as travelers to go back and switch to a Business account
Business Details: On the Places tab, businesses are displayed in a list-style view so users can easily and quickly see the name, hours, rating, location, and a photo of the business. When the business profile is clicked, it takes the user to the business details page where a more detailed description is shown about the business. On this page, users also have the ability to favorite a business by clicking on the star icon in the top left corner.
Search Bar (Maps Tab): When the user navigates to the Maps tab, they have the ability to click on the search bar at the top of the screen. Doing this provides the user with a search bar and a list of their recent searches. However, the user does not have the ability to actually perform a search within the application (just for visual purposes).
New/Edit/Share Post (Journal Tab): When the user navigates to the Journal tab, they have the ability to create, edit, and/or share a post that they have documented about their trip.
- Photos, Mic, and Journal Entry: When the user chooses to create or edit a journal entry, they are presented with the option to add a photo, an audio recording, or a journal entry to their documentation. Having these options ensure that the user can easily create and save every journey all in one place for easy access.

Functions that were visible, but not fully interactive:

Search Bar, Filter Button, and Scrolling (Places Tab): In the Places tab, there is a search bar located at the top that would allow users to search for different businesses or activities. The filter button (located on the middle left) would allow users to filter their results by different, enabling a more accurate search. On the bottom, there is a message telling the user to scroll down to see more search results in the list. All of these functions will serve a specific purpose in the final version of the application, but for now we felt that including these things wouldn't add to the experience of the user during evaluation.
Buttons in Settings
Explore and Settings Buttons (Maps Tab): The functions within the Maps tab, with the exception of the search bar, were too complicated to incorporate within the prototype in a timely manner. As a result, we decided to only show the basic key functions of the map for visual purposes. In addition, this also helped us reframe from overcomplicating the prototype.
Detailed Journal Features
- Share Post (partially interactive): On the main page of the Journal tab, users would have the ability to share their posts to another platform (messages, Instagram, Twitter, etc.).
- Calendar (not interactive): The calendar would allow the user to select a date for their journal entry.
- Text Boxes (not interactive): Within the journal, the user would be allowed to write a journal entry to save in their application.
- Save Button (partially interactive): Within the journal, the users can save their entries (the button doesn't actually save information in the prototype).
- Selecting Images (partially interactive): Users would be able to add photos to their journal entries (can't actually select photos in prototype, but can select add or delete).
- Recording Audio (partially interactive): Users would be able to add audio recordings to their journal entries (can't actually record audio in prototype, but can add or delete).
Business Account Details (Business Account / not interactive): On the business home page, users can add/view the details about their business.
User Reviews (Business Account / not interactive): On the business page, users can click on user reviews and see the reviews that customers have left about their business.

Tailored Scope

As a result of the way our app works, to show the proper functionality of multiple features like the specified recommendations based on survey answers, an interactive map feature, and being able to book restaurants using the app, it would require us to actually create algorithms and code the app. Additionally, the software we were using to create the prototype did not allow for text-input fields, meaning it had been possible for us to implement the journal feature to allow them to actually write content within the prototype due to Figma limitations.

Since the full functionality of many features of this app would not be possible to implement, we were forced to limit the interactivity of those features. That being the case, we decided to create a horizontal prototype since we are able to display all of the features, but many of these features have low functionality.

Process of Building Prototype

In creating the prototype, we already had a solid base for how the different screens lead into each other as a result of the wireframe from the previous part of the project. This allowed us to focus mainly on the design and interactivity when creating the prototype.

When designing the overall aesthetic and looks of the prototype the main thing we took into consideration was how the app will be used. During design studio, we received comments that the way some of the features are shown/labeled caused some confusion. There are a multitude of features like looking at locations, researching them, and writing journal entries and if users do not know what all of them do and how to access them, they can very easily become overwhelmed. Additionally, when using the app, users would want to quickly be able to switch between screens so they can efficiently find good travel locations as this is a main focus of the app. Because of these two things, we decided to go with a minimalistic design for our app. This would allow for easy, quick, and straightforward navigation which will allow for efficient use of the app. A minimalistic design also removes distractions and extra clutter which can minimize confusion among users and prevent them from being overwhelmed.

This also helped us decide on the color scheme for the app. We wanted the colors of the app to convey the same "straightforward" and "efficient" themes we were going for with the way we chose to design the app. The colors which our group believed conveyed that idea the best were black, white, and gray which is what we chose as the main colors of this app.

After we had these two things planned out, we started designing the prototype. Our software of choice was Figma as it allowed multiple people to simultaneously work on the prototype at the same time. We did however run into some problems with Figma. As described in the "Tailored Scope" section above, Figma did not allow for the implementation of some of the features we had in our app. This, along with other factors caused us to go with a horizontal prototype where we did not fully implement the functionality of many of our features. After fully fleshing out the first version of our prototype, we got together as a group and looked at ways it could be improved. After going through it, we realized that the part of our app meant for businesses was too integrated with the traveler part when it should be more separate from the rest of our app. We had previously overlooked this since our app is mainly for travelers and our clients themselves are travelers, so most of our thinking went toward that side of the app. After realizing this, as a group, we mapped out a separate section of the prototype that would be for the business side of the app and implemented it into our prototype. We then carefully reviewed the prototype again with each group member testing it themselves to make sure there were no more problems left.

Interactive Prototype

Link of Full Prototype:

https://www.figma.com/file/BgBvxKCOc0Vk0q5P80fety/StreetSmart-Wireframe?node-id=914%3A885&t=dUF98oQFAfd3WFLq-3

Interactive link (This one is used for testing the Prototype):

https://www.figma.com/proto/BgBvxKCOc0Vk0q5P80fety/StreetSmart-Wireframe?node-id=914%3A885&scaling=min-zoom&page-id=914%3A885&starting-point-node-id=1037%3A1817&show-proto-sidebar=1

If you become confused at any point, click on the whitespace or black space on the screen to see blue hotspots appear over clickable components on the screen.