News and blog posts from our students and faculty

Category Archives: Methods

CapMetro Re-design Wrap Up

For quarter two, our Design Methods class has been focusing on rapid ideation and iteration for a redesign of the Capital Metro mobile app. For those of you who don’t know, Capital Metro is Austin’s public transportation system.

To kick this project off, we completely immersed ourselves in the current app in order to formulate a thorough understanding of the current experience of using the app and identify the key areas where it breaks down.

The Problems

There are a number of things that cause frustration while using this app, but the attributes that cause the most frustration is the navigation, different menu items take you to the same place, and in some flows, it’s difficult to find your way back.
Here’s a concept model of the app as it currently is in order to illustrate its complexity and more clearly identify the breakdowns:
 
CURRENT-ConceptMap-CapMetro

 

With these breakdowns noted I created a new, “ideal” concept map:
 
Ideal-ConceptMap-CapMetro-Revised03

With this in mind, I chose to focus on the following:

1. Get a step by step itinerary based on my desired destination from my current location
2. Identifying a stop near me and easily understand if the bus I need will pass through

And so we begin…

Like I said earlier, this class is about rapid ideation and iteration. We started with an initial set of wireframes, user tested them and then made edits based on the results from testing. This process of make, test, iterate went on for six weeks.

Overview-iteration

User testing allows us to assess the usability of the product. In this class, we used Think Aloud Protocol, a method of testing where you ask the participant to think out loud as they are going through the flow of the product to complete a specific task. It allows you, the designer, to gain insight into the thought process a person uses to complete a task rather than just focusing on the completion of the task. This way you can pinpoint where adjustments to the design are needed.

UserTest-Hands
 

Evolution of the Trip Planner

TripPlanner-AllScreens

Evolution of Home Page
Evolution-HomeScreen

Evolution of the Trip Experience

Evolution-Map

Iteration 7: Trip Planner

TripPlanner-FinalFlow-Blog

What I learned

Think aloud protocol works.
People catch on and it’s a great opportunity to step out of your designer tunnel vision and see the design through their eyes. It immediately becomes clear where there are wholes in your design.

Make it difficult, make it real, make it almost impossible.
When user testing, you must be careful about how you craft the scenarios. It’s easy to make a scenario that may not be real enough but works well with what you’ve designed. This won’t tell you what you need to know to move your design forward.

Carefully consider the order of your flows.
It became very clear that it only takes one flow for a user to begin to learn your application and then begin to expect certain results. With this in mind, it’s important to order your flows strategically.

Posted in Interaction Design, Methods | Leave a comment

Last Stop: Final Iteration of the CapMetro App

We’ve made it to the last week of Q2 at AC4D, and to our last iteration of our project; redesigning the CapMetro app. The CapMetro app is used by riders of the CapMetro public transportation system here in Austin, and allows users to purchase and use tickets, find routes, see schedules, and more. Over the last 8 weeks, we’ve created, tested, and revised our designs for the CapMetro app 6 times in our Rapid Ideation and Creative Problem Solving class. Since it’s the last week, I’d like to review the process, what I did, and what I learned over the course of this quarter.

Concept Map:

Each week, we created concept maps to describe and illustrate the overall idea of how our redesigned apps work, and how the pieces of the app relate to one another. At week 1, we mapped the existing CapMetro app. This was the app as I saw it:

Concept_model2

Because I perceived the app as overly complicated and confusing, I wanted to start from the minimum capabilities that would still allow riders to buy and use tickets, plan a trip, and take care of the administrative stuff needed to handle ticket purchases (such as storing credit card info). Secondarily I wanted users to be able to reach a CapMetro representative with problems or questions. The final iteration and concept map maintained these goals, as you can see here:

IDSE201_wireframes_map_wk6

 

Wireframe Process:

While the concept map maintained the usage goals I originally set, the manifestation of these capabilities changed drastically in the wireframes. To iterate my wireframes each week, I followed this process:

  1. Re-sketched wireframes based on selected issues from user testing and in-class critique the previous week (more on that below). I preferred to sketch out ideas on paper before investing the time creating the graphics in Illustrator.
  2. Revised existing or created new wireframes in Illustrator. Each week, we would learn how to increase the fidelity a little bit, to make it look more like a real app, which gave users more clarity in testing.
  3. Performed think-aloud testing with paper wireframes. In this type of testing, I would approach people I didn’t already know and give them tasks written on a piece of paper to see if the app would allow them to complete these tasks or if there were moments of breakdown and confusion. I would ask them to think out loud as they navigated the app by pressing or swiping the paper cutouts of my wireframes. I played the part of the very slow computer, and once a participant pressed a button, I would put the next paper “screen” in front of them until they felt they had completed the task given to them. With recorded feedback from testing, I could choose the issues I wanted to pursue in the next iteration, and ignore comments I felt were really edge cases.
  4. Held an in-class critique. In class, typically the students would get 10 minutes each to lead a critique of their work, with questions to focus the comments. We would capture the comments and then, as with user testing, decide which issues to pursue.

