How to run effective Design Sprint workshops

Recently I’ve been lucky to run a range of design and product workshops with Outlandish, the worker-owned tech agency. It’s something I love doing. From 5 day Design Sprints based on the Google Ventures handbook approach, to one day MVP planning, design sprint-in-a-day sessions and more.

Through this there are a few simple techniques that I’ve come to appreciate that can significantly improve the experience of those in the room and the output of the day.

Some of these have already been recommended by Jake Knapp, John Zeratsky and Braden Kowitz in their book Design Sprint. I reiterate them here because, when you’re reading the book prior to running your first sprint, it’s easy for their importance to be overlooked.

Others have been learnt the hard way or developed with input from Outlandish colleagues.

Okay, in no particular order, here we go:

If you say sketch, then sketch

In a design sprint there is a lot of sketching. There needs to be. However some people don’t feel comfortable sketching because they’re worried about presenting their drawing skills to their peers. Also they’re concerned they can’t capture what’s in their head.

They will want to write their ideas instead.

But you should avoid your participants writing instead of sketching at all costs.

A written response feels clear and complete. But the beauty of sketching is that it IS crude and unfinished.

A sketch invites more contribution and engagement. It leaves space for the idea to be explained by its drawer and interpreted or elaborated upon by the listener. Because of the space around a sketch the potential feels larger, and more gets opportunities are seen within it.

Sketches, crude flowcharts, stickmen – these are all fine. But written responses should be discouraged.

Reassure your participants that no-one is judging, we are seeking to be inspired. Use the explanation above if need be. Explain why sketching is so important.

Make them stand

There’s something about tables that puts lead in people’s butts and makes them want to sit. This is murder for a collaborative process.

Keep the space more space than table. Give plenty of room around the whiteboards.

Take as many tables out as you can. Leave enough for people to sit at and make notes, but ensure that it’s light on tables. Even a little cramped. People will feel inclined to get up and out of their seat.

Equally, direct them. Don’t be afraid to explicitly ask people to stand up. Ideally before explaining the rest of the activity instructions.

Tell them directly: “Okay, for this next activity I need everyone out of their seats. So, please stand.

“What we’re all going to do is take one sticky note, write on it a user type, and post it on the board. And we’re going to do that for as many user types as we can think of for the next 2 minutes.”

And know where to stand during their feedback

As the facilitator and someone who’ll probably doing the majority of the speaking during the session, attendees feel naturally inclined to address any feedback to you. Be aware of this. They need to be feeding back to their peers, not ‘reporting to teacher’.

So when people are feeding back, try to stand in the midst of the group. Even better, stand behind them, so others are between you and the person at the board explaining their work. This way eye contact is made with their peers, group engagement happens and feedback is taken board.

Two people standing, drawing designs on a board.

Be aware of the power in the room

The main client has a lot of power. They’re probably an important decision maker too and it’s important that they’re invested and involved.

However they’ve got a team with them, and some of them in that team have a very different status. The intern. The assistant. The new hire. The student help. And the reality is they’re likely to have just as valid input.

It’s probably imperative, in fact, that new thinking is required on this project – and perhaps even they’re closer to the product’s target user than the CEO.

However it’s easy for the CEO to have a louder voice and the intern to be excluded. So, ensure that everyone is given full chance to speak and participant. And make sure that the intern, the assistant don’t just get a turn at the end of an activity, after everyone else has spoken and now the clock is ticking to move on. But rather, mix them up. Mix everyone’s turn to speak up.

As an aside: Outlandish, where I spend much of my time these days, uses a consent-based decision making process on their projects called sociocracy. Using it in design sprints is a great way to help level the playing field. They offer training in how to apply sociocracy in your own work here.

Make those sticky notes work for everyone

There’s a reason why sticky notes are sticky, and that is so they can be unstuck. And moved.

The process of design requires that people form associations and take action.

Writing notes and sticking them to a wall allows us to immerse ourselves in the chaos of information. Our brains kick in and try to form associations, and soon enough we find ourselves making connections and spotting common themes.

Moving the notes and resticking them elsewhere allows us to spark ideas and conversation, and so on.

If an activity requires sticky notes (e.g. for an idea generation activity, or capturing insights and research), make sure that they go on sticky notes. And insist on one idea or insight per note. Then get them up on the wall.

Really, do push your team to do this. They’ll find it unusual at first, and you’ll need to guard against over-talking and discussion of the notes as they’re created, but soon they’ll see the value of doing this.

A woman looks at a wall in the street, covered with sticky notes

Use the board to cut down discussion

A simple yet effective trick: partition a slice of your board off at the start. Draw a line to make a column to one side of your board.

This is your park board.

Here you’re going to park any questions that are taking up too much time.

In my experience they’re usually questions about what-ifs. I.e. other things that the project may or may not need to connect with in the future and how this challenge might be resolved; what other stakeholders who are absent might say; and risks.

