The double diamond seems to be a popular method of approaching design thinking for most UX designers. Discover, Define, Develop, Deliver. But often clients and stakeholders start to run for the hills when they realise that the discover phase involves time consuming user research, research that the client believes they don’t need to do because “they already know their users”. A lean approach to user experience design may be an easier way to sell design thinking to a client as it involves starting with assumptions and creating hypothesis that may solve a problem, then testing these hypotheses with real users in a short time frame. I find this to be a better starting point with clients as it saves time and engages them more from the beginning of the project, making the design process more transparent.
Just in-case that first paragraph made no sense to you, don’t worry. I find the best way of learning is by seeing an example. I decided to adopt a lean approach to a little challenge given to me – improve the ASOS app in order to increase conversion rates.
First Step: Declaring Assumptions
Problem Statement
Before diving into assumptions there needs to be a clear problem statement. I treated my challenge as the problem statement – improve the ASOS app in order to increase conversion rates. Probably not worded the best. Problem statements should follow a more structured format addressing the criteria below
[Our service/product] was designed to achieve [these goals]. We have observed that the product/service isn’t meeting [these goals], which is causing [this adverse effect] to our business. How might we improve [service/product] so that our customers are more successful based on [these measurable criteria]?
Lean UX, O’Reilly
As this is a hypothetical I can’t say I know the goals of the ASOS app, but I can take a good guess based on a quick google search and their press releases.
“Our core customer is the twenty-something fashion-lover: an avid consumer and communicator who is inspired by friends, celebrities and the media.”
From this I created a more fleshed out problem statement: The ASOS app was designed to be the favoured place for twenty-something fashion lovers to be inspired by fashion and buy clothes. The ASOS app isn’t meeting these goals which is causing a stagnation in sales and profit loss to our business. How might we improve the ASOS app so that our customers will want to buy more clothes and follow through with sales.
Proto-Personas
Once you have a clear problem statement it’s time to capture the audience you are focusing on. Proto-personas are an archetype of key users you will be focusing on, however a proto-persona is different to a regular persona as it is purely based on assumptions which you will later validate. As I did not have access to the ASOS team my assumptions were based on a few press releases and previous case studies on ASOS. From that I created one Proto-persona.
In a client setting this is a good in 2 ways. Firstly, you are getting them to think about their users. Secondly, it’s a quick and dirty way to get their current knowledge on their users.
Hypothesis Statement
Now that I have a primary persona (in most cases you’d have more than one) I could come up with ideas on how I might address their pain points. I had a look at the current ASOS app, did a quick heuristic evaluation, looked at what competitors did, and apps such as Pinterest that had features that could potentially address some pain points. From that I came up with the following hypotheses using the following template:
I believe that We will achieve [business outcome] if the user [persona] can achieve [user outcome] with this feature [feature]
Second Step: Testing my assumptions
I then wanted to test these assumptions with real users by sending out a quick survey which got 20 respondents, 5 user interviews and 1 guerrilla test of the current ASOS app. From this I gathered the data into themes (affinity mapping) and got the following insights
From this quick research, which only took a couple of days, I updated my proto-persona and re- prioritised my hypotheses based on the pain points that both would critically affect the business and users.
The key point I am trying to make is that proto-personas and hypotheses are fluid artefacts, they are not set in stone and the beauty of a lean approach is to constantly validate and update your assumptions. It’s also a good way of quickly getting the client to see the benefit of a design thinking approach in a ‘sneak peak’ way. Once they start to see the benefits of what a bit of research and user input can have they may be more inclined to invest more in a human centred design approach in the future.
In my next blog I’ll be going through the prototype I made based on these insights and how I iterated its design based on testing it with only 5 users.
Comments are closed.