And then repeat.

Main Changes:

Through the iterations, I saw 2 main changes in my work. One was the expansion of the app to include more and more necessary capabilities for people using the app in different situations. The other was the increasing level of visual fidelity.

As I mentioned, I wanted the app to be simple—much simpler than the current real-world product. Starting from my own experience as a bus rider, I pared the app down to what I felt was the minimum viable product. Through user testing, I was exposed to a variety of people who needed the app for different tasks or who had different preferences for how information was presented. For example, I wanted to avoid using maps, but many people need them to feel oriented. This made it necessary to expand the app to include many capabilities. Additionally, no individual screen should have too many capabilities on it, or it becomes confusing. The combination of these factors led me to expand the app. While it is less simple in terms of the number of screens, my app became simpler to use for the rider. Below are excerpts from the 8-week evolution of my wireframes. I have indicated the focus for the week on each iteration, some problems found, as well as fixes that increase fidelity at each pass.

Wireframes by Week:

Week 2

Focus: At week 2, after spending week 1 on concept maps, I made my first ever wireframes. Using my concept map, I focused on the payment method first. The existing app has a use-ticket capability. When you use a ticket on the bus, an animated screen shows up on your phone that you simply show the driver. Some drivers will make you tap the screen so it turns from blue to red. I suppose that’s to verify that it’s not counterfeit. However, there’s no scan mechanism or anything on the bus to show when a person uses the ticket, or on what bus. My idea was to put a barcode on the ticket machine receiver each bus, and then use the app as a scanner to scan the barcode. This way, the cost of the ride could be deducted from a rider’s account and CapMetro could capture information on use of the ticket.

Because it’s cheaper to buy longer-duration passes (eg, 7-day pass versus a day pass), I created a “punch card” system on this first iteration. If you rode a certain number or times, your next ride would be free. This was visually very confusing for everyone.

Issues: The punch card system was too confusing. The barcode system was generally well-received, although the technology is not really good enough yet to make it a convenient solution (imagine standing at the front of the bus and the app won’t scan).

Fidelity: Very low. It was more important at this point to start thinking of the app as a system than as a beautiful artifact. Even with low fidelity, user testing was successful in rooting out issues with the design.

IDSE201_wireframes_wk8_w2

Week 3

Focus: The use-ticket capability necessitates an “account” for the rider to which he or she can add money.

Issues: Typing in the amount a rider wishes to add is a little awkward, and invites mistakes such as accidentally typing in a symbol instead of a number.

Fidelity: Very low. The imperative for this iteration was to flesh out several flows, and so I ended up with a greater quantity of screens, but not better quality screens. Since this was iteration 2, I was ok with that decision.

IDSE201_wireframes_wk8_w3

Week 4

Focus: I moved away from the ticket flow and concentrated on building out the “find a ride” flow. How would riders find buses and select the right route for them? Additionally, I increased the fidelity to make clickable elements more explicit. In prior user testing, the flat, low-fidelity style sometimes confused people as to what they could push.

Issues: I had resisted using maps, and at this point through critique and testing I found that maps were important to people.

Fidelity: Low. I experimented with putting gradients on buttons which is not pretty, but it did help clarify usage in user testing.

IDSE201_wireframes_wk8_w4

 

Week 5 

(No iteration, it was Thanksgiving!)

Week 6

Focus: Increase fidelity and rethink the “find a ride” flow. In this iteration, I added maps that took up the whole screen and took out the screen with numbered steps. Instead, each step of the ride could be seen on the map. Again, this made more screens for me to create, but was easier for users to understand in testing.

Issues: I focused on the “find a ride” flow at the expense of the “account” section. Users found the account section confusing, leading me to concentrate on it in the next iteration.

Fidelity: Medium. With the help of my classmates and an in-class guest, I was able to make this look a little more like a real app.

 

IDSE201_wireframes_wk8_w5

Week 7

Focus: The account section. Instead of making the user go through the “My Information” screen to get to “Fare Balance” and “Payment Methods” I separated the 3 flows out once a user hit “Account” on the home screen.