Although these can’t be resolved in the room right now, you will find that one or more people will start discussing it like it’s part of the output of the day. It isn’t

I like to capture these things as questions, and refer back to them in the Design Sprint How Might We…? session, if you’re running one.

And when the day is over, you should also refer back to the park board to see if any of the issues and questions parked are still valid and actionable after the sprint.

You can also use the park board to list vocabulary that your team might be unfamiliar with, key dates, or other headline insights, and so use it to reduce the cognitive load on your participants.

Show the running order

Let’s think about the setup for a minute.

In the Design Sprint book Jake Knapp recommends showing the agenda at the start of the day, indicating all the different stages and activities you’ll be running.

There is something so fundamental about doing this, but it’s easily forgotten as you strive to get everyone settled and to get going.

Sure you can just launch into the day and try to take people on a creative journey, but attendees derive confidence in you if they know there is a grand plan. That things are heading in a certain direction – even if they don’t understand what the items on the running order mean or what they’re going to be doing.

Showing a topline running order means they relax. They give themselves over more to the activity. And your day just got a lot easier.

Ask permission

Another simple win. After the introductions and showing the order, check the understanding of your guests. Then, explain your role and the desired outcome of the day.

Finally, ask your attendees to allow you to lead. That’s all. Just ask your attendees something along the lines of “if I have your permission, I will be running through these activities and taking us towards this goal. How does that sound?”

They will say it sounds good – yes, you have their permission. And of course they’ll say this. But in this moment there is a transaction that takes place and trust is imparted to you.

Speak less

It’s scary to speak to a room, to lead a workshop. There is the fear that you won’t be understood. You feel a pressure to fill the air and over-explain. You feel that people expect you to have all the answers.

But that’s not true. It’s mostly in your head.

So breathe. Take a moment before you speak. Talk a little slower than you usually might in a conversational setting. Actively listen to yourself as you talk.

And when you’ve said what you have to say, lean into the pause. Leave it hanging in the room.

Generally your attendees will want to help you or rise to your challenges.

And as for questions: recognise that you don’t need to have the answers. If someone asks a question, open it to the room. You are there to help the day run beautifully and the attendees to be as productive as they can be.

When you do these things, you pay more attention to what you’re saying. You see where your tongue is taking you and how to finish the idea you’re halfway expressing.

Prepare. Prepare prepare prepare…

And finally, preparation is key.

When I was teaching English, I liked to have a running order, by the minute. For example, prior to running a class I’d make notes like this.:

  • 3 minutes – warm-up activity the ‘eee’ and ‘i’ game
  • 5 minutes – write past-perfect example sentence; elicit other examples; elicit grammar points
  • 15 minutes – set questions
  • 5 minutes – check answers and understanding
  • … etc

At every step I would also prepare what I needed say, almost like a script.

And I do the same thing with running workshops.

However I know that we will probably stray from this. I know that I can’t keep referring to the running order every few mins – it’s impossible. I accept that I will get sidetracked, or I’ll forget something.

But that’s okay, because the act of preparing helps me really get comfortable with the activities and feel relaxed. And in the room, it helps me have a better awareness of time.

So there you are! A few tips to help you run sessions. Hope they’re of use 😉

 

Update vs. innovate – knowing when is best for your company

What version of operating system does your phone run? Is it the latest? If not, do you even care?

The change in life that an upgrade makes, is it even still noticeable? Compare that to how it felt when you first bought a smartphone. Or your first car?

The impact of successful products

As a product actually develops from idea to reality, the potential directions it could go in rapidly narrow. The potentialities evaporate as decisions have to be made and things start to be laid in place. Once build begins, the cruft – the assorted debris, the complexities, leftovers and impacts of design and build choices – increases.

Gradually it becomes harder and harder to improve upon the product, and the effort required to continue to develop new features or apply improvements increases.

Meanwhile, something worse is happening.

The addressable market for your product is shrinking. Or because I like to focus on people rather than market numbers, I prefer to phrase it another way: the potential emotional value that your product supplies is shrinking.

The product value / product development trade off

The users whose pain point you solved with the launch of your MVP and first few iterations, are still around, but their scale of problem has reduced. You’ve (hopefully) already addressed it somewhat and provided some level of solution.

And therefore the emotional value that updates to your product can deliver is steadily shrinking too.

Gradually, the effort to update your product is going to greatly outweigh the emotional value updates can bring.

So what’s to be done?

Innovating whilst managing expectations

As CEOs of product based businesses, you should be looking to diversify and innovate. Find new problems and deliver solutions.

As Product Owners, you should keep updating your roadmap but beware of the diminishing returns that your product is likely to deliver. Feed this up. And don’t feel bad! Feel good for every bit of value delivered in this increasingly complex situation.

