Creating a High-Fidelity Prototype

My prototype screens

In my last post, I created a low-fidelity paper prototype of the app I am working on by the name Town of Randolph. In this post, I am presenting you with a much better high-fidelity prototype of the app. There are many changes to the prototype I first created. 

With the user testing being done in the low-fidelity prototype, I’ve had numerous comments on what needed to be changed and better ways to design the app for users to use. Last week’s low-fidelity prototype included 20 screens but this week includes 25+ screens to view and look at. 

Before we get into my project, I want to remind you of what a high-fidelity prototype is. According to Mockplus a high-fidelity prototype: 

“provides more visual details; it is almost equivalent to a UI effect picture, and only needs to replace the actual data and materials in the development process” (Mockplus). 

A low-fidelity prototype: 

“focuses on functions, structures and processes; it only provides the most simple frameworks and elements; it generally does not provide color” (Mockplus). 

Making a low-fidelity prototype helped me create the high-fidelity prototype in many ways. For one, it helped me organize where I wanted to place buttons and widgets on the high-fidelity app. Second, it helped me in a way come up with the colors for the app. The tool that I used to create my high-fidelity prototype was Adobe XD. This application is fairly easy to use and get used to. 

Changes

While designing the high-fidelity prototype I made a lot of changes from the low-fidelity. When you take a look at the homepages from both high and low fidelity there is a difference. In the high-fidelity prototype, there is more color and a status bar. I also made a slight mistake in naming the high fidelity app “Town of Randolph” instead of “All About Randolph”. I used the color blue in both fidelities.

Another change I made to the app was the navigation bar at the bottom of the screen. In the low-fidelity prototype, there wasn’t much of a navigation bar to click and get around to. I thought that users viewing the app would want to see a navigation bar at the bottom that allowed them to see notifications and etc. 

A major change that I made to the app was I added a new section for newcomers to the town of Randolph. This was a suggestion from one of the participants in the user study. The participant thought it would have been beneficial to add a newcomer’s section to the app so the new residents can view and look at the town information. I did decide to eliminate a screen called “Document Center” because I felt as though it didn’t fit in an app. The participants from the user study also mentioned that some of the app links and sections didn’t really make sense. This prompted me to remove the section. Along with this, I took parts of the sections out from the Home screen and the Resident’s screen. 

High-Fidelity Screen

While creating the high-fidelity screen I made many more screens so users in a test will feel as though it is the real app. The new screens I included were the Login, Newcomers, Police Station, Where To Vote, Notifications, Contact, Search, and Events This Month pages. Creating the high-fidelity pages was easy to make due to the repetitiveness of the buttons and widgets. When trying to build the prototype in Adobe XD I had to copy a few of the pages so that I can link pages back to them. This is because I had some screens that had the same information on the screen as the next. Though it was rare in my prototype the screens that had copies were Farmers Market, Parks and Recreations, and Where to Vote. I found out I needed copy screens because when I linked the back button to the previous screen it wouldn’t go to the screen I wanted it to. I am not sure if Adobe has a rule for certain screens but that would have been helpful so I didn’t have to make a copy of the original screen.

Though it has taken me a while to create my screens I am happy with the outcome. The app works like it is supposed to when I click on different options. Some of the information on the prototype isn’t a working feature due to time and how much I could make in a short amount of time. Here is a video down below of the walkthrough of my app.

Prototype Walkthrough

User Testing on Paper Prototype App

Image from Here

User testing is an important step in completing a product you are working on. Without user testing, you wouldn’t know what you need to fix or change in order to have a successful end product to users. 

Usability happens during the design process. What exactly is a design process, you might wonder? Well, a design process consists of 5 steps. These five steps are: 

Research 

Design 

Prototype – Usability Test

Build 

Test – Usability Test 

There are two steps in the design process that you will complete user tests for. These steps are the prototype phase and the testing phase. The phase I am in for this project is the prototyping phase. 

Creating a prototype can be either a high-fidelity prototype or a low-fidelity prototype. Low-fidelity prototypes are often paper-based and usually do not allow user interactions. (But, in this prototype I created it does.) High-fidelity prototyping is usually computer-based and is more realistic for users to use. 

According to Christopher Murphy from Smashing Magazine running a usability test will help you: 

• Identify if users are able to complete specific tasks successfully 
• Establish how efficiently users can undertake predetermined tasks
• Pinpoint changes to the design that might need to be made to address any shortcomings to improve performance 

I created a low-fidelity prototype on paper for my users to test. The difference was that I used the application Marvel to upload the screens and make them interactive. This made my testing session much more of a high-fidelity testing than just a paper prototype. The Marvel application allows you to upload paper prototypes to the site and make them interactive. Sharing is available so you can have users test out the app you have created. If you are creating a low-fidelity prototype I would suggest using this software as it works as an actual app. 

Before I started my user test I needed to come up with a few tasks for my users to do when they tested the app. I came up with three tasks for my users which were: 

• Task 1: You have been driving over a big pothole near your home and you want to report it so it can be fixed. 
• Task 2: You just moved to the town of Randolph with your two kids and want to know about its different parks and where they are located 
• Task 3: You want to find out about the local farmers market in your town to get some fresh vegetables. 