Issues: The overlay confirming that a user’s account has been updated only covered part of the screen, leading to user confusion over which “Done” button to hit.

Fidelity: Medium.

IDSE201_wireframes_wk8_w7

Week 8

Focus: I needed to increase fidelity so it looks like a real app. This week, I made minor changes to the account section and spent some time trying to make just one screen high fidelity.

Issues: At this point, much of the app has been built out, but there are still several circumstances that are unaccounted for. I decided it would be useful to go back to thinking up scenarios—or little stories about how users would need to use the app, in order to fill in those gaps. When I revisit this project as a portfolio piece, I will start with scenarios to make sure my system is comprehensive.

Fidelity: Medium and Medium-high.

IDSE201_wireframes_wk8_w8

Next Steps:

In revisiting this project at a later date, my goals are to continue building my capacity for systems-thinking. Focusing on different parts of the app to smooth out issues is fine, but the app must work as a whole and every possible screen must be accounted for. Additionally, I would like to continue building my graphic design skills so that I can create high-fidelity wireframes and other deliverables.

The complete set of this week’s wireframes can be seen below. Thanks for following us through the last 8 weeks of iterations!

IDSE201_wireframes_wk8_all

 

 

Posted in Methods | Leave a comment

CapMetro App Redesign: Iteration 6

This week, our Rapid Ideation and Creative Problem Solving class at AC4D completed the sixth iteration of our redesign of the CapMetro app. CapMetro, Austin’s public transportation service, provides this app for commuters using their bus and rail lines. I mostly worked on the “Account” section of the app this week, but as a broad overview, the concept map (showing major pieces and how they relate) is here:

IDSE201_wireframes_map_wk6

Last week’s user testing of the previous iteration of wireframes revealed a gap in the “Account” section of my wireframes. I did not have a good way for a user of the app to add money to their balance, except through the “Pay Fare” section if they wanted to add to their balance right after they used a ticket. Additionally, the previous version of the “Account” section was visually too crowded with buttons and that made it confusing for users to know what to do next.

In this iteration, I split “Account” into 3 sections. Once you hit the Account button on the home screen, the app takes you to a screen where the user has the choice of “My Information”, “Fare Balance”, and “Payment Methods.” This makes it simpler for a user to directly access the function they’d like, rather than filtering through the “My Information” screen or the “Pay Fare” screen, as in the last iteration. These are the three resulting flows:

IDSE201_wireframes_wk7_blog4

In this week’s think-aloud user testing of the current iteration, where users think out loud— stream-of-consciousness style—as they complete a pre-written task by pushing buttons on the paper prototype of the app, users had an easier time with the “Account” section. However, I used an overlay on screens to show that change had taken place, or to confirm what the user meant to do, such as on the screen below. Users were confused by the dual “Done” buttons. Even though the “Done” button on the bottom was always present, and the overlay was meant to rest on top of it so that users ignore the bottom screen, it seemed that users perceived all the elements on the screen as a unified whole. I will have to go through the app for next iteration to make sure that there are no conflicting buttons on any screen, even if the conflict is between an overlay and the background screen, or make the overlay darker and encompassing of the entire screen, so the background buttons are barely visible.

IDSE201_wireframes_wk7_blog2

Additionally, we recently had two classes on the basics of visual design, and I began to apply more care to the aesthetics of the app. In this case, I started using guides in Illustrator to align visual elements (though I need to apply them more consistently for next round), and chose icons  that were clearer and looked like they belonged in the same “family,” visually.

Our next iteration is our last one for this class, and my goal is to put a greater degree of care into the visual presentation of the wireframes, so that it looks more professional. It’s important for users to see a neat and clean layout, because it affects their level of trust in the app. Trust is important, especially if users rely on the app to get them places they need to go, like work and home, safely and on time.

Click the wireframes below to view the full set.

IDSE201_wireframes_wk7_blog3

Posted in Methods | Leave a comment

Redesigning the CapMetro App: Iteration 6

iteration 6

Previous user testing sessions made it very clear that it only takes one flow for a user to begin to learn your application and then begin to expect certain results. For this round of user testing, I reordered the flows and scenarios in order to combat this. At the end of a trip, the user is given the option to save that location as a favorite. Since this was the first flow they finished, they applied this model to future flows. Hence, when asked to save a location as a favorite, starting on the home screen, each individual decided to go through an entire trip in order to get to the end where they could then save the location as a favorite.