As suppliers and agencies building products, you’re in a difficult position. On the one hand you’re trusted to improve a product on behalf of a client. On the other hand, you are at risk of being viewed increasingly unfavourably over time (quietly, unfairly blamed?) as your work fails to bring the same returns as those early, giddily successful releases.

The best approach for you is to be open and supportive of your client. Highlight the diminishing returns they will eventually face. Help them avoid the risk of ossifying, losing out to new, smaller, focused products whose teams can move faster and deliver more emotional value than your clients 18th update can.

Encourage your clients to diversify, look for new emotional problems and product opportunities, and work with them to ideate and build these new products.

 

Better user testing with a user testing plan

You’ve got your product built and out to market. Or maybe you’ve got a clickable prototype built in Adobe XD or other tool, or even some paper wireframes. Either way, now you’re ready to get it under the noses of real people, test your idea and hopefully improve your business.

Scary times indeed. 

Why do you need a user testing plan?

A testing plan prepares you for user testing. At its simplest it helps you decide the areas that you are going to concentrate on. At its more complex and most useful, it’s a practical guide that ensures your tests are consistent, thorough and that they give your team actionable results.

Crucially, it also helps you focus on watching your users. A testing plan will allow you to uncover more about their problems, their needs and how your product might help them. Which is exactly why you’re doing this to begin with.

What goes in a user testing plan?

  • Scenarios
  • Tasks
  • Aimed for outcomes and a way of scoring
  • Requirements / assets needed to run each task
  • Notes and comments

So how do you start putting these together?

1. Choose what to test

To create your plan, first make a broad list of all the things you want to test.

Good ways of doing this include:

  1. Identify any assumptions you’ve made about your product or users which you want to test are true. Question the most obvious assumptions. It’s strangely hard to do, but invaluable.
    For example, ‘on our website, parents will be able to join parenting groups in their local area’, or ‘users will know they can save their work and edit it later’ etc.
  2. Think about the business objectives which your product is meant to deliver (e.g. increase the number of accounts created by our online shoppers)
  3. (A favourite of mine) think about those aspects of your product which are meant to give value to your users. Be it social, emotional, economic or whatever. Do they really generate value for your users? Do they even know these aspects exist in your product?

Now shortlist.

Whittle them down to a good number to test – and definitely use your business’s objectives to help you prioritise.

10 things are plenty for you to be testing within an hour, per user. Any more risks fatiguing your users, you and any observers.

2. Write your scenarios and tasks:

Test scenarios provide users with a real life context that they may find reasonably expect to find themselves in when using your product. Test scenarios also provide a structure that gives your user a seamless, authentic feeling experience – i.e. it provides them with the best simulation of real life as it is possible to give.

For each scenario you need a general structure something like this:

  • first the framing, or user motivation
  • then an actionable task for the user. These will give you something to measure, or validate its completion as a success.

Define your scenarios in advance!

Defining these scenarios – i.e. writing them down before you get into testing – gives you structure and reliability.

It means you can standardise the tasks, and therefore the test overall, making your results more reliable.

Writing scenarios in advance helps you avoid changing the way you describe them between users, as this would make your tests inconsistent

Finally writing scenarios and tasks helps you avoid poor or leading phrasing when you try to describe them to your user.

Simple things to avoid include:

  • Unintentionally revealing the steps required in order to complete an action;
  • Questions that use the same language as the on screen elements;
  • Turns of phrase that unwittingly reveal the aspects of the product you’re hoping to test;
  • Making the user operate in an unnatural way in order to please you (i.e. they do what they think you are pushing them towards, rather than solve the challenge in their natural way)

And of course, writing test scenarios allows you to identify in advance all the assets you’ll need to run that scenario. For example, if testing paper prototypes, all the paper assets needed to illustrate that user journey and any offshoots the user goes on.

What makes good user testing scenario and tasks?

As already mentioned, each scenario needs:

  • the framing / user motivation
  • then at least one actionable task

For example, “You need to travel to Oslo by Saturday morning. Go to the MyTickets website and book a good ticket.”

Keep tasks ‘human’ to reap insights

The phrasing here of “book a good ticket” allows the user to find and book whatever they think is the best approach to travel.

Had you just said “book a train ticket for Saturday morning” they might have done that, but you would have missed discovering that they’re the kind of person who would love to travel by boat for a change; or always hunts out deals; or that hates overnight travel; etc.

These would be missed business and design opportunities.

Make each task a real mission

Note in this example that the user was asked to find their own way to the MyTickets website. It was not already open and ready for them.

Seeing how users find, navigate to, and react to the product first opening should also be part of the test. It makes the scenario feel real, like a mission, and it may surprise you with the route that they take.

Outcomes and scoring

In order to track how well users are able to complete the tasks, you need a scoring grid. Nothing fancy. Just a simple grid, with the leftmost column containing the tasks and hoped for outcome, one per row, and then a column for each tester.

