News and blog posts from our students and faculty

Category Archives: Classes

Eight class weeks, seven iterations and one redesigned CapMetro app later

In the Rapid Ideation and Creative Problem Solving class, we are wrapping up the last week of our quarter with one final iteration on a CapMetro app redesign. When we first started the quarter, the redesign process began with the creation of concept maps which are used by a designer to visualize all of the components within a system. Doing this allows you to create a visual reference for the priorities and relationships of these components. After creating concept maps for both the existing system and our proposed redesign, we then created wireframes which are illustrations of the interfaces that bring the proposed redesign to life.

Next, using an evaluative user testing method called, Think Aloud Testing, we took our wires and began testing them with potential users. This testing method allows the design researcher to get a glimpse into the working memory of a user. During testing, users can articulate what they’re doing for the researcher as they are actually doing it without affecting the outcome of the task they’re performing. 

When I first began this redesign seven and a half weeks ago, my main goals for the user were to simplify the pass purchase process, make it easier to figure out how to get from where you currently are to where you want to go and make it easier to use the passes you have purchased. In the original system, there were multiple flows in the system that the user could select as starting points to begin planning their route. This included the Schedule, Maps and Trip Planner flows. They then were required to remember or re-enter information from one flow to another. A flow is a series of screens that contain actions a user would take over a period of time to achieve a goal such as buying a pass. 

Making design decisions and learning from them 

To simplify the experience for the user, I consolidated the Schedule, Maps and Trip Planner sections together. This allows the user to identify their starting location and ending destination in the context of what routes are available to them nearby and what other times they could take this route. The user is able to see this on the map. Being able to plan your trip and identify what route to take determines whether or not you purchase the ticket that will get you to where you want to go.  

Knowing which route to take is information the user must have before they can identify the service level they will need to purchase a ticket for. This is a complicated process because the user must also chose from several different service levels including Local, which is the Metro Bus or UT Shuttle; Premium, which is the MetroRapid or MetroFlyer service; Commuter, which is the MetroExpress or MetroRail; and Access, a shared ride service.

While there’s still a ton of things that could be done to improve the overall redesign I have proposed, it’s worth taking a step back to look at where I first started to where I’ve ended the quarter. The first thing would be starting from a very low-fidelity sketch of the system. By low-fidelity, what I mean is producing something that aims to represent the target concept, but is simple and something you can produce and test from a broad perspective quickly. I took this approach in my first two iterations, one that you can see below. 

First Wireframe Iteration 

Low-Fi Wireframes for Blog

Last Wireframe Iteration 

Home Screen & Buy Pass Flow

Trip Planner Flow

My Profile Flow

Use Pass Flow

In this last iteration, I focused on merging the information from Buses Near Me on routes and times specific to the bus that would appear soonest for that route into the the Trip Planner.This is the change that is reflected in my final concept map. 

CapMetro Concept Map Redesign 7

User testing and common breakdowns 

User testing this week was focused on the Trip Planner flow as it was the one I changed the most from last week to this. It revealed that there are still some things that could be improved in future iterations. 

Trip Planner Flow Breakdowns

The first break down showed that I could potentially merge elements from the trip route view into the screen that showed the top three fastest routes such as the name of the route and the bus number associated with it. This is something I would explore doing if I were to go through another iteration.  

The second breakdown was really about having a more obvious way to navigate through the different bus stops associated with each route. My intent here was to use color as a way to draw attention for exploring options from route to route. What actually occurred was that this was a point in the user test that would prevent the user from seeing the other options. I think adding in some left and right navigation arrows on the sides of the map would improve this. 

Finally, found that the step-by-step trip instructions were hidden too far down the Trip Planner flow. While users were able to get here, they would often ask for this information on the first screen that listed the top three routes. I could potentially eliminate the second screen, by bringing some of that information into the first screen and then have the drop down arrow give you an option that takes you to the step-by-step instructions. 

Now that I know what I know.

If I could summarize what I’ve learned in eight weeks, seven iterations and one redesigned CapMetro app later, there are a couple of things that I found to be particularly valuable. Based on what I have learned from the quarter, there are some things that I would do differently if I were to start all over. From iteration to iteration, I became more and more aware of the dangers caused by over-simplifying. It is an ongoing learning process for me to externalize the things I have paired away in my head in a way that helps other people understand why I’ve done the things I did.