In addition to reordering my flows, I decided to give the participants scenarios that covered ‘edge’ cases. I wanted to see what how the app would hold up if they had to double back or completely end a trip. While it ended up working fine, I learned that I should most definitely role play these ‘edge’ scenarios as they can be slightly confusing. They were confusing for two reasons– 1. I didn’t write them well and role play before with at fellow classmate would have mitigated this. 2.The participants I tested had a difficult time putting themselves in a situation outside of their current one. Example: If they had to change buses and go a completely different direction they would have “Called an Uber”.

 

Flow #1:

You want to save your home address as a favorite location.

There were no issues in this flow during testing.

Flow01-CapMetro-blog04

 

Flow #2:

You’re currently on Chestnut between 14th St and 15th St. You are walking to the bus stop around the corner on 15th St near Coleto St. You want to see when the next bus is leaving from this stop. You want to double check that the next bus is on the route you need.

Flow02-CapMetro-blog04

Issue:Multiple people expected the route for the next bus to appear after pressing the white pop-up. The hierarchy on the route page confused people– one person thought they were looking at a series of steps for the route.

Design Solution:The hierarchy of information on the page needs to be more apparent. If the user is making a decision based on the route, then the route number needs to be the obvious notation for sorting. This will help set expectations for what they are looking at. Also, there should only be one icon in use on this page. In this case, animation could be a good solution for orientation. Once the user presses on the white pop-up, it will move up to the top of the screen and the other routes through the stop will appear below.

 

Flow #3:

You are currently on the Eastside on Chestnut and 14th St and want to go to Hole in the Wall. Knowing that you’ve previously saved it as a favorite destination, find a bus there.

There were no issues with this flow during testing.

Flow03-CapMetro-blog04

 

Flow #4:

Curious of how people would back out of a trip once they’ve ‘started’, I gave two scenarios for the same flow:

Scenario #1: You are meeting friends at Hole in the Wall. You want to see what different trip routes from your current location will look like on the map.

Scenario #2: You are meeting friends at Hole in the Wall. You are currently on Chestnut and E 14th St. Find a bus to get there. Get on the bus. When you are on the bus, a friend calls and says they changed their minds and instead are meeting on South Congress at Snack Bar.

Flow04-CapMetro-blog04
Issue #1:Everyone hit the back button to view other trip options and “End” to end the trip when their friends called and changed plans. This is good. The confusion happened after they chose a trip. Participants didn’t think to click on a part of the route to see the information.

Design Solution:Once a trip is chosen, the map of the route comes into view and the first step is highlighted with the information pop-up. So, screen 6 will replace screen 5 as the first screen a user sees.

Next Steps
You can view my concept map here. For the next week, I’m going to focus on the usability and fidelity of the above screens.

Posted in Interaction Design, Methods | Leave a comment

Redesigning the CapMetro App: Iteration 4

The redesign of the CapMetro app is moving right along! I was able to user test six people this round, and it continues to be an educational experience. (Check out my previous post for a more complete breakdown of the user testing process.)

As a reminder, the goals I identified as most important when using the app were the following:

1. Get a step by step itinerary based on my desired destination from my current location
2. Identifying a stop near me
3. Buy a ticket based on my route
4. Easily Use a purchased ticket from any point in the app

 

Flow #1: Find a bus to Hole in the Wall (a local bar).

Flow01-CapMetro-blog03

Issue #1
Once on the map view of their chosen trip, five out of the six participants hesitated on what to do next. They all ended up pressing “GO!” and most finished the trip, but there was lag time between landing on this screen and knowing what to do next.

Proposed Solution:
I’m going to remove the “GO!” feature all together. The full route will be in view the entire time with each ‘step’ of the clickable for more information. The trip progress will start automatically once landing on this screen.
 

Issue #2
The participants who pressed all the way through to the end of the trip, wanted to know when they should get off the bus.

Proposed Solution:
This is an opportunity to add a notification for when the rider is getting close to their stop, as well as when they need to transfer to another bus.

 

Next Steps
During this round of user testing, it became clear that I need to establish looser scenarios for my participants. So far, each of the flows has had a very specific scenario. Such specificity has been helpful in addressing immediate breakdowns within a flow, but has delayed the uncovering of breakdowns lying in the periphery. With this in mind, my next round of testing will involve scenarios that push heavily on the boundaries of the system.

Posted in Interaction Design, Methods | Leave a comment

Maps in the CapMetro App