For each user, if they successfully complete a task or answer a question according to the expected outcomes, they get a tick. If not, an X. If they only partially complete it, you leave it blank.

Success Rates

Another way of scoring to give user-tasks a % success rate. This will allow you to work out some averages of areas of your product that need improving.

A typical scoring system would be:

  • %100 completion rate = user completed the task
  • %50 rate = a partial success in completing the task
  • %0 rate = the user was unable to complete the task at all 

A note on terminology:

Using “success rates” instead of something like “failure rates” has a more positive connotation, and is based on empathy for our users – which is fundamental for good design!  “Failure Rates” has an inherent critical aspect to it, both of the test subjects themselves and the design decisions. Or, putting it another way, the design team!

However product development is about iterating and improving. It’s aspirational. And it’s much more motivating for people making design decisions, prototyping and iterating, to be talking about success rates over failure rates.

Finally, I believe “failure rate” has a focus that is more internal to the organisation and doesn’t celebrate users. There is an undercurrent that suggests that ‘users are failing to understand our designs’ rather than ‘we aren’t meeting users needs’.

Notes and comments

Of course, there’s more to user testing than generating scores and ticking boxes. The greatest amount of learning comes from simply watching your users and understanding what they do and how they feel. For this, someone needs to take notes.

If you’re the person facilitating the test, don’t worry about taking notes yourself. As the facilitator, your role is to concentrate on engaging with the tester, making them feel comfortable, keep them talking and and help them verbalise what they’re doing throughout.

Instead, have an observer do the note taking. For best results, it should be multiple observers. For this, set up a webcam and microphone and send the feed to in another room. Ideally, see if you can focus a second camera on the product itself as well, as then you can send a feed to the observers as people navigate, click around etc.

The observers should capture:

  1. Noted behaviours (e.g. body language, shaking their head, flipping back and forwards between screens)
  2. Likes
  3. Dislikes
  4. Feelings
  5. Questions
  6. Ideas

Capture them one per Post-It note, making each short and clear. Be sure to also note which category each belongs to (i.e.  add “Likes”, “Behaviour” etc in the corner) and set them aside. 

Post-test results

Once all the tests are complete, it’s time to bring everything together. 

Take all your notes and do a ‘Saturate and Group’ exercise: as a team, grab notes and post them on a wall. Then, collectively look for common themes within the feedback and group them, moving the Post-It notes accordingly. Finally, give each grouping a title.

Taken together with the task scoring grid, you’ll now have at least a good half dozen clear opportunities for improving your product.

 

Desire and UX

In 2013 Lamborghini, the car firm founded by the Italian industrialist Ferruccio Lamborghini, produced 2,121 cars. By hand. And these cars sold for about $200,000 apiece.

Meanwhile in the same year Fiat, the Netherlands-based manufacturer, produced over 2 million cars, with mid-range Fiats costing about $25,000.

As a product they broadly serve the same function. But the question is, which is the more desirable car? Which would you rather own, a Fiat or a Lamborghini?

And how do we choose?

Once asked that question we find ourselves assessing the qualities of the two cars. We rationalise the miles-per-gallon and insurance costs, sure. But with the Lamborghini we find ourselves thinking about the speed, the design, the workmanship, the materials, the aesthetics. We visualise it.

And very quickly we realise that one of the main factors in our decision-making is desire.

Desire in UX

Desirability is established in users – and instilled in a product – through brand, image, identity and aesthetics.

But aren’t brand and identity separate disciplines to UX? Does adding brand, identity and image into the remit of UX design stretch the concept of UX until it becomes too broad and unworkable?

Such questions lead us down the wrong path. And in order to show why, let’s break it down a little…

Beep beep! What does a classic Merc say about its owner?

Aesthetics, brand, image and identity

The aesthetics: Lamborghini cars have a very strong aesthetic – you can always recognise a Lamborghini. A Fiat, probably less so.

Their brand is clear too: luxury and high end. Lamborghini cars are expensively finished, highly-engineered and probably have way higher quality parts than would typically be required of an everyday driver.

They also come with – and impart to their owners – a strong image: the cars have associations with the world of motor-racing (and shh… a historical connection to the world of tractors, but that’s another story).

Through this they allow their buyers to attain a certain identity: only a few thousand Lamborghini cars are made each year, so owning one means being part of a highly exclusive club.

Finally, all of these aspects of desirability mean Lamborghini cars, as products, instil strong emotional feelings in their users. This is likely to include pride and confidence, but overall it’s satisfaction.

Satisfaction in the UX formula

Satisfaction is the elusive quality that sits alongside utility and usability to create the user experience.

User Experience = utility + usability + satisfaction

Just one of the many UX formulae out there…

So back to the right way of thinking about this issue…. The question we should be asking ourselves as product designers and UX professionals is: what elements of brand, identity and image can we include in our product world that increase the satisfaction of our user?

