News and blog posts from our students and faculty

Category Archives: Methods

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.


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.


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.


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.


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.


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).





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.


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.


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:



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)

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)


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)


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)


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)


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:


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.


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.”


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.


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.


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*:



*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

Redesigning the CapMetro App: Iteration 1

In our quarter two methods class, our first assignment was to use and evaluate the current CapMetro app in order for us to have a thorough understanding of how it works, identify where it breaks down and evaluate how it can be made better.

After much frustration and getting lost in the trenches, I created a concept model of the app as it currently is in order to illustrate the complexity and identify the breakdowns:


When looking at the concept model, you’ll see that the app has a very confusing hierarchy where the most important action is to buy a ticket. There are multiple redundancies and it’s difficult to navigate once you get two steps into any process. Not to mention, good luck trying to figure out which bus or train or shuttle you need to ride.

Immediate Breakdowns:

-Difficult to navigate
-Redundancy of menu items which causes confusion
-No way back
-Inconsistent naming conventions

With these breakdowns noted and after a full immersion into the app, I stepped back and created a new, “ideal” concept map. (I use the term ideal loosely–this is an iterative process and much work and investigation is in my very near future.)


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

All of these actions are intertwined which is something that the current CapMetro app fails at supporting. My goal is to successfully integrate these use cases in a streamlined manner.

Here is a first round of wireframes that addresses the surface level experience of finding a stop near you based on your final destination (click to enlarge):


I had the chance to run the first flow through some user testing and identified a couple of key issues. It was my first time actually conducting user testing and it was so illuminating and slightly awkward. The method of testing we have been taught prompts the user to think aloud while going through the flow. At first people were unsure, but soon got the hang of it and began to tell me what was easy and made sense as well as what they were looking for when they didn’t know what to do next.





Next steps
After iterating on the above changes, I will be doing a second round of user testing which will include a couple more flows, including the one below. This second flow demonstrates what happens when you click on a bust stop to find the “next bus”. I have two flow options illustrated and will user test both, so stay tuned!

(Click to enlarge)

Posted in Methods | Leave a comment

CapMetro app iteration

This week in our Rapid Ideation and Creative Problem Solving class, we are on our first iteration of wireframes for the improved CapMetro app, and in my case, my first experience with creating wireframes at all.

To get from concept map to wireframes, we were asked to go through a process of taking the critique from last class, revising the concept map, writing scenarios, drawing a storyboard, and creating wireframes as sketches, then in Illustrator. Going through all these different ways of thinking about a problem certainly helps fill in gaps in the solution from several angles, although in my case I didn’t follow the path linearly. It’s helpful for me to move back and forth between methods.

My concept map shows minor changes, but there were a few points from last week’s critique that I spent the most time on in this iteration. The biggest one was that several of my classmates were interested in taking the approach represented by my first concept map that allows passengers to add fare without having to buy a ticket every time.However, it was noted that the current system allows for discounts if you buy 7- or 31-day passes. Always being charged for a day pass would quickly get expensive. I proposed a solution based on a punch-card system, where every 7 rides would result in credit back to your balance to be used on future rides. This solution takes care of both the cost difference in buying day passes and 7-day passes, and also ensures that your fare doesn’t expire, as it does in the current app (in the current app, once you “activate” a ticket, you have a limited time to use it). I think a punch card is easy to understand, and the additional benefit is that riders may feel “rewarded” for riding several times.

Here are my first iterations on wireframes (continued after the image):


Some things I want to think about for next time are how to visualize the very complicated route maps of the CapMetro system in a rider-friendly way. See current CapMetro map here. I also think there is opportunity to simplify several functions in my concept, such as in the Find a Ride sequence. I also took the approach of creating wireframes assuming the user has already used the app, so first-time setup screens, such as adding a credit card, will need to be explored. For the next iteration, we are asked to conduct Think-Aloud user testing, which will help guide the app in the direction of better useability.



Posted in Methods | Leave a comment

Creating Innovation from Convergent System Differentiators

In the Richardson Book Innovation X, Chapter 4 begins leading the reader through the complex yet fragile system of Convergence. Convergence in the past has been used, yet not heavily defined, by the action of such areas of combining media. Repurposing media for TV, Web, and mobile phones. Richardson uses the example of individuals contributing self-made videos that become a bigger part or a larger advertising campaign.

Here however, Richardson defines convergence as the means of integrating “multiple products (hardware, software, and services) and customer touchpoints to provide functionality, benefits, and customer experience that would be impossible in a stand-alone product.”

In this case an entire ecosystem is needed to house all the components of the system with well-defined touchpoints that create a seamless and delightful user experience. An ecosystem defined by being a collection of products, technologies, and other specific components that together create the functionality of the offering. Touchpoints then are described as being all the points where “customer and company intersect over time, from a customer being aware of the company’s products, to buying and using them.”