In week 6 of our Rapid Ideation and Creative Problem Solving class, I’ve been thinking about maps. Maps are weird. They’re useful, but they’re also overwhelming. There’s a lot of information included in a map that isn’t helpful to me at a given moment (such as the names of streets I’m not using, for example). But maps are also comforting. For example, Google Maps is usually quite reassuring—it makes sure I know how to get where I want to go when I’m driving.

The students at AC4D are on our 5th iteration of redesign for the CapMetro App—the app provided by the public transportation system in Austin. Maps are usually important in transportation websites and apps, but I resisted using them before this current iteration. I wanted my redesign to be what the current CapMetro app is not—simple. The current maps of the CapMetro system are very complicated. So I tried to find ways around using maps at all.

However, in our in-class critique last week, we had a guest who has thought a lot about the CapMetro app and website. She shared with us that people expect to see a map when they open the app to find a bus, and they’d like to see themselves on the map, in terms of their position. It’s comforting to see that the app knows where you are, and gives you more confidence that the route it shows is correct and will take you where you want to go.

That made sense to me, and I experimented with adding a map into my latest re-design. The first map comes up immediately when a user taps “Find a Ride,” and pinpoints the user’s current location. Once a user picks which route he or she would like to take, the map zooms in to show step-by-step instructions about how to get to the bus, the arrival time, the number of stops, and how to get to the destination from the last bus stop. I now have a lot of screens with maps.

I tested this redesign by conducting think-aloud testing with 4 participants—strangers at a bar—to see if this design made it easy or hard for real people to complete a few pre-arranged tasks. Each participant had a different level of ridership with CapMetro. I asked each to think out loud, like a stream of consciousness, as they pretended to be using my app by tapping on paper prototypes of screens I had made so I could hear what they were thinking—what was easy and what was confusing—as they went.

One task I asked them to complete was to plan a trip form their current location to 800 Congress Ave. The map that shows up as soon as they clicked “Find a Ride” made it very easy for them to see where they were and they intuitively knew to type in their destination and hit “Go.” The subsequent steps of the trip were useful to some, but not to others. One problem I have with the CapMetro system in general is the amount of walking a rider has to endure. Coming from New York City, I never had to walk too many blocks before encountering a subway station. Here it’s different, and a bus stop can be quite a long walk away. Some participants only used CapMetro for the rail, which was close to their residences. Since I’m primarily a bus rider myself, it was interesting to hear that they had no idea why I’d include walking directions on the app. While most of the transportation system is still bus-oriented, the redesigned app will have to work for both bus and rail riders.

One interesting comment was from a participant who said he wasn’t sure he’d need to see a map once he got on the bus—even if he was a first time rider of that bus. He was pretty confident that the buses announce each stop with an audio recording, and that would be sufficient to know when to get off. That’s interesting, but something I will have to think through a little more since I’m not confident the audio would be enough to know when a user is approaching his or her stop. If a map is not necessary at that point, however, there would be room to add other, possibly more relevant information, such as time to arrival at destination or traffic information. These ideas will need to be considered. The maps he was talking about are circled in red on the flow below.

IDSE201_wk5_wireframes_blogv3

Other changes for next week’s iteration, based on feedback and testing from this week, will include (again) increasing the realism and fidelity of the visuals and making the functions in the Account section much clearer and easier to navigate. The full set of wireframes is included below, as is an overview of the whole redesigned CapMetro app, represented by a concept map.

IDSE201_wk5_wireframes_blog1

IDSE201_wk5_wireframes_blogv2

 

Redesigned CapMetro app concept map:

IDSE201_wireframes_map_wk5

Posted in Methods | Leave a comment

Reiterating Simplicity: CapMetro App Redesign, Week 4

When our class began the assignment to redesign the CapMetro app (app for the public transportation system in Austin), I think we all wanted to make the app simpler to use. But simplicity means different things to each of us, whether it’s making an app that does just one thing very well or adding different functions to help users. This week I worked through the design again to refine what I mean by simplicity. In this iteration, the overall concept for my version of the CapMetro app centers on 3 sections: “Find a Ride,” “Pay Fare,” and “Account,”  with a chat function as an equally important but less-visible component.

IDSE201_capmetro_map_wk4

After several sessions of feedback, critique, iteration, and user testing, I’ve heard a lot of opinions about what people would like in the app I’m redesigning and not all of it is consistent (which is to be expected). So this week it was time to be selective in what to focus on for this iteration of wireframes. Some things I worked on included the following:

Increase fidelity. Last week, some people missed aspects of the functionality represented in the wireframes because it was hard to tell what was a graphic element and what elements indicated actions.

