News and blog posts from our students and faculty

Category Archives: Methods

Summit: Pay it down while you live it up

“I’d like to pay off my credit cards as soon as possible because it is a cloud, it is something hanging over my head.”
–Carl, 32

Debt can be intensely anxiety provoking and yet we saw over and over again in our research that although the young people we spoke with recognize that their financial situation is causing them stress, and could be detrimental to their future, they continue to struggle to change their day to day spending behaviors enough to pay down their debt. Why is it so difficult for people to change their behavior when it comes to money? Why aren’t all of the myriad of existing tools addressing this problem?

 

Satisfaction Happens Now + Fear of Missing Out

Over the last six months, through a dozen in-depth interviews, intercepts and prototype testing, we’ve gained a deeper understanding of how young adults think about their finances, how they feel about their debt, and how they manage their current financial situation.

Blog_ResearchParticipants_Debt

 

Through our research two things became very clear:

1. There is no satisfaction in future benefits. We need to feel immediate value to be satisfied.

2. We want to make good decisions but fear sacrificing more than necessary.

“In the moment of choosing to buy something or not, it’s really easy to make that decision– yeah fuck it, I don’t care– I want this now, and then, oh I have to rein it in now, I have to pay this off.”
–Carl, 24

 

We found that people will make a budget or a plan at the beginning of the month — often using budgeting apps like Mint — in order to get their spending under control, but once they are confronted with daily spending decisions like whether to eat out for lunch or go out with friends, their budget goes out the window. There is a huge opportunity to create a solution that bridges this gap between long term goals and day-to-day spending.

 

Introducing Summit: Pay It Down While You Live It Up

Summit is a financial app that sends users friendly, contextually appropriate messages inviting them to send a little extra money from their checking account to the card they want to pay off, making paying off debt a daily activity just like spending.

Blog_HowSummitWorks
 

Summit Gets Personal

Summit leverages individual’s spending habits in order to choose the best times to send personally relevant messages inviting them to put money towards their debt.

Blog_MorningJavaMessage
 

Summit Reduces Anxiety

Looking at a large credit card balance can be overwhelming. That’s why Summit breaks down the user’s long term goal of paying down your debt into small manageable chunks, all while helping decrease the amount of time they’ll be paying their debt.

 

Experience Summit: Click on the image below to get a preview of interacting with the Summit app

Blog_IdealStateClickable
 

But…does it work?

Summit promises its users to reduce the anxiety caused by credit card debt and empower them to change their behavior and achieve a better financial future, but what is it like to use day after day?. In order to find out, we ran a small pilot using existing technologies to test Summit’s core interaction: sending users daily messages that allow them to put money towards their debt.

We piloted with 7 individuals over 4 weeks and sent a total of 124 messages– paying an extra $388 over people’s minimum payments.

Summit_Pilot
 

Before our pilot, we calculated how long it would take each of our participants to pay off their credit cards and how much interested they would end up paying based on their current monthly payments. At the conclusion of our pilot we ran the numbers again to see what effect, if any, our service had, and what effect it would have if they continued at this new rate.

 

The results were exciting:

Summit_BeforeAfter

Not only did everyone pay more than their minimum payment this month, but if they were to continue to use Summit, on average they would pay off their debt over 2 years earlier and save over $800!

 

Behavior Change

Beyond saving our users money and years of indebtedness, we also strive to help users change their spending behaviors so they eventually won’t need our service. After our pilot we spoke to all of our participants and asked them if using our service had changed the way they spent money that month.

One of our participants, Jacob, told us about a message he received just before lunch one day. He had brought his lunch to work that day — something he had been trying to do more often to save money — but that morning his friends decided they were going to go out for lunch and invited Jordan along. Even though he had packed a lunch he decided he was going to leave it in the fridge and go with them. As lunch time, approached he received a message from Summit asking him to put $7 towards his credit card debt which he accepted. As he put that money towards his debt, he decided to keep the positive momentum going and eat the lunch he brought.

This is the behavior change Summit seeks to bolster. Keeping long term goals top of mind and creating a cycle of small successes that helps people create their own positive financial future.

 

Going Forward

Going forward as we develop and launch Summit we will be looking for strategic partners who can help us make it a success. Our strengths are in understanding our users and telling stories, and will be looking for people with technical, financial and industry experience to work withus to make Summit a reality.

