The Problem
As a part of my apprenticeship, we were given challenges in addition to client work every two-three weeks. The challenges covered a number of topics, including UX discovery and strategy, front-end development and accessibility, and UI design. One of our later challenges was to design a native mobile app for iOS to help Boston public transit commuters get to work on time.
While there are plenty of transit apps out there, none of them really focus on getting commuters there on time. Google and Apple Maps come closest, but don’t have up-to-date information on Boston transit. If you’re juggling a complicated or multi-step commute, especially going between the T and buses, there isn’t an efficient or easy to use way to track your trip other than to frantically switch between global and local apps.
Some specifics on what our apps needed to incorporate:
- Retina graphics (which essentially came down to designing at 2x)
- The assumption that we have an awesome back-end dev aggregating all available MBTA data
- Alarms to let you know when you need to leave to catch your bus
- A way to let the app know how urgently you need to get there by your stated time (“I absolutely need to be at work at 9 for a meeting” vs. “it’s okay if I get into work a few minutes late”)
Within this challenge, I was given an additional mini-challenge from my mentor: don’t use any white, grey or black.
My Process
I started my app design by researching what apps exist in the market already. I looked through some of the big contenders — Google Maps and Apple Maps — in addition to smaller apps like Embark, HopSpot, MBTA Transit Guru and HERE. I tried to figure out what they did well and what they were lacking.
After doing my competitor audit, I started brainstorming, sketching and wireframing. I used POP for some quick prototyping to help me wrap my head around the flow and interactions. It was a really great tool to help me jump from paper to product.
About mid-way through the challenge, I brought my prototype to our program leader for feedback, where he promptly told me to get rid of most of it. I was trying to be too big, he said, and in order for my app to successfully complete its goal, I needed to strip away everything extraneous and focus on the alarms. I wasn’t trying to compete with Google Maps, I was trying to supplement it.
So I went back to the drawing board. I started cutting, focusing totally upon the process of adding and using the alarm function. My app was much stronger after narrowing down my scope.
Once I had some functional wireframes, I brought it into Photoshop and started pushing some pixels. I wanted to give it an “almost-flat” aesthetic. I struggled with colors for a little while, before finally pulling my colors out of my mockups and into their own palette file to allow me to see how they interacted with each other. That gave me better perspective into how they fit together, and I was able to refine and come out with a significantly more harmonious and sophisticated palette.
I’m pretty satisfied with how the app ended up coming out. I received plenty of great feedback during my challenge critique, which I used to refine my designs further. I’m still missing some screens that I would need if this was going to be developed (namely, my “places” and “options” menus), but what I presented accomplished its goal of creating a way to set alarms for your commutes.