Giving the users tasks to complete while they are going through the app allows for you to watch users and what they do. The Nielsen Norman Group also states that giving tasks lets you “gain qualitative insights into what is causing users to have trouble” (nngroup). Engaging with the app will allow me to see what I can fix and what might need to be clearer for users to click into and use. 

Along with my user testing, I made a professional script to read to the users taking my test. With the script, I made sure to get verbal consent to record and use the video for my data. Due to unforeseen circumstances, COVID-19 prevented me from doing user testing on more people than I wanted. My user testing was done over the application Zoom where I screen recorded two participants for my test. 

As for the results of the test I had interesting feedback from the two participants. I realized it took both of them a while to find some of the information from the tasks I gave them. Participant 1, Lily, had a hard time distinguishing between the Home page and the hamburger menu. She didn’t quite know that there were many different options to click into when she first began. She thought she could navigate everything from the homepage. This prompts me to maybe look into this and possibly change the name from Home to another name so it doesn’t confuse the user. 

Participant 2, Amy, took a while to find out where the Farmers Market was located. She suggested that Farmers Market be on the Town News page and that not be located under home and family. 

Doing a user test can be very helpful as it is was to me. I got interesting feedback on how to better the app for users to navigate through it and find what they are looking for. To see my full report, video of user tests, and PDF of the user test click HERE to view. Thanks for reading!  

How To Make A Low-Fidelity Prototype App

Low-fidelity prototyping is one of the best ways of getting closer to an actual design. There are three different types of low-fidelity prototyping. One of them is sketching/ paper prototyping, digital prototyping, and native prototyping. The prototype I will be using for this project today is a sketching/ paper prototype. During this class, I have been working on an app for a town municipal site by the name of Town of Randolph. I have recently made a mock flowchart and named the town app “All About Randolph”.

According to Ben Coleman, author of How To Make Paper Prototypes, all you need is common office or home supplies to get started on your prototype. Coleman gave a list of supplies needed for a low-fidelity prototype which I will list down below:

• Paper with a grid or dot grid (preferred)
• Sticky notes (never leave home without them)
• Pencils
• Eraser
• Pens (Sharpies in different colors and thickness are ideal)
• Scissors or craft knife
• Glue (preferably re-stickable)

Coleman also gave a list of items that might be great to have in the house while completing your prototype.

• Index cards
• Mountain putty
• Adhesive tape (preferably removable to move items around)
• Highlighter pens
• Double-ended marker pens with fine and normal nibs
• Transparent sheets and markers
• A box for filing or transporting your prototype

When creating a prototype, you can create one for any screen size you want like an iPhone, computer, tablet, and much more. In my particular prototype, I created screens for an iPhone because I am used to looking at iPhone screens.

Many people may ask, why prototyping? Well, you wouldn’t want to turn in a big term paper without a rough draft first. This is similar to making an app. You wouldn’t want to jump right into creating an app without a mock app first. This may cause problems.

Authors of the blog post The Art of UX Sketching and Paper Prototyping state that you can come back to your prototype and do quick fixes to the designs you have recently created. The authors of this blog post listed a few reasons why paper sketches are great. Here is this list:

• Designer/ product manager is thinking through all the initial ideas running through his head
• Outline the steps in a user flow
• Explore and validate a variety of layouts
• To show the basic app structure

When creating your prototype, you want to be sure the viewers understand where they can click and go into a certain section of the app. You can do this by having a common color throughout the prototype and labeling what it means. In my prototype, I used a purple arrow to represent where the users can click and navigate into another page. Click HERE to see the low-fidelity app I created for All About Randolph.

While creating this app it took a while to come up with how I wanted to present the material on screen. The quickest and easiest screens I created was the main navigation pages for the app. This consists of the pages Home, Residents, Town News, Calendar, and Report. These main navigation pages are also what are in the hamburger menu at the top of each page so that the user can quickly get to them.

At the footer of each page I created, I made sure to put the Facebook and Twitter app logo at the bottom and the actual site page for the user to visit. The reason I put the actual, non-app site at the bottom is that some of the links on this app are not represented as it may not go well with the app. Users can go to the website for further information.

For some of the app screens like Pay Bills, I used a different navigation layout other than the block touch in screens like Report and Local Government. Because this is a low-fidelity prototype I am creating I will most likely go back in and change the screens to one or the other touch options, possibly the block form as it is easier for users to click. In the screens I made, I placed a purple arrow over the sections that users can click and interact with.

The app I created is a simple app for users to use but may need some adjustments if it were to go into a final stage for user testing. Most of the navigation I created for the users to get around in the app is due to creating a better user experience for the user. Making the screens readable and big enough is one of the goals of making a great app. Click HERE to see the PDF of the app screens I created.

Creating User Flowcharts

Flowcharts can be very helpful to view steps and processes for whatever you are doing. Liza Mock author of The Comprehensive Guide Process Flow Diagrams & Process states that you can use “process flow diagrams to solve problems, manage data, lay out programming and much more” (Mock). In this assignment that I completed, I was to make user flowcharts for an app I created for the Town of Randolph’s original website.