It’s also a point in the process in which you take a step back and ask yourself if you’ve really thought things all the way through. Documenting the design decisions I’m making as I make them is something that I have started to do in order to get better at this. Not only is this a good way for me to capture both my thinking and decision-making, but it also helps me feel better prepared to talk about why I did the things that I did using the wireframes as the visual artifact. Being able to do this is a major part of gaining the feedback from others that you need to continue improving your work. While iteration has taught me that there will always be something more I can do to improve the flow, actually embedding this as a check point in your iteration process is what will get you to stop long enough to reflect on the things you have done. 

I also would have written more scenarios about the user earlier on in the process. This method helped me to overcome feeling stuck about not being able to come up with solutions for your system that are oriented around the user in a later iteration. Scenarios are written stories used by designers to help articulate how a person will use their system to achieve a goal. 

Most importantly, I have learned the value of doing multiple iterations. Whether I was working from lower-fidelity, sketched wireframes or digitized wireframes built in Adobe Illustrator, there were many iterations in between each version that was ultimately used in user testing that week. While the quarter is coming to a close, I also want to continue improving how the work I do reads from a visual perspective and identify screens that I can experiment with for using different interactions such as swiping. I now have a full set of wires that I can continue to work from for doing just that. 


Posted in Classes | Leave a comment

High Fidelity – How to ask the right question

At Austin Center for Design one of the nicest things you can hear is Jon Kolko saying, “You made a thing. I’m proud of you.” You made a thing?  A major tenant of the curriculum is learning to make artifacts as tools to ask questions and make arguments. Ever step of our seven-week-long, iterative assignment to redesign the smart phone app for Austin Public Transit System, Cap Metro, has been about exploring how to create artifacts that ask a question and get the information needed for that stage of the process.

The first week we created a system flow with screen shots from the existing CapMetro app and then created a concept map of the existing app and a concept model of our proposed redesign. A concept map is a visualization of the structure of a system to understand complex interactions that cannot all be viewed simultaneously in the actual product. We started here because this is the right thing to make for the questions we were trying to ask, namely: How does the existing app work and what is wrong with it? What should we do instead? If we had started by recreating and then improving upon a single screen from the CapMetro app, we would have created an artifact that would be excellent for asking questions about CapMetro’s typographic and layout choices, but would not provide useful information about the overall structure of the system.

The second week we started creating wireframes for our proposed new system. Wireframes represent the layout of a screen that focuses on functionality and interactions, rather than visual design. We have iterated on our wireframes each week for the last six weeks, as well as updating our concept model to represent our iterations.

At week three we had iterated on the wireframes once, and it was time to go out and get feedback from real people. To do this we used a method of user testing called the think-out-loud protocol with paper printouts of our wireframes. The user is given a task to perform using the wireframes. While he is completing this task, the user is instructed to “think out loud”, verbalizing each action as he does it. During the test the researcher acts as the “computer” bringing up the appropriate screens in response to the user’s action.




Each subsequent week of iterating and testing I have had the opportunity to see how the changing level of fidelity of my wireframes, or closeness to the actual thing being represented by the artifact, affects the type of feedback I receive.  In addition to documenting at least three critical breakdowns to address each week, I have found a high-level takeaway from my testing. Many of these have involved how the level fidelity, or closeness to the actual thing being represented by the artifacts, have affected test results. A few weeks ago my high-level takeaway was about the need for better visual consistency and hierarchy in my typography and graphic elements throughout the system – a fidelity issue. Last week, I realized that I was trying to test navigation at a level that depended on the user having a spatial understanding of how on and off screen elements related to one and other. This is largely communicated through animation that was not coming though on paper screens. For my final user tests I created an on screen, clickable prototype, so I could model some of those animations.


[Link to clickable prototype here: ]


What I found from my user testing is that the fidelity  of the clickable prototype created a number of issues of its own. Because the prototype looked very real, and some of the gestures felt like a real application, users were derailed when it did not behave the way a real application should behave. This was especially true for the keyboard, which was just an image with certain sections mapped as hot spots to link to other screens and the map, which was also just a static image and so did not allow for zooming in and zooming out.

“Wait, the keyboard is broken…” – User 2


Despite these issues, I got useful validation on my updates to the real time bus arrival feature, called Next Bus (see Next Bus Flow below), and feedback that lead to a final tweak to my on-going attempt to integrate step-by-step written directions to a destination with the map of the route (see screen 27 and screen 29 from the Search Flow).



