An in-depth walk through of my very first product design take-home challenge.
As part of an application for a Product Designer role, I had to complete a take-home design challenge. For those unaware, a take-home design challenge is typically a fictional design brief, set by the prospective employer to understand how you approach and solve design problems. The outcome itself is not important. It’s all about showcasing your problem-solving process.
Before I started, I frantically searched online for other step-by-step guides that would inform me on how best to approach it. The few I did find were invaluable.
So, in this blog, I will help the other beginners out there by giving a complete walkthrough of the brief, how I approached it, and the steps I took.
Ultimately, I was too inexperienced for the position. The hiring manager — also the Head of Design at the agency —explained they were “looking for a candidate with more direct client and product team experience”. Fair enough.
My response to the design challenge was far from perfect too. Among other things, he explained that “when it came to implementing these (my ideas) into the prototype, there was a little bit of a disconnect where I felt like you got distracted by a mixture of design patterns that already exist”. (I’ll share his detailed feedback at the end)
But he added he’s “seen some seasoned designers turn these around with less” and “thought on the whole it was fairly well put together and for your first challenge response, fantastic”.
Therefore, I feel comfortable sharing my approach, despite the fact it didn’t land me the job. ‘Fantastic’ for a first time means it could be valuable to someone else.
The Challenge Brief
The brief itself (sent in a Google Doc via email) was a bit long and confusing, and would take up too much space if I copied and pasted it here. So I’ll summarise the crucial elements.
Arrival has decided to challenge Uber & Tesla by combining its growingly affordable electric vehicle technology and the market potential for ride-share services. By using their ground-breaking driver-less autopilot technology they can produce a fleet of safe, short range vehicles to operate as transport for hire.
Design an app for a new electronic, driverless ride-sharing service from Arrival, using Human-Centred Design to justify your design decisions.
- Identify 3 x use-cases
- Prioritise 1 x use-case and create a detailed user flow
- Create wireframe of most important part of that flow
- Design the primary interface screen(s) in high fidelity
- Don’t just copy how Uber etc provides their services
- Think about alternative ways to improve on the ride-share experience
- The branding should evoke the style of Tesla
I mentioned that the brief was a bit confusing. So — as it was my first ever take-home challenge — I read, read and re-read it. Then I read it again. I added it to a notion page, where I added highlights and bold text, to help me understand what was expected. I also pulled out the deliverables — which were spread across 4 different paragraphs — and synthesised into the 4 bullet points you read above.
“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions” - Albert Einstein
The brief mentioned I must use Human-Centred Design (HCD) principles in my approach. This was helpful because HCD has a clear step-by-step framework and would provide the road map to solve the problem.
HCD has 3 key steps, which I used to direct my approach.
- Discover: research the problem and find people to talk to about the matter.
- Ideate: using the information you’ve gathered, use creativity to think up solutions.
- Prototype. turn the ideas into tangible designs.
I then spent (a lot of) time thinking about and identifying where best to tackle each of the deliverables within the HCD framework. Where did it make most sense to address them and why? The problem-solving process can be very vague and unclear, so this was a crucial exercise because it provided me with clear mind and a defined plan.
The plan looked like this:
- Research (Goals, user survey, competitor analysis, desktop research)
- Synthesise (Emerging themes, empathy mapping)
- Define (How Might We?)
- Identify 3 use-cases (Deliverable 1)
- Prioritise 1 use-case and create a detailed user flow (Deliverable 2)
- Wireframe most important part of the flow (Deliverable 3)
- Design the interface in high fidelity (Deliverable 4)
Step 1: Discover
The first thing I had to do was immerse myself in the problem through research. I wanted to think about: the problem space, the users (their goals, wants, needs), and the wider the competitive landscape.
To help focus my discovery phase, I set myself two research goals:
- Learn as much as possible about our potential users. Who would actually want to use a product like this? What are their pain points, needs, wants, goals? To what extent to demographics, location, car ownership status, interest in the environment etc. play a role?
- Understand current solutions and the competitive landscape. What products and tools exist in the space already? Who are the direct or indirect competitors? What works well, and what could be improved in the current landscape?
A key principle of HCD is talking to real people to gain an insight into their experiences. So, I carried out a quick user survey to learn more about my potential users. The two major themes I wanted to learn about where their attitude towards ride-sharing and the ride-sharing experience, and their attitude toward self-driven cars.
I used Google forms and shared it with my friends and family for feedback. I tried to keep my questions open ended, except where collecting demographic data.
Survey response breakdown:
- 14 responses (not a tonne, but enough for me to move forward)
- 21.4% own a car, 7.1% share car ownership, 42.9% don’t own a car, 28.6% used to own a car
- 92.9% are not living with a life-affecting physical or mental disability, 7.1% are
- 92.9% are either extremely or very concerned about the environment, 7.1% are moderately concerned
- 92.9% have used ride-sharing apps before, 7.1% have not
- Uber is the most popular ride-sharing app at 92.3%, followed by Bolt, Addison Lee, Lyft
User survey insights:
- Current ride-sharing apps are generally convenient, well priced and easy to use
- Public transport is considered before ride-sharing
- Users are annoyed when drivers cancel
- Mixed user sentiment on driverless ride-sharing
- Seen as less flexible than human driven alternative
- Concerns if it can it work in London?
- Safety is main user concern
- Potential to reclaim personal time
To get a clear idea of the competitive landscape, I then decided to check out the competitors.
The analysis itself was not particularly thorough (remember you only need enough research to justify your decisions). I quickly pulled together some pros and cons of each service, and organised them into a notion page, like this:
- Basic pros and cons of Uber, Bolt and Addison Lee
- Basic summaries of the service offered by Lyft Autonomous and Waymo One
Following my competitor analysis, I decided to expand the scope of my research through desktop research. This basically involved me absorbing articles, journals, personal accounts, blogs, podcasts.
Desktop research insights:
- Driverless cars could actually damage the environment
- Strong human attachment to personal cars
- Trust and safety are consumers primary concern
- Huge potential to help elderly and people with disabilities
- People may experience more car sickness in driverless cars
- Driverless cars could be uncomfortable for users
- People love seeking analogue experiences, including driving
- Adoption will likely depend on location (and what public transport options are available)
After researching the problem, it was time to synthesise what I had learned, and identify any emerging themes. This is about making meaning out of all the observations and research. Turning the fact into insight.
One insight stood out to me was that elderly and disabled people can have very difficult experiences when using current ride-sharing services.
Through the analysis of the competitors (selected for being popular among my survey sample), I got a glimpse at how the current ride-sharing services (like Uber) have sometimes failed to meet the needs of elderly or disabled people. This was sometimes through discrimination by individual drivers, but also by failing to design for this user group when it came to the digital experience.
I explored this further through my desktop analysis, where I learned:
- 21% of the UK population (14.6 million) is disabled — many are unable to drive
- 19% of the UK population (12.3 million) is aged 65 or over
- After retirement, the number of trips taken by older people falls by 20%
- A 2019 survey asked 500 care home providers to respond if residents ever went out of the home with a friend, rather than with a staff member, registered volunteer or relative. Only 4 providers responded…
- People who spend a lot of time at home may enjoy the chance of an outing — a car sharing trip simply to visit another place for a few hours may be a welcome change.
- Poor transport options are often cited as a key barrier in preventing them taking part in wider society
- AV manufactures show little consideration for how experience might benefit people with disabilities
- Many elderly people are intimidated by the ride-hailing experience
- Some need to be able to interact using non-typed input e.g. voice
The emergent theme was clear to me. The current ride-share services seem to be failing to completely meet the needs of this user group. It was therefore an excellent opportunity for Arrival (the company I’m designing the fictional app for) to explore. The issue also felt worthwhile to tackle based on simple numbers. With 14.6 million disabled and 12.3 million elderly people in the UK, the potential market — and potential profit — was massive.
I was to design for the experience of elderly and disabled people.
After looking at all this research, I then decided to create quick empathy map of a user persona — called Mary. It lists what she says, what she does, what she thinks and what she feels.
This helped me to step into the shoes of the potential user, and empathise with and understand their unique perspective. It also allowed me to keep a (roughly) defined user group in mind as I designed the app.
How Might We
Following the empathy map, I created a How Might We statement.
- are short statements that can be used to incite ideation and launch brainstorming
- bring direction and structure, and helps us frame the opportunity
- are great because it assumes a solution exists, and that we can find it together
- seem simple, but can be challenging
- must be broad enough that there are a wide range of solutions, but narrow enough that we have some helpful boundaries
How Might We… redesign the ride-hailing experience for elderly people (like Mary) so that it can be simple, accessible and fun?
I now have a condensed brief of research findings, a clear idea about the opportunity — and bridge to the ideation.
Step 2: Ideate
With the opportunity defined in my How Might We statement, it was now time to come up with ideas.
In practice, this looked like a brainstorm. I wrote the statement in the middle of an A3 piece of paper, and explored different solutions around the outside.
This was a very fast and fluid process, with no solution too crazy, stupid or far-fetched. Good ideation is about give yourself total freedom to come up with as many ideas as possible — quantity over quality!
Following my brainstorming, I was able to identify 3 different use-cases for the app (deliverable 1). The brief specifically asked for a common use case, a use case that combines a number of tasks and an unusual or interesting use case.
The use cases were:
- User orders ride
- User gets in car
- App makes optional suggestion to pick up another solo passenger, if the route is efficient and destinations are close
- User can accept or decline
- If they accept, ride automatically reroutes to pick up new passenger
- New passenger gets in car
- User says “Hey Arrival…” to initiate voice activated ride ordering process
- In-app voice asks where the destination is
- User says destination out loud
- Ride is ordered
- Car arrives
- Car takes user to destination to complete activity
- Once activity is completed, however long that is, user says “Hey Arrival… I’d like to go home”
- Car is dispatched to location
- Car takes user back to original destination
- User downloads app
- User agrees to give app access to calendar data, including the location
- When a calendar activity is coming up (e.g. in 30 mins), app asks if user would like a car dispatched
- User agrees
- Ride is ordered
- Car arrives
- Car automatically takes user to the location from the calendar item
The 2nd deliverable of the challenge was to prioritise one use case and create a user flow for it.
I decided to prioritise the common use case solution — optional in-ride partnering with other solo elderly person. I felt this solution would closely align the goals of the user, specifically focusing on the language of the How Might We statement to make the experience simple, accessible and fun for an elderly person.
Additionally, I considered this option as both reasonably low on effort and time — and is therefore an attractive option from a business perspective.
My solution essentially sought to match elderly users of the ride-sharing service, if their destinations were similar and the journey was efficient.
In an unseen stage of user onboarding, the user would opt in or out of ‘ArriveMate’ (the name of my solution) notifications. These would be the friendly pop-up notifications that ask if they want to pick up another person en route to their destination. Of course, if neither actually want to share the ride, then no pressure. It’s totally optional.
The onboarding would also be able to accept a level of personalisation from the users, so that they are matched based on similar interests. A basic example would be, if both users add ‘classical music’ as one of their interests in the app profile, ArriveMate may suggest they share a ride together.
The purpose of ArriveMate is — as the How Might We statement suggests — a solution that, I feel, would make the ride-hailing experience simple, accessible and fun for elderly people.
For elderly people who are lonely or intimidated by the current ride-sharing experience, ArriveMate could be a good solution, by matching them with like minded people to share their journey with, all done through a very simple interface.
To create the user flow of the ArriveMate experience, I jumped into FigJam:
Step 3: Prototype
With the ideation over, it was time for the 3rd and final stage: prototyping. In a real world setting, this is the path that leads from project stage out into people’s lives.
To meet deliverable 3, I created a wireframe for most important part of my chosen use case.
This was created in low fidelity and with a neutral colour palette (to avoid any decision bias). I only needed enough detail to be able to communicate with the hiring manager the story of each screen at this stage of the experience.
My tool of choice was Figma and I used a simple wireframing kit from the Figma community.
The brief said not to worry too much about the branding of the app, but I did make a few style decisions, which I’ll explain here.
- One thing the brief did mention was ‘the brand should evoke the feel of Tesla’. This was a bit strange as the brief was for a company called Arrival, not Tesla. I raised this with the Hiring Manager in my interview and he admitted that was a mistake. The previous version of the design challenge was an app for Tesla, and they simply hadn’t updated the whole document. I didn’t know that when designing the interface so took inspiration from both Tesla and Arrival.
- The red is Tesla’s red. (Taken from their brand guidelines)
- The gradient surface of the pop-up notifications are meant to evoke the metallic surface of a Tesla car.
- The font — Apercu — was taken from Arrival’s website. (Using CSS Peeper)
- The interfaces were generally kept very simple. I was designing for elderly people and so wanted to avoid any cognitive overload.
- There was also the strategic use of colour (Tesla red) to direct the user attention from one CTA to the next.
It was now time to turn all of this work into the final product. It was time to design the primary interface screen(s) in high fidelity (deliverable 4).
As above, this was also done in Figma.
Ultimately, given the time constraints, I was fairly happy with the outcome. Putting together a research driven solution that improves on the already well-developed ride-sharing experience was not easy, but I think I was able to illustrate ArriveMate’s core experience and value proposition. I focused on the in-car notification flow, but there are many other directions I could build upon.
With more time, I would:
- Test my flow with users, and iterate based on feedback
- Explore other visual directions and validate with users
- Design an onboarding flow that allows for profile personalisation
- Design user profiles
- Explore the idea of humanising the notifications, to increase the level of trust and enjoyment
- Explore different methods of user input (e.g. voice)
- Spend some time with elderly people! Get an Uber with one and speak to them as they go about the experience.
Personally, I did feel I ran out of steam a little bit towards the end. I spent so much time on the discovery/research phase (I knew I was inexperienced so wanted to showcase that I can fill that experience gap with effort) that the project almost feels a bit top-heavy. I was also having a lot of fun with it, so I spent even more time. The first phase is about 3x the size of the last phase.
Hiring Manager Feedback
On my research and proposition:
“I thought your research and proposition thinking was sound and you had some very sensible ideas and justifications for where you saw the development of the application going”
On converting research to prototype:
“When it came to implementing these into the prototype, there was a little bit of a disconnect where I felt like you got distracted by a mixture of design patterns that already exist (like Uber maps) and keeping the journey simple.”
“The experience we need is in being able to translate all of that great insight and it be second nature in how we see it taking shape in the UX and UI.”
“I thought on the whole it was fairly well put together and for your first challenge response fantastic. I’ve seen some seasoned designers turn these around with less.”
“For a first attempt you did well.”
For the future:
“Design challenges have a bad reputation, and we try not to use them where possible, but you will no doubt come across them.”
“The trick is to figure out what process works for you and how you can illustrate your thinking and execution without doing too much and burning out. Less detail up front means more is left over for later on, if that makes sense.”
“Your research was so so detailed that it meant is was disproportionately bigger than the outcomes. Next challenge take a step back and simplify what you need to put in maybe.”
And that’s it! That’s the end of the design challenge walk through. I hope at least someone found this to be interesting or valuable. This process actually ended up being very helpful to me as it made me reassess, very deeply, my process and where I can improve next time.
If you have any questions about any of it, please don’t hesitate.