IDSE201_wk4_blog1

To address too-low fidelity, I put the screens in a phone silhouette and gave buttons dimensionality. It’s not beautiful, but users can understand what it does. I also tried texture on a screen to indicate a hidden screen underneath. Simplicity isn’t necessarily visual minimalism. In this case it’s more intuitiveness of function.

Rethink the navigation structure. In an effort to make screens as simple as possible, I was creating confusion by hiding sections of the app behind a hamburger menu in iteration 2. Paradoxically, my efforts were making things simpler to look at, but more complicated to use. At this point in iterations, we should be focused on use as much as possible.

IDSE201_wk4_blog2

I took away the hamburger menu in favor of adding a button to the home screen and adding a global button to “chat” up in the header. The additional button on the home screen still isn’t my favorite solution, but it’s actually simpler to have three buttons and no hidden navigation than two buttons with hidden navigation.

Particularly look at the “Routes” screen, in which users could select which bus to take after entering their starting points and destination. In my previous iteration, low fidelity created confusion around how to use the screen, and the information presented was unclear.

IDSE201_wk4_blog3

I minimized the information presented on the Routes screen and indicated more information with an arrow. It looks less like a “dial pad” now. I will continue to rework this to get the right amount of information presented when a user gets to this section of the flow.

Think about the payment method. In last week’s user testing, some participants were unfamiliar with the scan functionality I adopted to pay fares. In last week’s in-class critique, it was suggested that since the metaphor was backwards (usually a passenger has a ticket, which can be scanned, rather than the passenger scanning something on the bus) it might be confusing.

IDSE201_wk4_blog4

This goal will continue into the next iteration. I’m still thinking through the best and most intuitive way to make the scan system work.

For the next iteration, I’ll use feedback from tonight’s in-class critique and outside user testing to continue to simplify the app both visually and in terms of usability. The full set of this week’s wireframes can be seen below (click to view larger).

IDSE201_wk4_blogfull

 

 

 

Posted in Methods | Leave a comment

Week 4: The Cap Metro redesign continues

For the last four weeks we have been working on redesigning the CapMetro Public Transit smart phone app in our Methods course. A new tool to help us with the redesign process was introduced for each of the first three weeks.

The first week we created a concept map of the existing CapMetro app and a concept map of our proposed redesign. A concept map is a tool to visualize the structure of a system to understand complex interactions that can not all be viewed simultaneously in the actual product. It is a useful way to think about emphasis and hierarchy as well as consistency before diving into the weeds of screens and interactions.

The second week we started wireframes. Wireframes represent the layout of a screen that focuses on functionality and interactions, rather than visual design. We also updated the concept map for our proposed redesign based on new ideas and feedback.

By 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 printouts of our wireframes. The user is given a task to preform 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 wireframe screens. If the participants stops thinking out loud the researcher says, “Please keep talking.” Otherwise the researcher does not answer questions or explain anything. Verbalizing what they are doing does not change how people approach tasks (although it does slow down the process), however, questions, especially those that require introspection, will change their approach. So, by just instructing the user to keep talking, the researcher gets the best representation of how the user would actually approach the task and what problems there are in the current system. Based on the problems users encountered we each identified 3 major problems with our design to address.

So, now it’s week four, and I’ve done it all again: Updated my concept map, iterated on my wireframes based on last week’s feedback, tested my wireframes with 5 users, and identified three major problems with my design that need to be addressed. Tonight I will present all of this to my classmates and professor, solicite feedback about resolving the issues I’ve identified, and then start the process again.

Below are the three flows that I tested. A flow is just a succession of screens that allow the user to achieve an intent. Not all of these screens are necessary to for each intent but hopefully they illustrate some of the major variations that are possible. The orange dot on each page indicates where the user taps, swipes or pinches to get to the next screen (pdf available at bottom of post).

tripflow_Artboard 7 tripflow-02Next Bus FlowRoutes and Schedules Flow

The major issues I found in my testing have to do with accessing the Next Bus feature from the home page (page1, 20, 30 in the flows) and how the Next Bus feature relates to planning a trip. Users weren’t clear on the difference between the two. The fact that on page 8 an identical box has a different function added to the confusion.

wireframes3_Artboard 7The other major problems occur on the trip overview screen (page 8).

1) Users thought the red line was the distance they had to walk, rather than the first bus in this trip. 2) Users did not realize that bottom section would pull up to reveal step by step instructions for the trip.

wireframes3-02