“I don’t expect to swipe [between things] on a map.” – User 4





flows-02 flows-03


So, that’s it for this quarter. I made a thing, and I’m proud of me. I have learned about the specifics of designing a transportation application, about the tools and techniques available for wire framing and I have continued to hone my ability to craft artifacts that elicit feedback that is useful.

Posted in Classes, Uncategorized | Leave a comment

CapMetro App Iteration 6: Defining and Refining

The latest iteration of the CapMetro App was intended to reduce the number of physical clicks that it would take a user to get from point A to point B, purchase a ticket, or add money to their “wallet”, and get on their bus.

Other smaller functions such as saving to favorites, finding help info were taken into consideration but not the primary function of this iteration.

Below is the revised concept map for this version of the flow:

Cap Metro Concept Map - Support Process

And below are the pre-critiqued wires of the consolidated journey:



3-01And below is the post critiqued in class revisions to the wires:

20141210_214335After both critique and user testing the results were mixed both positive and negative.

My user tests did not seem to have an issue with being immediately presented with the idea of getting to a particular location from the location they were currently, via gps.

The critique however pointed out that someone, at some point may want to not always use their current location to get from A to B, and might not realize that by clicking the “Plan a Trip” button on the navigation that option actually appears.

My user test questions then were to specific. The task posed was get from where you are to this destination. This was not an open ended question and from this the task seemed rather obvious and was generally successful.

The next steps are to actually take into consideration these open ended questions. What if a user wants to perform a certain task that I do not have the option for? And this is the process of iteration.

Honestly 7 iterations is really not enough to get to the ultimate flow for the user. Testing and re-testing is really the key. Getting the wires in front of real people and knowing what questions to ask or to NOT ask might actually be the key.

Posted in Classes, Design Research, Interaction Design | Leave a comment

A moving experience: Nearing the end of the CapMetro ReDesign

It’s week 7. That might not mean much to you, but to us here at Austin Center for Design it means we have 10 days left to finish out the second quarter of the Interaction Design for Social Entrepreneurship program.

It also means that after spending the last six weeks working on redesigning the smart phone application for the Austin’s Public Transportation system, CapMetro, we only have one more week to update wireframes, user test them and present them for critique. We are using a method of user testing called the think out loud protocol: A user is given a written task to complete using the wireframes (for example, find a route between your current location and this address), the designer performing the test acts as the “computer” bringing up the appropriate screen or component in response to the user’s actions, and the user is instructed to “think out loud,” saying what he or she is doing and why, while performing the task.  With the fact that the quarter is drawing to a close in mind, I planned my user testing this week to focus specifically on a couple of problem areas in my design.

Me conducting a user test at a favorite dive bar. Image courtesy of Lauren Segapeli.

By this point my flow for searching for routes and narrowing down options based on departure time is going pretty smoothly. So, rather than run users through that again, I focused on how the user drills down on a particular route to a destination, looking at the interaction between the information presented through the map and the information presented via text. I also looked at the flow for the Next Bus feature, which allows the user to find out when a bus is next departing from a particular stop based on real time data, rather than just the set schedule.

My high level take away is both encouraging and daunting: my design has reached a high enough level of fidelity that the animation between states is increasingly crucial for the user to understand how to navigate the application. So, for my final round of testing and critique I need explore better ways to describe this animation. In the meantime, below are some of the specific problems I encountered in my testing and the complete flows I tested. I’m also including a high level system diagram that I created last week to explain a problem I was running into and how I have updated it in this week’s iteration.



Above is a search flow as the user finds a route, departing after 5:30, to go from his/her current location on Chestnut Street to my favorite Mexican restaurant in Austin, Polvos, on South First Street. point-01

This is screen appears after the user has selected one of the options for a possible route to Polvos.

“So I guess I walk from point 1 to point 2…” -User 1

The user I was testing with understood the numbered circles on the map to be points to travel between instead of steps on the trip, this caused confusion.



The user can access step by step instructions by swiping up the panel on the bottom. To return to different options the user clicks on the section on top where the options have stacked on top of each other. Most users understood this, however, it was somewhat awkward. This is where I realize I need focus on the animations and transition. It is strange for the options to stack in front of the to/from bar.