The mock app I created for this website is named All About Randolph. I decided to name the app All About Randolph because it is an app for town residents. In this project, I created three user stories, three user scenarios, and three flowcharts representing the steps they take to get to a certain section of the app.

A user story is a short and brief description of their need. While it doesn’t get every detail of the user their story is to give you an understanding of what the user is trying to accomplish. As an example, one of my user stories comes from the user Mark. This is his story. “I recently came across a pothole in front of my house and I always run over it. I want to report this pothole so it can be fixed.” This is a brief description that I gave to the audience. We know exactly what the user needs which is a pothole needing to be fixed. Another example is my user Ann. Her story goes like this. “I recently moved to the city of Randolph and want to know about the town’s current news.” Again, we understand what she wants from this brief description.

The next task to complete was a user scenario for each of the users I created for this app. A user scenario is a more detailed and more informative description of the user but still has only relevant information. This is where you want to explain the primary goal for the user visiting the site. For Mark, his user scenario goes:

“Mark is a longtime resident of Randolph, MA. He works Mon-Fri, 9-5 pm in the city of Boston. Every day Mark takes the same route to and from work. He usually comes across multiple potholes on his route but there is one pothole that Mark doesn’t like. The pothole that he doesn’t like is right outside of his house and he tries to avoid it every time he comes home but manages to hit it every time. As the day goes by the hole gets bigger and Mark gets more frustrated. Being able to drive down his street without hitting the pothole is ideal to Mark.”

To give you another example Ann’s story is:

“Ann recently moved from New York to Randolph, MA due to a job change. She chose the city of Randolph to live in because it was a bit cheaper than the city. Coming from a suburban neighborhood in New York Ann wants to know about the towns current news that is going on. Ann has three young children and a husband who she wants to see thrive in the community. Knowing the towns current news is one of her main priorities for her and her family.”

After creating these scenarios and user stories, I created a flowchart for each user as to how they will navigate through the site to find what it is they need. I will explain Mark’s flowchart. Mark wants to report a pothole that he notices every day. There is a section in the app where residents can submit for a pothole. Through the flowchart, I charted his steps as to how he will reach his need in the app. To get a better idea of the flowchart click HERE to see the full PDF version. I will list out his steps for you.

• Start
• Opens App
• View Homepage
• Select Reports
• Pothole Page
• Report the Pothole
• End

This was a simple flowchart where Mark’s need was met. Creating flowcharts, specifically Marks, lets viewers know the steps user can expect to get to a specific location on an app.

Ann’s flowchart is a bit different than Mark’s. Here is how Ann’s flowchart looks.

• Start
• Opens App
• View Homepage
• Select Town News
• Select Article
o Yes
o Read Article
• Share Article
o Yes
o No
• End
Ann’s flowchart has a couple of decisions in her actions to look at her town news. She can select any article she wants. But, she doesn’t have to share it if she doesn’t want to. Whichever decision she chooses to share it or not she completed her task.

Flowcharts are a great way to understand what your users go through when they are on an app or even if the tasks aren’t done on an app. To view my full PDF version of the assignment click HERE.

App Sitemap

In my last blog post, I have made two sitemaps for a town’s site. The town’s site I worked on was the Town of Randolph. For this new project, I was tasked to create an app sitemap. Though this site doesn’t have an app I created a sitemap for it. As I have done for the two sitemaps previously, I have created an information architecture for the app. If you forgot what information architecture is it is according to Nick Babich “all about the organization of information in a clear and logical way” (Babich).

Creating apps that originate from a website can be a bit tricky for some to do. In my app sitemap, I decided to leave some information out of the app. This is because some information is not needed and requires to be done on a website instead.

Down below is the sitemap for the Town of Randolph website that I created.

App Sitemap

If you look at the proposed website sitemap for this site and compare it to the app sitemap I created you can see a difference in what information I decided to place on the app sitemap. There are fewer links in the new app sitemap. My vision for the site is to have a side navigation bar where the information is listed for visitors to click.

In this app sitemap, I kept some information the same. The home tab on the sitemap is what I decided to keep the same. A small change was made to take out the “Reports” section and add this to a new section to the tab pull-down list. Visitors on the app can easily navigate through the categories under the “Home” tab. The next tab I decided to keep for the new app was the “Residents” tab. If residents in the town needed to quickly look for something they can easily find the information under the tabs listed in this section.

Proposed Website Sitemap (compare)

A decision I made for the next two tabs “Town News” and “Calendar” was due to how much space they take up on a site. Because this is an app for phones and or tablets much more space is needed so viewers can view the calendar and news without it being straining on the eyes.

I decided to keep the report section for the app. If you are to think about it, many people would like to report potholes when they remember where they are. If they were to wait and submit the report when they get home they may forget just where it was.

The last section in the sitemap is the footer information at the bottom of the app. In the footer the only information I decided to place there were the social media accounts and the website link. This information is needed for visitors in the app to follow their social media and go to the website link if needed.

The app sitemap for the site Town of Randolph is a bit different from the website sitemap as the app sitemap doesn’t need as much information as the other.