The Summit Team,
Samara Watkiss, Jeff Patton & Lauren Segapeli

——-

(Click below to experience the pilot)
Screen Shot 2015-04-17 at 11.45.09 AM

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

Summit: Ramping up for Piloting

Summit: Process and Next Steps

Posted in Classes, Design Research, Methods, Portfolio | Leave a comment

Tipping Point: One step back, two steps forward

Over the past six weeks, we’ve done six different rounds of user testing focused around concept relevance, messaging frequency and voice.

As a quick recap, here are the things we know:

  • There is a sweet spot for the tone of the app; financial enough to be credible, but also irreverent enough to be friendly and refreshing. We’ve been saying if our app got dressed, it would wear hip business casual.
  • We tested the idea of creating a light-hearted tone by asking the user to create a character that the user takes care of in place of taking care of debt or savings directly. That didn’t resonate particularly well with users, what was more compelling was the idea of doing things for your “Future Self”.
  • Users want some kind of progress report. The most compelling way we found to frame this is in terms of how much faster they are paying off their debt compared to if they just paid their minimum monthly payment and how much this will save them in interest.
  • Users appreciate a quick and light weight set-up process, but it needs to be balanced with enough visibility into how the product works so they can form a mental model.
  • So, going into this week, we decided to stop and take a moment to better understand our findings in order to focus our next round of testing.

     

    What is our Value?

    Defining our value statement, has helped us to better solidify and narrow down our next steps. In order to this, we asked ourselves some questions as provocation:

  • Why are we doing this? Why are we intrigued?
  • What are the types of things we want to come out of this for
    the people who use it? Is it serving that purpose? If not, why
    not?
  • The long answer:

    We understand that it’s hard to keep long term financial goals in mind when making in the moment spending decisions, that’s why Tipping Point will enable users to contribute to paying off debt or building up savings at the same time they are buying a new gadget, getting drinks with friends, or grabbing lunch on the go.

    We narrowed it down to the following:

    Tipping Point turns your spending habits into your saving habits.

    We will continue to revisit and revise this statement as we move forward.

     

    The Journey

    As a part of stepping back and reframing, we worked through the journey a person would experience while using Tipping Point. Focusing on how an individual feels before interacting with our service, at the moment of discovery, and through each touchpoint up until a goal is reached:

    FullSizeRender 30

     

    The customer journey map in conjunction with our value statement helped us reframe where we are in the process and focus our next round of testing.

    Moving forward

    FullSizeRender 25

    The goal for the next couple of days is to wireframe the setup process, along with more defined screens of what the day-to-day interaction will look like. We will be pushing these through scenario validations, think-aloud sessions, and intercepts. Through these testing sessions we hope to learn more about what works and doesn’t work as far as tone and frequency, and also start venturing into what works as far as setup and flow. Check in next week to see our latest insights!

    Posted in Methods | Leave a comment

    Recruiting Participants for User Testing

    We are three students in the Interaction Design and Social Entrepreneurship program. We are developing a service to help people balance day-to-day enjoyment of their lives with their financial goals of paying down debt or saving. (Learn more about our project).

    We have the idea, now we need your help to test it!

    We are looking for people to participate in user testing who are:

    • In the Austin Area
    • Between 22-30
    • In their first couple years of post-school employment
    • Making at least 40k
    • Have personal debt or are actively trying to save

    We will provide food and/or a small token of thanks. We will also share results of our study. If you are interested in participating please contact us.

    Thank you,

    Jeff, Lauren and Samara
    tippingpoint@austincenterfordesign.com

    Posted in Design Research, Methods, UX For Good | Leave a comment

    What is the Soul of the Idea?

    Last Saturday, Sam, Jeff and I narrowed down our three ideas to one. In order to do this, we had an honest discussion about which idea we were each most passionate about– that we truly thought would benefit the people we spoke to during our research.

    We excitedly settled on a service that, for now, we are calling “Tipping Point”. Throughout our research we found that amongst young adults ages 22-32, while financial literacy is lacking, what is doing the most harm is the inability to balance immediate satisfaction with future stability. Here are two of our key insights from our research:

    There is no satisfaction in future benefits. We need to feel immediate value to be satisfied.

    We want to make good decisions but fear sacrificing more than necessary. Because we don’t know how to balance these competing desires we avoid the situation or make rash decisions.

    With these insights in mind, the design idea must achieve the following:

  • Provide a narrative that supports users’ identity and ties together disparate financial actions into a bigger, motivating story.
  • Recognize that the value of money is personal and context specific.
  • Translate future benefit of wise financial actions into immediate satisfaction.
  • Tipping Point will be a service that uses someone’s habits of spending as a means to make a dent in their credit card debt. Essentially, using their habits against them. We created a storyboard to begin to think through the following scenario:

    Looking at his credit card bill online, Carl, a recent grad with a high paying job is overwhelmed by the amount of debt he has accumulated in just under a year. For the last couple of months, he’s made a conscious effort to start paying down his debt– he’s read blogs, followed experts on Twitter, but nothing has made a difference. Reflecting on this fact, he is frustrated that he has the knowledge of how to save better, but is unable to get his actions and habits under control. Knowing he needs to cut back on frivolous spending, he still wants to continue to enjoy his time out with friends.

    He sets up an account on Tipping Point, and chooses restaurants and bars as the places he spends the most money. During a night out with friends, when paying his tab he gets a prompt on his phone asking him to tip himself. Reminded of his goal, he excitedly tips himself 20%. Another message pops up congratulating him that he just paid $5 towards his credit card payment. At the end of the first month, he gets a summary of how much he’s affected his credit card debt, with some tips on how to continue to better make changes. Carl feels accomplished.

    StoryBoard-Carl02

     

    What is the Soul of the Idea?

    This is a question that we’ve had to keep close to the heart every day this week. Sitting down and working through how to “smoke and mirrors” this together in order to test the idea with real users, we hit roadblock after roadblock.

    We started by crafting an ideal service map which we then broke down into a more lo-tech option to essentially hack it together. We did hours and hours of research between the three of us to find a service, pre-paid debit card with notifications, to get as close to the real experience of our idea as possible.

    IMG_59050-2

    We realized we were trying to hold our test too true to the actual idea. After much discussion and guidance from Matt, Jon, and Scott, we realized we need to step back and ask ourselves:

    “What is the soul of the idea?”

    Instead of focusing on the technology piece so much, we began to focus on the human piece. How does the idea feel?

    We are working through the tone and ideal scenario and drilling down into each moment to better craft the service. Really focusing on feeling and staying away from too many technical terms. From our research, we found that there’s a lot of frustration around not understanding finances, about not being able to change personal spending habits, which are both causing decision paralysis.

    IMG_6145

    As we craft the tone of our service, we are keeping in mind the need for it to lighten the cognitive load of feeling trapped by personal financial situations and how this can manifest in the details.

     

    Out of the building and into the wild

    The more we discussed the tone of the service, the more questions we had about what the service really is.

    Do we do away with the reality of the money and layer a story of keeping a fictional pet or possibly your future self alive and healthy, Tamagotchi style? Are the pings transaction-based, time based or location based? How often is too often to get notified about spending?

    The only way to move forward from here is to start answering these questions, and the only way to get some answers is to get out of the building.

    After playing out different scenarios of how the service would work, we sketched super low fidelity screens onto note cards.

    tippingpoint-test02

    tippingpoint-test03

     

    Then we put them in front of people:

    tippingpoint-test01
     

    The screens portrayed different personalities for the service. One set was very straight forward, prompting the individual to throw $10 at her credit card. Other screen flows were more humorous with a character named Melvin playfully nagging you to buy him a six pack as a mask for paying down your debt.

     

    Keep it simple. Keep it fresh.

    The simplicity of prompting a person to throw a specified amount to their credit card was easy to understand and easy to act on, while anything showing a percentage was too overwhelming and not as satisfying. We learned that too many prompts in a short time period would elicit reactions like “…at some point, I’d start hating Melvin.”

    The importance of how the service manifests in the details became incredibly apparent during this round of testing. Playful surprises from our very lo-fi screens were well received. One guy even said, “I want to see what Melvin does for $7.00!” Another participant even began to joke around saying, “You drink tonight, Melvin. I’ll stay in.”

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

    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