The other flow I focused on is for the Next Bus feature below:


I realized while I was testing that I didn’t include a way to get to screen 25, the list of all bus stops on the route.  I have since added the VIEW ALL STOPS button that you can see in the flow above to address this problem.


This shows the screen before the button was added.

Finally, I need make more apparent the connection between the scheduled information used to plan trips in the future and the ability to use real time data to check projected arrival time for in-transit buses.

“I’ll reopen it to check for estimated time of arrival when I’m leaving.” -User 3

I want the user to know that when he/she looks at route to a destination within a certain period of time before departure, the app will automatically query the Next Bus data to update the arrival times for buses and modify the route if necessary.  This issue, plus some improvement since last week are diagramed below.


Posted in Classes, Interaction Design | Leave a comment

CapMetro App Revamp: Iteration 6 + User Testing


Each week in our Rapid Ideation and Problem Solving class we have presented a new iteration of Austin’s public transportation app and today marks the presentation of our 6th iteration.   Over the last three weeks we have been incorporating the Think Aloud Protocol as a way to learn directly from users what they’re thinking as they use our application.  This method of testing provides valuable insight into the usability of our designs and provides ample data to help us move forward as we iterate each week.  To learn more about this process of user testing (and to see last week’s iterations) you can take a look at my blog post from last week here.

This week I used the same Think Aloud Protocol to test designs with 5 participants at the same bar my classmates and I tested at last week.  Testing at a bar not only helps the designer (me) to simultaneously unwind while gathering valuable data, but it also helps the test subjects feel more comfortable speaking aloud since they have typically had one or two drinks, and thus have lowered inhibitions.  The data I gathered this week continued to be useful as I approach my final iteration, due next week.  You can take a closer look at the full flow of screens by clicking the image at the top.

The first thing I found through my testing deals with the images below.  The user was asked to purchase a pass, and when they reached the screens below, they expressed confusion as to why their credit card number was still showing as editable and they hesitated before touching “confirm.”  I need to make this series more visually coherent by making it clear that they have successfully entered a card number and that they are confirming the purchase.  My intuition is that they hesitated because their mental model of a payment confirmation is more direct, along the lines of “Your card will now be charged $5.50″ and then providing a means to confirm or cancel.



The second deficiency I found dealt with the visibility of the “later” option on the screen below.  I asked the users to plan a trip that arrives at a later time, and they had difficulty finding this option which is located at the bottom of the screen.  For next week, I’m going to sketch ways to incorporate a “later” option in the initial search criteria, or at the very least make this option more visible on the screen.




The third issue, which did not actually arise from user testing, but from asking for a teacher’s opinion on the design deals with the screens below.  The first and third screens below both contain bus stop icons, and they perform different functions when tapped depending on what screen the user is on.  This is inconsistent.  For my next iteration I will try combining the information from the third screen directly into the first screen to see how that tests.  I will also be looking at ways to get rid of the key since it takes up screen real estate and overall is visually clunky.




Next week will be the final iteration, if you have any feedback on this series of wires — anything from function to visual asthetics — please leave a comment below.

Posted in Classes | Leave a comment

CapMetro Redesign Iteration 6

In this sixth iteration of the CapMetro App redesign for my Rapid Iteration and Creative Problem Solving class, I learned about how you can use scenarios to help you overcome feeling stuck about not being able to come up with solutions for your system. Scenarios are written stories used by designers to articulate how a person will use their system to achieve a goal. With only one last iteration to go this quarter, I decided to focus my time on building out the user flow for what was originally the Schedule.

After crafting a short scenario, I came to the decision that what a user that routinely rides the bus needs is not just a schedule of routes, but a way to know what buses are near them and when. From here, I illustrated the interfaces that help bring the proposed redesign to life by creating wireframes.

These are some of the changes that I made based on replacing the Schedule with Buses Near Me.

Home Screen Changes 

  • Eliminated the schedule button and replaced it with Buses Near Me
  • Eliminated Next Bus because Buses Near Me does the same thing in that it allows a user to see based on the stop closest to them, when the next bus will arrive. It is also not useful for the user to just see the time the bus will arrive without the context of where they will be picked up from.
  • Adjusted the size of the Pass Holder to be the same as the other buttons on the screen.