There’s a lot of opportunity here: from major features that build tribes, that create exclusivity and reward power users; to the aesthetic decisions we can make on interaction animations, transitions, the colour palette, imagery, content tone/language and more.

Window Seater

This is a question I’m thinking about as we grow Window Seater. For a travel app, how can we leverage brand, identity and image in the user experience?

At Window Seater, Pete and I believe that, as travellers, we should build connections to the people, history and cultures through which we pass. And we believe in a new approach to storytelling: handmade, high quality stories that better connect us to the world and its people.

So how can we build desire around this and bake it into Window Seater’s products? How can we make users desire to be a part of our tribe?

Desire in the digital world

An example we can all learn from is Maptia – ‘home to a world of stories’ about the world and its peoples – and see how they’ve employed thinking about brand, identity and image in their UX.

Take a look at Maptia’s journey from 2014 to present day. Notice the enhancements to its design and the creation of a high-end feel via its typography, imagery and palette. Notice too the visual priority given to the Maptia community in the 2018 design.

Maptia homepage in 2018

And of course, the focus and pull of its improved mission statement, from:

At Maptia, we believe that if people from every country, every culture, and every background shared the stories of their lives and of their travels, then the world would be a more understanding and empathetic place. We also believe that this would encourage people to get out there and make the most of their short time on this planet. Our mission is to gather these stories together and create the most inspirational map in the world.

Maptia’s Mission Statement circa 2014

To:

At Maptia, our mission is to foster empathy through storytelling.

We aim to provide a platform for those who document and capture the world around us, bringing them together to create a lasting record of life on Earth; so that people everywhere can experience the cultural and natural wonders of our planet, can feel more connected to the biggest issues facing the world today, and can be empowered to create a better future.

Maptia’s Mission Statement circa 2018

Notice how the vision is now so much grander.

Also the focus has moved from 2014 team’s internal ambition, to 2018’s focus on appealing to and servicing an existing tribe: the photographers, writers, explorers and those passionate about our planet.

For us Maptia’s approach is hugely inspiring and definitely something to learn from.

So what exactly can we learn from all this?

As product managers and UX professionals, when we’re building products we need to factor desire into our product world to increase the satisfaction of our users.

When building our product we need to identify early on, what are the brand values it stands for.

We need to consider the image it presents, and the identity that it will impart to its users and which delivers them emotional satisfaction.

Seth Godin, in his writing on marketing and his excellent podcast Akimbo, talks about the refrain that people repeatedly tell themselves. Namely:

People like us do things like this.

Seth Godin

Or, taken another way, “people like us use products like this”.

Seth explains that anyone involved in marketing needs to reach out to these people, to this audience. Because these are the true believers and advocates for your product.

Before we can do that though, we need to know what the “this” is.

We need to think about image – or the reflective qualities of our product (thanks Don Norman!). What are the stories that the product tells about itself, and which the user can then tell about themselves? Whether it’s a travel app that signals that we, the users, believe in fundamentally connecting to the places and people through which they pass, or a luxury sportscar that signals their owner has status, that they’re powerful and part of an exclusive group.

When we do this, we’re on the right path to deliver satisfaction and increase the chances of a successful product. So yes. Yes desirability is 100% part of UX.

 

A guide to roadmap planning with empathy

Recently I’ve been running roadmapping sessions and MVP planning sessions with Outlandish, the worker-owned tech agency.

Combining elements of design thinking practice as championed by IDEO and Stanford’s d.school, and mixing it together with great advice from Jon Kolko on how to think about emotions and roadmaps, they’ve gone pretty well.

Here’s a process for running something similar with your own teams:

When to use this:

  • Planning the future for an existing product, particularly one which might be underperforming.
  • Or planning a new product’s MVP (Minimum Viable Product).

If you’re working on a new product, you could run these activities as part of a Design Sprint. Some good places to do it are after the creative activities (sketching out initial ideas), or after the user testing of the prototype at the end of the Sprint.

Time required:

~ 0.5 day with your team

Step 1: Identify the users

Ask the team to identify who they think are the important users of the product. What do I mean by users? Not demographics, but rather people in situations.

No: An English woman in her mid 20s.

Yes: A press officer in a mid-sized NGO.

Yes: A press and PR team manager in a mid-sized manager.

Get everyone to write as many as they can, one per sticky note. They can hang on to their sticky notes for now, no need to gather them up.

Include the internal users

Whatever you’re building you’re likely going to have a few extra, critical users to think about. There’s the end user/customer, that’s for sure, but maybe you’ve got some wider stakeholders who connect with your product in some way to address; for example, other teams, external services, funders, CEOs and more.

Who do you have to convince your project is worth partnering with, building upon or funding?

