A technique in which subject experts or ‘users’ are guided in generating a taxonomy.
When to use:
Designing information architecture (site’s navigation).
Two part workshop to create empathy with staff/employees. Part one gets everyone involved working on a project at all levels to submit ‘hopes’ and ‘fears’ for the project anonymously via placing notes into a hat. Part two sees the UX designer presenting the aggregated ‘hopes’ and ‘fears’ results back to the audience.
When to use:
At the start of a project. When you want to shift over to a collaborative working environment. To help establish trust or to create empathy with staff/employees. A way of getting Stakeholders’ buy in (getting budget/resources assigned to a design process).
Proto-personas are like traditional Personas, difference is instead of using marketing data and notes from user interviews we only use Client stakeholders’ experience with their users.
When to use Proto-personas:
1. When you want to ensure alignment amongst Client stakeholders.
2. Used by Agencies when a Client doesn’t want to pay for research.
3. When doing Lean UX, Proto-personas are your best guess as to who is using (or will use) the product and why. You start with assumptions and then do research to validate the assumptions.
How I make Proto-personas:
1: Organise 3 hours brainstorming session with Client stakeholders.
2: Turn data collected in session into Proto-personas.
3: Organise a 3 hour review session with Client stakeholders rank Proto-personas in order of importance.
4: Make amendments to Proto-personas.
5: Get Client stakeholders to sign off final Proto-personas.
What I include in Proto-personas:
1: User’s behaviours.
2: Goal user wants to achieve with product.
3: User’s influences (list of technologies they use) which shapes their mental model (expectations of how a product should work).
Note: Instead of demographics I use a list of technologies. This info gives Designers an idea of what UI solutions the users will adopt instinctively.
Find out more about Proto-personas
Meeting involving Stakeholders and a UX designer.
When to do Stakeholder interviews:
Early on in the project when a solution needs to be chosen.
Here are the seven step strategy I use for Stakeholder interviews…
1. No guessing
Ask questions to turn my assumptions into certainties. Best way to waste time is designing on assumptions.
2. Move off solutions
Stakeholders usually just want to talk about solutions. Design is a process for solving problems. Fully understanding the problems first allows me to properly prescribe solutions.
3. List all the problems
A. Get Stakeholders to put all the issues that causes them problems on sticky notes on a wall.
B. Ask “If you could make a product that solves all the problems on this list, and nothing else, would you have a solution that exactly meets your business goals?”.
C. If their answer is “no” then go back to adding issues to the list.
D. With a completed list I can start to understand what design solutions would work best.
4. Find evidence
Looking at each problem on the list, ask “What evidence do you have that this problem actually exists?”.
If there is no evidence to confirm a problem exists, then research is needed to validate its existence.
5. Remove the solution
Let the stakeholders convince themselves that the project is important.
Ask “Do you think living with the problem may be cheaper than fixing it?”.
Without stakeholders’ buy-in even my best solution will fall flat.
6. Explore constraints
Ask “Did something stop you from succeeding in the past?”.
If obstacles still exist, first explore ways stakeholders can remove these obstacles, before going onto solutions.
Before the interview, send stakeholders email outlining the six types of questions I’ll be asking them. This gives them time to prepare and confirm they have the authority to make decisions and manage the budget.
In multidisciplinary teams we make User Stories, these are user centred stories that detail how the users are going to use our product to achieve their goal.
When to do User Stories
When you want to define a product’s features list.
Here are the steps I follow to make User Stories…
1. Define who are our users
Ideally we want to use Personas, in their absence on a small budget make Proto-personas.
2. Fill out templates
Using each Persona fill out this template on a sticky note:
As a <type of user>, I want <some feature> for <some user goal driven reason>.
3. Facilitate discussion
Put sticky notes on wall to shift focus from writing product features to discussing them.
4. Agree on features list
Turn discussion notes into features list and share list once written up.
Designer leads multidisciplinary teams in design activities, typically the conceptualisation of a product.
When to do Workshops:
1. Design agency/consultant wants stakeholders to buy into a design process.
2. Aligning in-house teams to work more effectively.
3. When a stakeholder wants co-creation.
4. Working in/with UX Lean.
Types of workshops I do:
1. Proto personas
2. User Stories
3. Stakeholder interview
4. Hopes and fears