Trip Planning Flow Wireframes (pdf)

Next Bus and Schedule Flow Wireframes (pdf)

Concept Model (pdf)

 

Posted in Interaction Design, Methods | Leave a comment

Redesigning the CapMetro App: Iteration 2

We just wrapped up the third round of iterations for our redesign of the CapMetro app. I made changes to the design based on the feedback from user testing in the previous round as well as built out additional screens in order to have a more complete application.

As I said in my previous post, we are doing user testing to drive the iterative process. I didn’t go into much detail before, and am going to give you a little more insight into the process this go around.

FullSizeRender-2

Think Aloud Protocol

User testing allows us to assess the usability of the product. The kind of user testing we have been taught in class is Think Aloud Protocol. With this method of testing, you ask the participant to think out loud as they are going through the flow of the product to complete a specific task. It allows you, the designer, to gain insight into the thought process a person uses to complete a task rather than just focusing on the completion of the task. This way you can pinpoint where adjustments to the design are needed.

While some participants catch on immediately and verbalize their thoughts throughout the process, others tend to drop off after about 30 seconds. When this happens, simply prompt them to “please keep talking”– you’ll be met with a smile and a continuous stream of verbalized thoughts.

People get into it.

It’s pretty cool. It’s especially illuminating to hear the thought process of the participant as they are completing the task– most of the time in a way that you didn’t design for. I can say, first hand, that it works. People can describe what they are doing stream of conscious without it affecting the task at hand.

We’ve been testing our app designs using paper prototypes. This is an extremely affordable method that allows us to test each iteration early and often.

For the last two rounds, I’ve tested 5 participants each. I’ve found that only one out of the five participants has a radically different experience with a flow, wether it’s no issues or more issues compared to the other participants. In the next round, I plan on testing seven participants in order to evaluate the difference between sample sizes.

We were tasked with completing user tests with participants that we don’t personally know. Living in a college town, a little incentive goes a long way:

FullSizeRender-3

 

Now, onto what I learned this round.

Flow #1: Find a bus to Hole in the Wall (a local bar).

You can see the full flow below, with the green dots notating “ideal flow” and any red showing a breakdown and design rework opportunity.

The home screen was reworked based on the first round of testing where most of the participants were unable figure out how to enter in their destination.

(click image to enlarge)
Flow01-CapMetro-blog02

Issue #1
While each participant easily understood to click in the top section of the screen to enter in their destination, there were two participants that first clicked on their current location in order to get to the next step.

Proposed Solution: If someone clicks on their current location on the map, a small bubble should pop up with the option: “Plan a trip from here.”

 

Issue #2 & #3
Once seeing the map and route come back into view, each participant was looking for what time the bus was going to leave. It’s becoming apparent that once participants have chosen a “Trip”, they are no longer worried about how many total miles they will need to walk, nor the total trip time.

Proposed Solution: Departure time and arrival time will be the key pieces of information in the top bar. Also, if they click on the first bus icon, it will give them the specific bus info needed.

 

Issue #4
After clicking through the trip steps, one participant wasn’t sure how to stop the navigation sequence upon “arriving”.

Proposed Solution: Even though only one participant mentioned this, I think it’s worth considering. I feel like there should be a resolution to “end” the current process. This could be done with a notification that says something like “You’ve Arrived! Save Location as a Favorite Destination?” “Yes/No” > Home Screen

 

Flow #2: Set your home address as a favorite location.

Issue #1
This was a truthful moment. The star is not working as an initial gateway to accessing/setting a favorite location. It quickly became apparent that having two of the exact same icons in close proximity was confusing. Each participant’s knee jerk reaction was to go to settings. One participant wanted to push on his current location, assuming it was his home location, to set it as a favorite.

Proposed Solution: Managing favorite destinations needs to be located in the settings tab. The “destination” field should auto-populate frequent destinations once a user starts typing. There needs to be a simple way to save a location as a favorite.

(click image to enlarge)
Flow02-CapMetro-blog02

 

Flow #3: You’ve already saved your home address as a favorite destination. Find the bus you need to get home.

Issue #1
Compared to the first flow, the participants pressed the star pressed the star in the entry box. One participant pressed the star in the menu bar. While both option will get you to your favorites, it’s still too confusing.

Proposed Solution: The “destination” field should auto-populate frequent destinations once a user starts typing. For the next round of testing, I’m going to A-B test the location of the star.

(click image to enlarge)
Flow03-CapMetro-blog02

 

Flow #4: Edit the email you have listed in your account.