Make sure that these people are captured as users too, because even though they might not be using the product directly, they still have an experience that relates to it.

Make sure you have a diverse range of users

In this situation, and if you’re running this process with a team, different team members will likely choose the most important users from their point of view.

On the off chance that everyone picks the same user, or if you’re running this with just one person, then encourage the identification of a few more users.

Step 2: Pick the most important user

Ask everyone to individually choose what they think is the most important problem and user. It’s good to say “important” rather than “biggest” or “urgent” or such here, as it leaves this open to interpretation. The criteria of “important” is up to each team member.

Everyone should make a note of their problem on another sticky note. Again, they can hang on to these.

Step 3: Turn the problem into a Point of View Problem statement

Championed by the Stanford Design School, a point-of-view (POV) “is your reframing of a design challenge into an actionable problem statement that will launch you into generative ideation”.

That sounds like fluff, but the key here is “actionable statement”. Rephrasing the problem into such a statement really does help stimulate creative activities. So here’s how we do it:

Everyone thinks about the user and problem they just captured. Take the problem sticky note and use it write a statement about your user, in this format:

[USER] needs to [USER’S NEED] because [SURPRISING INSIGHT]

One of the best examples I’ve seen of this, also from Stanford’s Design School, runs:

The project: Redesign the ground experience at the local international airport

The user POV: A harried mother of three, rushing through the airport only to wait hours at the gate, needs to entertain her playful children because “annoying little brats” only irritate already frustrated fellow passengers.

Note the surprising insight part. It’s not something broad and basic such as “because children annoy other people”, but something that believably conjures a real scene and is empathetic to the user (we’d all hate our own kids to be thought of as brats).

Ask your team to create their own POV Problem Statement for their chosen user on a third post it. Once this is done they can trash the problem sticky – they don’t need it anymore.

Ask everyone to read out who their main user is and their POV Problem Statement.

Step 4: Identify the value

We’re going to put the work done so far aside for a moment (we’ll come back to it shortly), and now think about value.

Jon Kolko, in his book Well-Designed: How to Use Empathy to Create Products People Love, has a great explanation about value and it’s worth getting his book to understand the importance of ‘value’ on a deeper level.

In short, there are many types of value: economic, social, personal, spiritual, emotional. Value is whatever the user feels it to be.

We’re going to ask our team to take a moment to think about the value that their user gets from using the product. For example, is it monetary savings (economic)? Increased influence in their network (social)? And so on..

Give it a few minute or so….

Turn value into an emotional statement about value

Now it’s not actually the value that someone receives from a product which is important, but rather their perception of and emotional reaction to this value which is most crucial. This is crucial to the idea of satisfaction, which, along with utility and usability, is a key component of UX.

So everyone needs to take the value they’ve identified and turn these into an emotional statement, from the point of view of the user.

In other words, everyone writes how the user feels after using their app.

It doesn’t matter that we don’t know what the solution is or what we’re building yet. But we can still imagine a future where our product exists and users are engaging with it.

And if we can imagine this, we can imagine how they feel after using it.

For example:

“After using our financial advice tool, the user feels comfortable and secure that they are making the best investment decisions with their savings.”

Everyone write a Value Statement on a sticky note.

Create swimlanes on the board

That’s already a lot of work and a lot of sticky notes! Now is the time when we come together and start to work more collectively.

Each member of the team takes their sticky notes for User, POV Problem and Value Statement, reads them out and puts them up on the board.

As facilitator, make sure they go up on the far-left of the board, with plenty of space to the right (you’ll need a lot of space in later steps). Also, make sure they are arranged in swimlanes, so it looks like this.

User | POV Problem | Value statement

User | POV Problem | Value statement

User | POV Problem | Value statement

The ordering and tidiness are important here, because things will get messy later!

If there are any duplicate users that’s fine, they can be merged. Talk about it with the team.

If there are duplicate users and duplicate POV statements, you might want to combine these into the same swimlane.

Step 5: Generate feature ideas

Now this is actually one of the hardest parts of the process, so stick with it and you’ll see some real gems come out at the end.

In short, you need the team to generate ideas for what their solution to this problem may involve.

If you’re doing this after already working up some solution ideas….

E.g. you’re running this as part of a traditional, Google Ventures style Design Sprint – then you’ll probably have some ideas and sketches already created to draw upon.  Maybe you’ve already tested a prototype and have some feedback too.

… else if not, and this is an existing product:

It might be worth pausing to:

  • show the existing product, just to refresh everyone’s minds about what it looks like and can do
  • review any user testing research already undertaken
  • pull out that ever-increasing list of ideas, suggestions and anything from the old backlog

Tip: to help facilitate this and ensure that momentum is maintained, avoid crowding around a screen. Instead, prep the room in advance:

  • post screenshots of the product up all over the place
  • put up quotes from users and test subjects
  • generally, provide a lot of eye candy around the room

