I was recently asked by a potential employer to take a 7-day mobile app design challenge where a hypothetical problem was presented(below). This article outlines how I handled the challenge. Granted one week is not very long, my hope is that future employers can explore and appreciate my end-to-end product design process here.
My design response required 4 primary deliverables;
- Documentation of challenge research / analysis
- Sketches / Whiteboards / Storyboards
- Mock-ups / Wireframes
- InVision prototype or similar
The design brief:
A 26 yr. old traveling salesman in NYC frequently misses important sales meetings, usually because of unpredictable public transportation. The primary factors include weather, overcrowding, peak traffic, and “other general delays.” The financial cost of missed meetings negatively impacts his quality of life.
Assuming you have access to a repository of public transport and systems data, design an app that will aid AJ’s to efficiently coordinate his use of public transport. Additionally, assume you have access to public transportation APIs, embedded mapping software, the user’s calendar and machine learning technology.
There were 3 primary phases to my challenge response:
- Research / empathy
- Create / shape
- Prototype / Test & learn
1. Research / Empathy
My personal context
I will start with my personal context since I spent 11 years without a car between San Francisco, Melbourne(Australia) and Paris(France), almost always relying on public transportation. I used many apps including Google Maps, Waze, NextMuni (SF) and TramTracker (Melbourne). I learned quickly to estimate travel times very conservatively in order to be on-time. After spending more than a year in each one of these cities I also began to learn about traffic patterns, as well as which lines were especially unreliable (SF muni’s N and J trains are the worst!).
Experience map:
The very first thing I did was write down a list of primary stakeholder factors. I would keep this close the next few days and consider how all factors might impact new ideas I may come up with.
User Interview:
I immediately thought of real sales people I could talk to for a better understanding of what it’s like hustling between important off-site meetings. Since I am rarely late myself and not in sales, I craved more context of AJ’s situation.
I conducted a 20 minute interview with a friend Connor C. Who has been in tech sales for about 6 years between two primary companies. I wanted to ask what apps he uses for work, and also get a better understanding of his entire experience around conducting a sales meeting.
Key take-aways:
• Connor loves Google Maps
• Usually for in-person meetings he has already been in contact with one or two people at the company. This is an opportunity for them to bring in more of their team to meet and educate about the product utility.
• He likes to send branded ‘swag’ sometime ahead of a meeting as there is less pressure on the client in person. Client’s still appreciate gifts on their own time and it tends to make his in person exchanges more relaxed.
• He brings in coffee/pastries or even lunch depending on client preference.
• He tries to start his presentation with discovery questions to get a feel for the client’s existing system/solutions and the possible pain points that his offerings can address.
• He may use a slide deck for very high-level explanations of the services.
• It’s nice to have a meeting agenda, ideally shared with clients ahead of their meetings.
When I described AJ’s situation, Connor laughed and said that no good salesman would last very long if they couldn’t manage to arrive to meetings on-time. He felt that AJ mostly just needed better time management.
Challenge / Solution Definition:
From the brief:
AJ often fumbles sales opportunities due to unpredictable conditions and transportation (weather/traffic/other).
I see four high-level solutions;
1. Predict public transportation better
2. Alternate transportation (may cost more than public transportation)
3. Bring the meetings to AJ
* Requires facility
* Less control of attendance = less certain effectiveness
4. Host virtual sales meetings online
*Less personalized experience = less effective to yield larger sales opportunities
The ReadyRide approach and basic app description:
To help AJ get to his sales meetings on-time, a mobile app can use real-time data on public transportation routes to address his departure timing problem. It will factor in historical trends about ridership and can also recommend alternative transportation options ranked in order of price.
Given problem/solution and app function, I’m going with the name ReadyRide (Abridged below as RRapp).
The app’s character should include a theme of Simple / Smart / Fast.
Storyboard Scenarios:
Telling good stories is one of the most critical parts of design. In ideal situations I create a “nightmare” scenario involving the challenge and a “dream” scenario involving the solution.
1 — User Fail Scenario
To get more familiar with AJ’s challenges I wrote a quick failure scenario where AJ loses sales opportunities because of time management and transportation issues.
2 — App Success Scenario
Now a full-success scenario inserting RR app in order to help AJ avoid some of the pitfalls he faced in an unfavorable scenario.
2. Create / Shape
Brainstorming / Ideation:
Design brief considerations
A. I had an early question about if I should lean towards lofty futuristic concepts or stick to something practical. I chose to go with the most simple and practical approach I could. I wanted to develop something a good dev team could build quickly without issue today.
B. With my own abilities to navigate public transportation, I also gathered from the brief that AJ’s primary issues stem from poor schedule management and or very liberal and inaccurate commute time predictions. With this in mind you will notice I am not designing a new mode of transportation, but rather a weather/traffic aware scheduling & reminder system that will present AJ with his most timely and realistic transportation options.
UI Feature ideas
- Schedule views that considers transportation (between locations)
- Multiple routes between meetings
- Transportation delays
- Peak traffic times
- Other common issues
- Schedule view that considers weather given locations & times
- Connections to ride-sharing alternatives (Uber/Lyft)
- Map view of schedule
Contextual Feature ideas
- Location awareness
- Weather awareness
- Meeting attendees
- Calendar inputs (sync)
- Transportation preferences (filters)
- Notes (for agenda and other)
App Design Inspiration
- Google Calendar
- iClock
- Airbnb
- TripAdviser
- Lyft / Uber
Technical considerations
For the purposes of this design, I assume all features included are feasible with the help of a top engineering team. Specifically, this app will include custom usage of a few APIs including weather, maps, public transportation, and ride-sharing apps. Always run things by your actual users! How do my feature ideas impact the actual users?
Original Wireframe:
Early Ergonomic Screens (Sketch):
Lettering and colors:
I liked the colors orange and red for their sense of urgency, but I figure these can accent a cooler more professional set of blues.
Icon & Navigation evolution:
A critical part of any app experiences — I began with simple and familiar shape outlines shooting for general legibility. Next I moved to more distinct shapes focusing on positive and negative space within a more bold style. Next I added a color splash version. Finally, I began filling out the app screens and realized I wanted the icons to sit inside a blue nav bar. I rendered the symbols in primarily white for this, bringing back the feel of a bold negative space.
3. Prototype / Testing +
I saved the last two days of this project to work on the prototype. By the end of the navigation bar creation in Sketch I was well on my way to developing an app prototype with Sketch + InVision. I was able to complete a thoughtful first version in one day, but then I ran a usability test with a friend and discovered valuable home-screen modifications worthy of immediate implementation.
I ran only one user test of the prototype on the day before finishing this project. Although this presented much more work to be done at the last moment, I learned invaluable ways to better express my original vision.
At this point I would create a final design doc with hi-res design mock-ups and call it a wrap. Although the design brief never called out the critical graphic design element of this project as a deliverable, it goes without saying that any proposal for a design related project had better showcase moderate to expert levels of graphic design capability. This design document removes the research process and is another chance to elaborate on the designed solution app functionality.
Check out the final app design PDF here — http://alexwyrick.com/ReadyRide-design-sample-min.pdf
InVision App prototype demo —
Next steps for a project continued:
Finally, I wanted to explain what I would spend more time on if this were a real project I was responsible for seeing all of the way through. In short, some less primary features were somewhat ignored in my prototype due to time constraints, so I would start with those and continue the test and learn cycle.
- Design the contact page
- Further develop the maps pages
- Add InVision screen transitions and micro animations for a smoother prototype feel
- Continue testing and iterating!
I would like to continue testing the updated screen versions, and in the future I would work on split testing many other things, starting with the on-boarding screens.
Conclusion
This was a very fun and rewarding challenge. Projects this time-intensive and thorough require you to push yourself to make tough decisions about what is worth exploring. One thing I am especially grateful for was finding a friend to test my prototype for 5 minutes before retooling a final version to submit. Challenging your designs before calling them final can be an incredibly eye-opening experience . It also presented me with a perfect opportunity to show that I could continue to achieve critical improvements without the presence of direct feedback from highly experienced design managers.
That’s it — thanks for reading! I will likely have to defend the contents of this article in an interview and so I’m happy to hear any feedback in the comments below. 🙌