Issue #1
Having two options for editing the information in the account section wasn’t confusing, but the majority of the participants wanted to click on the email field first to edit.

Proposed Solution: For the next iteration, I’m going to make it possible to edit each field by clicking on it.

(click image to enlarge)
Flow04-CapMetro-blog02

 

Next steps
In the next week, I will be doing a third round of user testing which will include iterations of the above flows, as well as additional flows such as purchasing a ticket and the full setting options.

The updated concept map is below. The major change for this map is the ability to manage favorite destinations in the settings menu: (click image to enlarge)

Ideal-ConceptMap-CapMetro-Revised03

Posted in Interaction Design, Methods | Leave a comment

Testing CapMetro App in the Wild

This week our class began testing our proposed ideas for the re-designed CapMetro app. In order to get a sense of how people would navigate the app, I printed wireframes (revised based on our last in-class critique) on paper, and cut them out so they’d be one per page. I then conducted “think-aloud” testing with 4 participants at 2 cafes, some of whom accepted a $5 Starbucks gift card as an incentive. I thought it was just a little too time-consuming to expect participation for nothing, around 15 minutes per person. Think-aloud testing, where participants talk out loud through what they’re thinking as they test the app, seemed easier for some participants than others, but once users got comfortable with it, I was able to hear both their navigation decisions and some of their rationales. The overall concept map is represented here:

wireframes_conceptmapv3

The advantages of using mid/low fidelity images on paper is that, through testing, we’re able to see what aspects of the design give users trouble without investing a lot of time and money into developing the app first. The paper method definitely works. People navigate the app in surprisingly different ways, and problems quickly became apparent. The 3 most common and largest issues were:

1. Not using the menu icon: Only two main functions were shown on the home screen, all others had been hidden in a menu that appeared on the side when a user would tap the menu icon in the upper left corner. Most participants didn’t realize they could use this, leading them to try to accomplish tasks that were not built out through other buttons.

problem1

2. Using the “barcode” method was a novelty: This takes some explanation here. The current CapMetro app ticket is just a screen with a sheen animation. You show it to the driver and just get on. No scan or any other recording that the ticket is used. They just expire within a certain time period (for example, a day pass is 24 hours once activated). In order to create a system where CapMetro can still allow people to use tickets on their phones, but also so the company can track usage, I proposed putting a simple barcode in the bus, on the machine that currently accepts money for fare. I think it would be a relatively inexpensive solution that’s also easy for customers to use. However, I only know of one app from personal experience that turns the phone into a scanner capable of scanning a barcode. The scanner uses the iPhone camera to “look” at the barcode, and once it’s in focus, the phone recognizes the barcode and the next screen flows in. I don’t think this is a common function. One participant did figure out the mechanism behind the function. She talked through thinking the bus scans the phone to the phone scanning the bar code on the bus: “So I just hold my phone over it? […]I’m assuming I’d just use the camera on my phone.”

problem2

3. Problems with the “Route selection” screen: This screen consistently gave users issues, for different reasons. One is that they were not sure that they could click the gray bars that show each route option. One user did not like the order each variable went in, preferring to see the route number, then departure time, then duration, then amount of walk time. More than one user was confused about walk time—if it meant walking to or walking from the bus.

problem3

Overall I think the tests indicated that most of the app worked well, but also gave plenty to iterate on for next week. Regarding the 3 problems specified above, my to-do list includes:

1. The menu icon: I will need to enhance the visibility, enhance indicators that make the icon look “clickable,” find a way to include options that are currently accessible only via the side nav in the home screen, or some combination of these ideas to make sure users can access all features with ease.

2. The barcode scanner: I need to think about it a little more, and consider if it’s too foreign to use for a public transportation app. I still really like the idea, and the confusion may be a downfall of paper testing. Also, if users can “learn” the usage quickly, it might be ok to keep even if usage of the scanner is not immediately clear.

3. Route screen: Rethink the layout of the screen and information hierarchy. With increased fidelity, route options should look more “clickable” by employing a visual technique such as a bevel.

And…

4. Test some less-primary functions and flows a user may need. The questions I asked this week were around major tasks a user would want to do with this app. There are more minor tasks a user may need some of the time, and I will explore those as well.

The full set of wireframes may be viewed below*:

wireframes_v3_blog

 

*Note, areas that say “Keyboard” are a testing note. In think-aloud testing, a separate card with a iPhone keyboard on it was used to simluate a keyboard popping up when fields were tapped.

Posted in Interaction Design, Methods | Leave a comment