Over the last 8 weeks in our Rapid Ideation and Problem Solving class we have been working on a redesign of Austin’s public transportation app which can be found in Apple & Android App stores under the name “CapMetro.” Each week we have created a new iteration of the application, performed user testing using paper prototypes, and presented a new iteration of the design to our class for critique. This week marks our “final” iteration. I’m using “final” in quotes because a valuable lesson learned from iteration, testing & critique is that there’s always room for improvement and always insights to gain from further testing.
Above is the latest version of my wireframes for the CapMetro application, broken into three flows:
- “When is my bus arriving?”
- “Planning a trip & Saving a location”
- and “Buying a pass.”
These flows are based on the concept map below:
Before I get into the findings from my final round of user testing, I want to give you a brief look at the process and the evolution of the designs over the past 8 weeks.
8 weeks ago, I started this project by navigating through every screen of the current Cap Metro application taking screenshots of every screen. I then printed out every screen, pinned them to the wall according to the app’s architecture and created a concept map of the entire system which can be seen below.
At this point, having a good understanding of the current application I created a new, revised concept map, taking out unnecessary and redundant features & interactions and started to sketch out a new design. My first sketches can be seen below:
After the first round of sketching, we presented our visuals to the class and had a formal critique of the designs. It’s funny to look back now and think about how uncomfortable everyone seemed sharing their opinions during our first formal critique and how uncomfortable it was to receive critical comments about our designs. It’s funny because critique has become such an integral part of our design process; We now share our opinions about each other’s work and solicit feedback to better our designs almost constantly. Without direct critique and feedback, my design would have progressed at a much slower rate. This has been a very valuable lesson; one that now seems obvious.
At this point, I took the opinions I received from my classmates and incorporated them into my design and put them into a digital format. My first digital iteration can be seen below:
The idea of wireframing is to create low-fidelity renderings of screens in order to map out the system flow. As you iterate and the system starts to take shape over, you can then increase the fidelity. The purpose of starting low fidelity, is that it allows you to get feedback specifically surrounding the structure and not the visuals. If you start with high fidelity, people will have a harder time focusing on the structure and will start to critique color and aesthetic choices that are irrelevant at the early stages of design creation.
From here, we incorporated user testing into our process. We tested our designs using paper prototypes making use of a method known as the Think Aloud Protocol. This process involves a test subject interacting with paper screens as they would with an actual device, and while they are interacting with the screens they are also saying out loud whatever they are thinking. This method gives the designer insight into what a person is thinking as they use the product. If the user were only to interact with the screens and not think aloud, we would be forced to guess why they performed certain actions. Having them speak aloud provides valuable insights you wouldn’t be able to garner otherwise.
We continued this process of iteration, testing and critique every week. Below are further iterations showing each week’s progress:
This week I tested Iteration 7 at a local bar with 5 individuals I have never met using the Think Aloud Protocol I discussed above. I had a number of insightful findings from this week’s tests. The first opportunity for improvement I found deals with the screens below:
On these screens, the user is adding their home address as a “favorite.” What I found through user testing, is that individuals thought it was odd that they entered the address as a favorite and then had to tap it a second time in order to actually proceed onto planning their trip. On my next iteration I would skip the second screen entirely and move onto planning a trip with the assumption that they typed it in because they want to go there (a safe assumption to make).
My second and third finding deals with the screen below:
I made the tasks more difficult this time around, forcing users to use previously unexplored areas of the app. I tasked the users with navigating to a destination, leaving at a later time, and saving that destination as a favorite. Everyone had an easy time navigating to the destination, and would make it to the screen above with no problem. However, most of the users skipped over the other two parts of the ask. Because they would reach the screen above and were left without any additional options, they felt lost. This showed me a few areas for improvement: This navigation screen should have both the exact time of departure and the option to change the departure time to a later time or date. This screen should also allow the user the option to save the destination as a favorite. Both of these actions are currently only available on earlier screens.
Moving forward I would want to further test the navigation features, and have the user go through an entire trip from start to finish as if they were actually on a bus, and maybe incorporate them turning on and off their screens during the trip, instead of just having them click through screens logically without any sense of distance or time. I would also want to turn these wires into a clickable, digital prototype to test the moving interactions and affordances to see how they are perceived by users.
Over this quarter, I have learned a lot and enjoyed seeing the progression of my designs and the designs of my classmates. I’ve learned the value of iteration, the value of critique, and the value of testing. I’ve built skills in systems thinking and the use of visual design tools. I’ve built something I’m proud of and something that I’m confident would work if it were to actually be built and further iterated on.
If you have any feedback on this “final” iteration, please feel free to leave a comment below.