Below is a Concept Model describing my depiction of a general generic model for a convergent system.


However… through all the examples and definitions of seamlessly convergent companies able to operate and integrate multiple elements of technology and product on page 106 of Chapter 4 in the book, Richardson introduces us to the first divergent opportunity for something new and innovative that could potentially break a companies well defined convergent system. The concept of sustainability.

He states that “sustainability is increasingly a competitive differentiator, as well as becoming necessary for regulatory compliance. Knowledge of how to achieve sustainability in a given industry will be a prized capability.

In order to achieve sustainability a company may have to go through a massive series of ecosystem changes, affecting customer touchpoints, and perhaps adding, in the beginning, more work and an actual monetary loss from the company in order to meet the new standards the company may choose to institute to be considered “sustainable”.

So in an effort to derive new an innovative ideas from Richardson’s concept of convergence, sustainability as a game changer immediately gathered my full attention. The first thing to come into mind was the electric car combined with the convergent system of a company like Car2Go. However upon further research Car2Go actually has become aware of this deviation and offers in very few places the infrastructure changes necessary to support a fleet of electric vehicles to support these vehicles both on the consumer and company side.

So what about upping the ante? What about now using Richardson’s suggestion of sustainability often resulting in the combination of multiple companies to create a broader product offering? What about Car2Go and Tesla?

The introduction of a fleet of electric vehicles that are not simply electric vehicles for utility, but now a fleet of high performance on demand vehicles people may just use for a night on the town? Or to get the chance to “test drive a Tesla”. Granted this idea completely changes the entire ecosystem that would even be placed on the current electric car offerings that Car2Go offers.

I unfortunately do not have a definitive solution for how to create a new perfect Ecosystem for something like this to happen but I can imagine that it would begin with first: Convincing the Tesla company that a car share program is not only great for both companies but will boost the image of Car2Go from necessity to luxury, and Tesla to brand evangelicalism by offering a potential not yet customer to absolutely have to have one of these cars one day.

The companies would have to integrate the Tesla recharging station model, as well as offer specialized maintenance, and a higher premium resulting in a completely new customer billing structure. I imagine much of the existing infrastructure of “checking out” your Car2Go would remain in place, but much would change. I would love to see this happen.

Below is a chart of my idea of what could happen when a company like Car2Go decides to change its infrastructure and go “Super Electric”. As you will see the company first begins smaller in its current comfortable state of convergence. But then the idea of becoming sustainable by being more environmentally friendly is introduced and the fragile tower (here expressed as a Jenga game) begins to tumble as things fall away and established touchpoints break as the ecosystem changes.

If and when the company can re-establish a new set of systems, a new convergence, that works with sustainability (and Tesla) they not only lower environmental impact, but expand product offerings, parter with new and exciting technologies and gain a real competitive edge. Click the image for the full resolution and details.

Graphics & Diagrams by Crystal Watson and William Shouse



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

CapMetro App Revamp: Iteration 1

Quarter 2 has begun! This first blog post comes to you courtesy of our “Methods” course which is entitled “Rapid Ideation and Creative Problem Solving.”  For this class we will be presenting a new iteration on the same design each week.  The design we will be iterating on each week is the existing CapMetro App which is the official app of Austin’s public transportation system, and allows bus/rail/shuttle riders to buy passes, plan trips, view maps & schedules and see when buses will be arriving. This week we are creating two concept maps:  A concept map of the existing CapMetro application and a concept map of our revised iteration.  A concept map is a visual representation that simplifies the parts of a system in order to allow for a better understanding of the  organization and boundaries of the system as a whole.  To start this process, the first thing I did was take screenshots of every screen and print them out.  I labeled each screen with a unique name and then pinned them up on the wall in a logical order.  See here. From this I created an “As-is” map of the current system (click image below for a closer look): CapMetro(AsIs)10.29.14

After completing this map, some things started to stick out to me that could be improved upon:

  • The Route Maps and Schedules should be combined since both options take you to the same place and the toggling mechanism (allowing you to switch from Maps to Schedules or Schedules to Map) should be more obvious.
  • Planned Trips should automatically be saved in a history instead of requiring the user to manually save a trip as a “favorite.”
  • Tickets should automatically be saved to the “cloud” with the option to save to a device instead of making the user choose between two “Save to the cloud? or to your device?”  which is probably confusing to many users.
  • The online ticketing system is overly complex;  Requiring the user to manually activate a ticket prior to use (in order to start the clock on the expiration date) is confusing and unnecessary; The ticket should activate when it is first used.  Requiring the user to activate the ticket, tap the code, and then present the code to be scanned by the driver is way too many steps for people in a rush to get on a bus.  If and when technology permits, this system should utilize nearable technology so a user can pay their fare just by tapping or waving their phone near a reader.
  • There is confused terminology on the app.  The words “Tickets” and “Passes” are used interchangeably, and “Terms and Agreement” takes you to a “Terms and Conditions” page.
  • Having written turn-by-turn directions of every route is unnecessary, and better presented in map form.
  • The Index menu presents options that already exist on the home screen.  To simplify it makes better sense to remove the duplicate options, and just provide a clear path back to the home screen.
  • All pathways need a clearer path back to the home screen.
  • Pressing the back button should move the user back one level, not ask if they want to quit the application.
  • The Settings and More Info menus feel like catch-alls instead of meaningful buckets.  Many of the “Settings” could be nicely combined into one “Account” screen.  The “More Info” should combine “Phone numbers” and “Contact Customer Service” into “Contact Us”.