… or if this is for a completely new product

If you’ve launched straight in to this and haven’t done any idea/solution generation yet, such as you might do in a traditional Design Sprint, that’s fine. However you’ll need to pause at this point to run some activities to generate some of these creative solutions.

I recommend taking a flip through the Design Sprint book and running the activities for Crazy 8s and Solution Sketches here.

  1. Crazy 8s: a brain-dump sketching exercise, each person making rough sketches showing a possible solution, 1 per minute), leading to…
  2. Solution Sketches: taking one of these ideas and, over a good hour or so, each person sketching out some key screens to show what the user sees.
  3. Then a presentation of each person’s work and the team decide which idea (or aspects of the various ideas) to take forward.

These will help decide the overall concept to be used in the next steo=p.

Capture the ‘epic’ feature ideas

Using everything that’s been researched and discussed so far, and the ideas proposed and decided upon, everyone jots down the large-scale features (here it is the user-facing functionality) that need to be built.

Write one feature per sticky note.

For example, for a financial advice app, large scale features might include:

  • Show customer finances
  • Share data with accountant
  • Email updates
  • Show market data
  • Live chat with financial advisor
  • Printable reports
  • … etc

Get the team up, read them out one by one and slap them on the board to the far right of your post notes.

Any duplicates or overlaps can be grouped together.

Tip for facilitators: People often forget to allow for building the common product features, so it’s worth prepping a few extra sticky notes in advance. Some typical examples include:

  • Update account information
  • 2 step verification / account security
  • Alerts
  • Social sharing
  • Charts, visualisations
  • … etc

If they’ve not already been added, make sure these go up on the board too.

Step 6: Get ready to roadmap

Identify the MVP or first phase features

Now, really channeling Jon Kolko’s great roadmapping exercise, each team member takes a note and asks their colleagues: can we achieve value for our chosen key users (and solve their problems) without this feature?

If yes, leave it where it is on the board. If no, move it to the left side and place it in the appropriate swimlane next to your User. POV and Value statement.

It’s a bit of an about-face and abstract way of looking at features, and you might have to explain it a few times to the team.

After all the team have reviewed these, you’re going to end up with a stack of sticky notes and features on the left hand side swimlanes, near the appropriate User, POV problem and Value Statements.

Well done! You’re halfway to having a list of features for your MVP or first phase of work. Draw a line to make sure these are all in a nice, tidy column. Then draw an axis along the bottom of the board to show time.

Break it down

However, in reality I’ve found that there are often still too many features for an MVP / Phase 1 of work, and many of these features aren’t minimal enough to be truly considered MVP features.

So what works now is to separate them out further and put them into a series of phases.

Draw some more columns on the board after the MVP / Phase 1 column. Each of these columns represents phases in your project’s lifecycle (not Sprints, Agile fans, we’re not at that level yet).

Now brief your team to think more about the features that are in the MVP column. Ask them to think carefully about each of these and spread them out more. Ask them to consider:

  • The extent to which this feature delivers the value – compared with other features, does it deliver a huge amount of the value, or only a small amount
  • The market size –  what % of your users are going to benefit from this feature
  • The return (or if you’re looking at income, the margin) on delivering that feature
  • Feasibility of delivering it (how challenging does it feel in terms of tech, resources, organisation buy-in etc…)
  • Can any of these epic features be broken into parts, (e.g. ‘send text message alerts’, then later ‘users can edit alert settings’)

And remember, the team need to keep asking: how critical is this? Is this feature really something that must be delivered in order for the first phase to work/deliver value/succeed?

It’s likely that once you get everyone thinking along these lines, they’ll start to realise that the features already placed in the MVP / Phase 1 column aren’t all critical, and many can be moved along to later phases.

You’re aiming to end up with a spread of features across the many phases of your project. This will take some time and needs good, relaxed discussion. So make sure it stays on the feet and at the board.

Hopefully at this point you’ll see a good list of feature ideas broken out along the board. There’s probably still going to be quite a few, so now is the time to channel your inner Design Sprint facilitator: break out the voting dots!

Choosing what to do:

Give people 3 or so dots, and ask each person to vote on which ones they think are the priorities. That should help agree priorities for work and effort.

And that’s it! At this point you’ll have a roadmap! You’ve identified your core users and who your roadmap serves; you’ve captured their challenges and value they’ll get from your product, when it is launched; and you have a roadmap of phased work and features to launch.

All that is left to do now is take it to your teams and stakeholders, and begin

And, of course, update it. Regularly.

Good luck with your products!

 

Building careers in UX

A few months back, I co-hosted a UX careers meetup with UX designers, as part of the Interaction Design Foundation – London branch.

Taking place at London’s Space4, it was a chance to discuss how we can grow in UX, how to find UX jobs, how to build careers, what makes a good UX portfolio and more.