In this iteration, I also revised the concept map which was used initially to map the existing system. Concept maps are used by a designer to visualize all of the components within a system and understand both the priorities and relationships these components have. The revised concept map shows the changes made to the the home screen. Getting rid of Next Bus means I can make the Pass Holder Button the same size as the others. I also no longer need Buses Near Me.

CapMetro Concept Map Redesign 6

User Testing

I’m continuing to practice an an evaluative user testing method called, Think Aloud Testing. With this testing method, the design researcher can get a glimpse into people’s working memory. This allows me to hear how people are thinking through each step as they articulate what they’re thinking without affecting the outcome of the task they’re performing.

For user testing this week, I provided the user with the following scenario: You’re a regular bus rider that usually takes the same route at the same time every day. Today is a special day. There’s a major event in town and you have decided to head to work at a later time than usual. How would you use the Buses Near Me feature to find a new route to your job at the Domain. This task revealed several breakdowns in this flow:

Schedule Flow


“Why would I use Buses Near Me instead of the Trip Planner?”

“Where’s the keyboard?”

“How do I know where I am right now? I don’t know where Century Oaks Terrace is.”

“Maybe I can press the time?”

What user testing revealed for me is that moving into my final iteration, I need to identify the best elements from Trip Planner and Buses Near Me and combine them into one single flow. They are both For example, I think that the Buses Near Me map could help the user visually orient themselves better than the Trip Planner map because it immediately shows you what route is associated with the times displayed on the screen. From the Trip Planner, I think the ability to immediately buy or use your pass. All screens for my proposed CapMetro Redesign can be seen here.

Posted in Classes | Leave a comment

The ideal, the not-so-ideal, and the service blueprint

In our Service Design class we read an article by Mary Jo Bitner called Service Blueprinting. The reading provided foundational steps and example case studies on how to predict and help improve customer service through a consumer point of view. A service blueprint is a way of mapping a service that can be digital or physical. Anywhere from a smart phone app that is providing a service relationship with a customer to a physical store that a person can walk into and explore.

Service Blueprinting is also way of creating an artifact around an experience that can be shared with other people. Someone might want to map a service to gain a greater understanding of the whole, or gain a different level of clarity, if zoomed in upon, to what a service and system looks like visually. It makes it also easy to share and build upon for future states and changes.

Many of the examples shared within the reading were mapping an ideal state of a customer’s experience. But as I continued reading further I began to wonder, what happens if it breaks down? There are other ways to looking at a service- instead of just simply planning for the ideal. Then that creates a problem: how would you imagine mapping contingency plans? You would have to find a way of building behavior but without understanding the myriad of worst-case scenarios.

Extracting from negative possibilities, a different way to look at the opposite-of-ideal situation, is to zoom out to another layer and concentrate on the feelings a customer may be having during these less than perfect experience points. Concentrating around the idea of feelings, or the way somebody is reacting to a negative experience could be an informative way of mapping a service. Human reactions provide cues to a moment where you can implement some sort of strategy. This level of focus takes away from the unpredictable nature of the million things that could go wrong in someone’s experience, and provides a small pool of variables that then can be clues leading towards how to implement new points of interaction to bring the customers experience back to a controlled state of being.


Just like stated before you can’t plan for every single negative and on the same note you can’t predict every single positive either. You need to hope for the ideal and plan for it but then plan in an autonomous employee human manor.  Essentially it’s designing a policy for when the system breaks. The employee can then pull from plausible scenarios that are more controllable and not as abstract.

Posted in Classes | Leave a comment

How may clicks should it take to get to the center of a CapMetro App: Iteration 5 and critique notes for 6

A couple of weeks ago we had a visitor come in that was a map aficionado. From her wonderful visit I came away with a really great sense that a map isn’t just a representation of a space through lines and dots. Maps can convey space, distance, change over time in landscape and construction. Maps are extremely complicated, yet at the same time they should be simple.

A dichotomy I agree, but a necessity I also agree.

Reconstructing the idea of a map through an application where you preform tasks to get to an end goal is not only a task of keeping that map simple, but also making for the user the most straightforward fast and delightful experience that surrounds that map.

After her visit I made some changes to my version 4 iteration, and came up with the below offering to my user test subjects the same 6 tasks.





This is what (after a few minor tweaks to the interface from feedback from users) my app mock up looked like when viewed through the eyes of a very very smart man.