These realizations lead me to create my first iteration in the form of the revised concept map seen below (click image below for a closer look).


Thoughts?  I’m specifically looking for feedback on the clarity of these models and the revisions I chose to make/not make.

Posted in Classes, Methods | Leave a comment

Map this app

Some things are complicated. Take the CapMetro app, for instance. The CapMetro app is presented by the CapMetro public transportation system here in Austin, and is responsible for communicating vast amounts of information to CapMetro riders, including bus routes, schedules, ticket prices, ticket purchases, detour information, and much more. In order to understand the CapMetro app in its entirety, our Rapid Ideation and Creative Problem Solving class is working on creating Concept Maps. Concept Maps are visual representations of systems that simplify the system in such a way as to make it more comprehensible, more quickly. This is important for us as designers as we begin to think about constructing systems, and important for the people to whom we show our ideas, so that they can make sense of this complex information, too.

We’ll be mapping this app several times over the next few weeks. The Concept Maps here are first-pass iterations, done rapidly over the past 48 hours. The first two represent the system as it exists today. [Continued after the maps, click to view larger.]



The last Concept Map represents my ideas for optimizing usability at a conceptual level. These ideas will continue to improve over the next iterations. [Continued after the map.]


As early observations, I think that trip planning, schedules, and next-bus information all share the goal of getting riders information on the optimal route and time for their travel. That commonality leads me to believe there are ways to consolidate that information, as you can see around the “Find a Ride” bubble. Secondly, the current CapMetro app uses phone numbers to handle any problems or breakdowns in the app or in service, which necessitates leaving the app to dial. A chat function within the app could streamline customer inquiries, and I think would probably take up less time for CapMetro than fielding phone calls. Lastly, while an overview of the system and route maps are necessary, they are difficult to read and comprehend on a small phone screen. I think there is a potential to use the stops themselves to better handle large-format route information, perhaps in conjunction with the app. Going forward, I also would like to consider the app payment structure to make it easier and more enjoyable to use. If you have thoughts on optimizing this app, please feel free to comment, especially since this is an ongoing project!


Posted in Interaction Design, Methods | Leave a comment

Wash, rinse, repeat

Our second quarter methods class is called Rapid Ideation and Creative Problem Solving and rapid it is. We started Monday night; were informed that we would iterate on the same assignment 7 times over the the 8 weeks of class; and told the first iteration was due Wednesday. The project is to redesign the smart phone app for Austin’s public transit system known as Capital Metro.  Each successive iteration will tackle a finer level of detail and require a higher level of fidelity. For the first iteration we are not focusing on screens or specific functions at all. Rather we are creating two concept maps: one of the system in its current state and one of our vision of how it could be improved.


Based on mapping the current system I identified the following high level problems, questions and opportunities I would like to explore in my proposed redesign:


Schedules and route maps are treated as separate sections when in fact they are just two different ways to view information about the transit services.

Notifications, service alerts and latest advisory all seem to present the same information.

Treating all intents the same

The Capital Metro app currently caters to three different intents. The first is a slower paced intent that involves browsing available services to plan a trip or look at a schedule and route. The next is a more focused information-finding intent, when is the next bus coming to this stop? Finally, is an action oriented intent, I want to purchase a ticket. It is easy to imagine a narrative where these intents lead from one to another or narratives in which each exist independently.

What if each of these intents was supported by its own app that integrated seamlessly with the other two, but could also be used on its own for a more streamlined, uncluttered experience?

Not integrating with other tools 

Do users want an other trip planning tool or if they want to use whatever they have been using (in my case Google Maps) and have it connect to Capital Metro’s database and applications? What if you could use google to plan a trip in the public transit option and instantly compare it to the the database used for Next Bus (which uses real time data tell you when the bus will actually arrive rather than just what the schedule says) to improve the fidelity of Google’s projected time and transfers? What if after finding the route you want using Google I could go seamlessly to the buy a ticket for the route? What if Capital Metro could access the locations you have saved in Google Maps?

The Capital Metro app is already using GPS for the users current location in some cases. How can this be better utilized?

Other possible points of integration: On your calendar to see when your week or month pass expires?


PDF of concept models: CAPMetroReDesign1

Posted in Interaction Design, Methods | Leave a comment