In the spirit of sharing things of value, here are the notes from the day:

UX Interviews

Lauren, a starting-out designer, observed that in a recent UX interview, as her potential employers looked over her portfolio she noticed that they were more interested in the processes she went through in her work than the final design. They were interested in the research and the iteration, rather than the final output.

In a similar vein, Kayleigh from the tech agency Outlandish agreed that being able to show good process was an important skill and appreciated by prospective employers.

For example, when taking a test as part of the interview, if you do something so simple such as save out the work properly in a format that the wider team can use, this demonstrates that you know the correct processes.

Tools and the UX job search

This carried over into your choice of UX tools.

In short, amongst those who’d been to interviews recently, it was felt that interviewing companies didn’t seem that bothered about which tool you were most familiar with. It didn’t matter if you were a Sketch person, or XD person, or whatever; it was more important to demonstrate that you’re good with the process of design.

The tool isn’t you. You can learn the tool.

Wireframing skills and the UX job search

Kayleigh from Outlandish wasn’t interested in recruits showing finesse or fidelity of a wireframe, but more that they were able to demonstrate clarity of a concept.

“We value the skill of being able to sit, sketch on paper with a client and be able to show the user journey and layout. Our test of a good wireframe isn’t the finesse or straight lines. It’s whether someone can walk over and understand exactly what it is.”

Kayleigh Walsh, Outlandish

How to find UX jobs

“Call the company and tell them that you emailed. They like it and it’s a nice touch.”

Lauren

Lauren again observed that, one time, she missed the deadline to submit an application but submitted anyway. She called the company, told them that she’d missed the deadline but had submitted. And then she was added to the final round of candidates.

Kayleigh at Outlandish told us that Outlandish only work with people we meet. So we should all go to events! Go to meetups! Go to parties! Relax and chat to people there bout what interests you.

That’s how the Outlandish team discover interesting people and learn about the things that motivate them and they enjoy working on. From there, the Outlandish team might want to start collaborating with them and they’ll reach out to them to ask them to come to an interview.

Culture Fit

Does culture fit matter when you’re looking for work?

We all felt: yes. Because you’re going to be at the company every day, it’s important to research and find a fit that feels good for you

Tip: Research the companies you’re applying to. Look at their finished projects or portfolio. Depending on who they work with, you’ll get a feel whether this is a nice place to work in.

Ask yourself: Do this company work with nice people? Do they seem flexible? Are they ethical?

Again, Kayleigh from Outlandish, added:

“When we’re talking to potential designers, we want to hear that they believe in similar things that we do (fairer society, positive social impact, ethical behaviour etc). It’s important for us to work with people who aren’t just in it for the money.”

Kayleigh Walsh, Outlandish

UX Mentors

Get one. Mentors are really useful, either in a formal or informal capacity. And it’s easier to get one than you think.

All you need do is just ask a designer you know or are friends with for some occasional support or the chance to have a regular conversation… and hey presto, now you have yourself a mentor.

If you are looking for more formal mentoring opportunities, you can start your search at:

  • UXPA’s mentoring programme
  • Hexagon UX‘s mentoring programme, designed to support women and non-binary people working in UX.

“Hexagon UX’s mentoring programme is like speed dating for mentors!”

Tell employers what you’re learning

Is it worthwhile telling interviewers what you’re studying? Is it a good idea to tell prospective employers that you’re taking courses at the Interaction Design Foundation or elsewhere?

Yes. Tell people you’re doing courses. It shows you’re interested and always developing yourself.

UX hackathons

Rosie, a junior UX designer, advised that we should all do them. You learn so much, they’re very galvanising and the work you do there tends to go straight into your portfolio.

What happens at a hack?

You get mixed up into groups and work with people to make something. It’s intense. You also learn about the business case around the products you’re designing, which is something you might not experience in a learning environment.

It’s worth pointing out that anyone can join a hackathon, and you don’t need tech skills. Hackathons often have lots of developers and are actually short of designers. So if you go, you’ll be in demand!

There are hackathons everywhere. Small to big ones. And if you’re interested in political or ethical based hackathons, you can take a look at NewSpeak House, which often hosts politics-based hacks.

UX careers resources

  • Behance Live – they do a tutorial every day

This being an Interaction Design Foundation meetup, we also shared the courses we’re all doing and can recommend:

Coworking spaces – good to find work opportunities

We discussed how if you’re actually in a space you end up talking to people and collaborations and opportunities just tend to start happening.

So consider joining a coworking space that has a very open, collaborative atmosphere.

Space4 is just one such coworking space. Based in London’s Finsbury Park, it’s home to a lot of smaller non-profits and developer teams who would probably love to meet UX designers and collaborate.

A stay at Space4 might lead to a good conversation and a great portfolio project… or even might help a startup get funding and further paid work.

And that’s it! Those are all the notes. Hope that’s all been of interest.