If this doesn’t come completely across at first for the iterations that will come next blog post, here was the feedback from the mini-critique given on the fly Tuesday evening this insightful mini-critique.

  1. Screens 1 & 2 find better ways to show how the user interacted with the app.
  2. Screen 3  There is no option for choosing your time of arrival. What if the user wants to actually arrive somewhere at a certain time rather than leave at a certain time (This was brought up in user testing as well). Buy button can go to the bottom. Why do you need a home button when all your task items are listed at the bottom? Where does home even take you?
  3. Screens 4 & 5 refer to critique of screen 3. Screen 5 take into consideration that there might be multiple steps to get to your stop, and create a scrolling carousel where the user can scroll step by step to their stop while the map animation follows the written information so they are both in sync. Separate out the information sections with whitespace.
  4. Screens 6 – 7- 8 – 9 – 12 – 13 & 14 combine into one screen.
  5. Eliminate 10 & 11 altogether (they are annoying and unnecessary)
  6. Screen 16 – 17 – 18 ok, but could be better and higher quality.

Now, with all that said and all but a few screens left to get to point A to B and buy a ticket (add to Wallet), now it is time to correct these screens, combine and consolidate. To choose fabulously readable fonts, make the UI friendly and creative without being complicated. Fun but not kitschy.  So by eliminating almost half the screens the next iteration will “fill in the blanks” with all the things that inevitably happen when something goes wrong.

So lets get started.

Posted in Classes, Interaction Design, Portfolio | Leave a comment

CapMetro App Revamp: Iteration 5 + User Testing


This week in our Rapid Ideation and Problem Solving class we are presenting the fifth iteration of our redesigned mobile application for Austin’s public transportation provider, CapMetro.  Each week we run a formal critique in class to gain feedback from from fellow students, faculty and visiting lecturers, and use the information we gather from these critiques to iterate on the look, flow and functionality of the design.  The last three weeks we have also incorporated user testing as means to gaining insight into the usability of our designs.

The format of user testing we have utilized is called the Think Aloud Protocol.  The Think Aloud Protocol involves a user who interacts with one wireframe at a time as if it was an actual device.  The person administering the test acts as the “computer” and is responsible for giving the user the next appropriate screen based on their interactions.  On top of observing the user interacting with the design, the users are asked to verbalize what they are thinking as they interact with the screens.  As it turns out, humans are pretty good at verbalizing what they are thinking while they are thinking it, and it has been shown that verbalizing those thoughts doesn’t significantly effect their actions.  This makes this form of user testing extremely valuable for designers who are always looking to understand both the how and why behind people’s actions.  Other forms of testing, specifically tests that accumulate metrics, are good at understanding how people interact with a product, but without hearing people verbalize their rationale behind certain actions, they’ll only be able to guess as to the why. 

That said, this form of testing is easier said than done.  It may seem obvious, but I’m finding that in order to get rich data, it takes a test subject who isn’t reluctant to speak aloud about what they are thinking.  To maximize the likelihood of success, the person administering the test must focus on the way they present the test to the user.  Using self-deprecation, giving an example of how thinking aloud sounds, assuring the user that the design is being tested, not them, and even telling them that they are testing somebody else’s design so they are not afraid of hurting the test giver’s feelings can help put the user at ease and make for more useful data.

This week I went to a local bar with some of my fellow design students and we set up shop offering to buy people beers of they would user test with us.  While it may not seem like a great idea to involve alcohol in a user test, it actually works out great.  A little alcohol seems to diminish some of the inhibitions that usually accompany the awkwardness of thinking aloud in front of a total stranger.  I tested with 5 individuals at the bar, and was happy with the information I was able to learn from them.

The wireframe screens I tested are presented at top, and are organized into three main flows listed in the left column.  These flows are based on the concept map below (click images for a closer look):



The first flow, which is my main “hero” flow, involves finding out when the next bus will be arriving at a nearby stop.  Compared to previous iterations, this task improved significantly.  I focused on increasing the fidelity of these screens this week, and it was great to see the impact this had on how well these screens were navigated.  While my main flow improved significantly, the other two flows did not see as much success.

The screen below from my second flow gave some people trouble:


The icons circled in the picture are meant to represent “history” or “recent searches” but this is not obvious to the user and so I will be providing a heading above these in the future that says “Recent” in the same way it says “Favorites” above favorites.  I also think some of the confusion from this screen is just a challenge of testing a paper prototype; Paper prototypes are static, so the user can’t experience any of the moving/animated affordances.  In this case the user does not experience the keyboard and the “recent/favorites” animating into place, and so they were confused with how this screen related to their previous action of tapping the “Enter your Destination.”  For testing purposes, it may be necessary to provide an intermediate step between these screens, showing the motion, to give the user a more realistic experience.

The screen below also gave people trouble with my second flow:



The location and destination is sized too large, and people were confused why the arrow is pointing to a destination that is not the destination they typed in.  Most people thought the “8min” refers to when the bus will be arriving (and not the duration as I had intended it), and they were confused with why this information is presented with the “leaves at 2:13 pm” thinking this information is redundant.  This week I will be placing a lot of focus on this screen and will try to create a number of iterations playing with size and priority of information, and hopefully next week this screen will be much more clear & usable.

For the third flow — buying a pass — there was one consistent area of confusion that involved the transition between the screens below:



In this iteration, after people enter their credit card information, a button shows up with the card they entered showing as an available payment method.  Through my testing it became clear that this is an unnecessary step.  The user just entered the card number of the card they want to pay with, why am I now forcing them to select that card for payment?  While I could just make an incremental change to fix that, overall, I’m not happy with this flow and want to rethink it completely.  This week I’ll be focusing on simplifying this flow to make it less clunky and flow more naturally.

Overall this week I’m happy with my progress and happy with the information I gained from testing.  I feel like I have a clear path forward and feel confident that my next iterations will continue to improve.  If you have any feedback or thoughts on ways to improve this design please feel free to leave a comment below.

See you next week!


Posted in Classes, Uncategorized | Leave a comment

Everything to everyone: CapMetro redesign iteration 4

Last night I did my third round of user testing at one of my favorite bars in Austin. For those of you who are just tuning in, the quarter-long assignment for the methods class is to redesign the smart phone app for Austin’s public transportation system. Each week we are creating updated wireframes, which are layout sketches for a digital interface based on the results of user testing. We are using the “think out loud protocol” for user testing, which involves asking participants to preform a task using the wireframes, saying out loud what they are thinking and doing as they preform the task.

I made some pretty big changes based on testing and feedback from last week’s iteration. Not surprisingly I found some pretty big holes in my design this week. I have identified two high level problems and three specific system failures from my testing.

The first problem is referenced in the title of this post. I’m still wavering on for whom I am designing this app. Is it the first-time/occasional user, or is it for someone who rides public transit multiple times each week? Once I determine this it will clarify how to prioritize features and how much explanation and hand-holding is required.  In particular, the Next Bus feature has a very different value for a frequent rider who knows the bus route she takes all time and just wants to see if the bus is on time versus someone who isn’t even sure there is a bus that goes to the right place.  We started the redesign process by writing a brief vignette about our user. I am going to revisit and update that vignette before I begin tweaking the wireframes for the next iteration. (From a testing perspective it is probably easier to find people who fit the first time/occasional user persona, but there are some potentially more interesting features for the frequent user. I’ll let you know what I settle on next week.)

The second high level problem is a visual design problem: it is not clear what is clickable, tappable, swipable or otherwise actionable, and what is just informative. As I work through this upcoming iteration I’m going to be very mindful of visual consistency and what visual cues have been successful in past iterations.

These high level problems manifested in the following 3 system failures or critical incidents:

1) The nearby bus stops on the home screen (red shapes) are not obviously clickable nor is it clear to users why they would want to click on them. (Image below is #1, #40, #20 and #30 in the flows at the bottom of the post.)

“Those red things are super annoying.” - Test Participant #3

“They’re just there, they don’t tell me anything.” – Test Participant #4


2) The system doesn’t differentiate between searching for a route to find Next-Bus information and searching for a route to find the complete schedule. (Image below is #21 in the flows at the bottom of the post.)


I created the diagram below to visualize this problem and to understand how the navigation is working (and not working) in general. You can see that there are a number of breakdowns, indicated by the red lightning bolts.



3) Placing the step by step instructions as pop-ups on the map, rather than as a list, is still confusing. Users did not realize the numbers were clickable to reveal the next set of directions. (Image below is #8 in the flows at the bottom of the post.)


Below are the complete sequences of screens that I used for testing, with orange dots to indicate user action.


Posted in Classes | Leave a comment