What walls are for

Earlier this week I did a talk at the Mind the Product conference in San Francisco. I was talking about research, but now that i work at Atlassian, the examples I gave included some from the Jira team’s work.

I also showed a slide that was a photo of a team, gathered in a meeting around a wall covered with index cards. No one in the meeting had their laptops out.

This is what people seemed to want to talk about over coffee later in the day. Could it be true that I, spokesperson (one of many) for Jira, would possibly want to see stuff on the wall?  Surely it should all just be in Jira right?

People told me they messaged photos of the slide back to their teams to show them – ‘look, the Atlassian person says it is ok to put things on the walls!’

omg yes. I love walls with post its and index cards stuck on it and sketches on whiteboards. I like walls for planning, for thinking, for communicating and for analysing. And then you capture it all in a tool, like Jira.

This is why.

Walls make it easier to iterate

Digital things look ‘finished’ too soon. when something is a work in progress on a wall, it looks unfinished, so you keep working on it. moving things around, reshaping things, connecting things, erasing things, and making them again. Walls make it easier to iterate. Iteration, in my opinion, is massively correlated with quality.

This is why walls are good for sketching out design ideas and processes. This is why they are amazing for research analysis (don’t care what anyone says, post it notes are still the best tool for research analysis for exactly this reason – no one ever does three (or more) rounds of synthesis using a digital tool).

Walls make it easier to collaborate (in a single location)

There is something about a group of people standing in front of a wall full of sketches, or index cards or post it notes. Its a different kind of collaboration than you get around a table, or in a digital tool. You’re usually standing up, so you’re paying attention, you’re focussed. People physically pick up the card that they are talking about and something about that seems to pull focus even more. Doing a stand up at a physical wall and moving the cards across to done has always felt a lot like the physical act of crossing something off the to do list – so much more satisfying than updating a status on an issue. The messiness of a room full of post it notes when you’re doing analysis almost compels you to finish making that sweep through the data… finding the best place, for now, for every sticky note of data. There is something about the physicality and the embodiment of the work that I have always felt binds teams together more, drives us to do better and more complete thinking about the work we’re doing. There is no science to this just many years of experience. Walls just work better for me, when I’m lucky enough to work in the same location as my team. Walls do suck at remote and distributed teams.

Walls make it easier to communicate

Sometimes the walls are not for you but for other people. Sometimes walls are to send a message. They can say – ‘look how many things people want us to do, this is insane and someone needs to prioritise this’, they can say ‘look how much we’ve done this sprint, yay!’ or ‘look how much we have left to do, uh oh!’, they can say ‘these things are really important to our team, this is what we believe it’, or they can say ‘here is what we’re working on at the moment’.

I’ve been in, and observed many teams who use walls to communicate either the most important messages to the team in a kind of omnipresent way – this is what we believe it, or this is what we are focussing on right now, or these are our values, or here is our goal.

Or sometimes they are designed to communicate to bosses and stakeholders – those walls might say ‘we’d get the things we’ve promised done if you didn’t always sneak in all this unplanned work’ (I’ve seen a few of those).

Some people I’ve know have had jobs that include keeping the digital tool up to date with the wall. Or the other way around. Its not inefficiency. The wall is doing different things for the team.

And that’s another great thing about walls, it doesn’t need to be a zero sum game.

If you’re using Jira, using a wall makes perfect sense to me. I don’t know why you’d do without.

related reading: Alan Cooper – Know whiteboards, know design

From insights to actions. Or, what should we do with this research?

So what should we do with this research?

This is a question that researchers often hear at the end of a playback session. Especially one where we’re sharing findings or insights and not detailed recommendations of what to do next.

Most of the time there are two questions that teams should ask themselves:

  1. Which of these problems/opportunities do we care about now? If you were going to prioritise, which are the most pressing? Which might contribute most to the team meeting goals?
  2. What do we think we could do that might make things better for our users? What different things could we do that might address this opportunity?

A good researcher can help a team understand what opportunities are available to pursue. They will help you to see a problem in a different way – to frame the problem from the users point of view.

But you shouldn’t expect the researcher to come back and ‘tell you what to do’.

From insights to actions

Getting to actions from insights is a team sport that requires a range of inputs. The researchers role is to make the ‘user’ input as rich and insightful as possible. They should then to work with the team explore and evaluate the possibilities that emerge.

What makes an insight actionable?

To make a research insight actionable it must answer two key questions:

  • what is happening?
  • why is it happening?

Research that is not actionable answers only the first of these questions. If we don’t know why something is happening, we are not well placed to contemplate what action we should take.

The better the ‘why’ explanation, the better equipped a team will be to come up with clear and confident actions in response.

Research alone won’t tell you what to do

Sometimes when people say they want the research to be actionable, what they really mean is that they want the research to tell them what to do. They want research to answer a third question:

  • what should we do?

Sometimes the right course of action is 100% obvious, but often that is not the case. It would be a foolish or naive researcher who thinks they have the full set of knowledge required to provide this answer.

User research is just one of the pieces of information that product managers or designers need to decide what they should do.

Lenses for decision making

To make a good decision about what to do next, the team really needs to look through at least four lenses:

  • what is the user perspective?
  • how does this align to our product strategy?
  • what are the technical (feasibility) issues?
  • what are the financial/business implications? (cost / revenue)

Or, to use a more familiar framework, is the solution desireable, feasible and viable.

Image: Niti Bhan

Most of the time, user researchers aren’t in possession of this full set of information. They will likely have strong and informed views. But don’t be disappointed if they can’t point you straight to the perfect solution.

Designers and product managers are usually much more expert in coming up with and evaluating solutions.

Designers are trained to take a problem and think about how you might be able to take many different approaches to solving itTeams should use the designer to make sure they’re generating and evaluating lots of possible solutions.

Product Managers tend to be the experts in balancing all the different needs and helping the team to choose the best of the solutions on offer.

Researchers can help represent the end user perspective through out this process. They can play a role in helping design a way of evaluating proposed solutions from the users point of view.

Other team members are also vital in this process.

Engineers and technical representatives giving the feasibility perspective (and quite often some pretty amazing possible solutions that the designers might have missed).

Analysts and data scientists providing a different useful data sets to contribute to evaluating solutionsSometimes a colleague from legal, or marketing, or other parts of the organisation can be very useful in this process too.

Getting from insights to actions is a team sport

Its the responsibility of the researcher to make sure that the insights they bring to the team are useful. They need to explain the why and not just the what. But moving from insights to actions is a team sport and needs all the players to participate.

Five user research rules of thumb

Over years of experience you begin to collect ways of working and talking about how you work that accrete into rules of thumb. Here are some that I reference pretty often. I’d love to hear others.

  • One hour / day of analysis for every hour / day of research. 
    (I’m pretty sure that back in the early days it used to be 2:1 ratio but that was Before Agile. These days 1:1 is considered generous, but it is entirely necessary. If you don’t intend and allow time to do the analysis, don’t bother doing the research IMHO).  There are some thoughts on doing research analysis in agile teams that I mostly agree with here.
  • The 70/30 rule
    Researchers should spend 70% of their time communicating, helping (and persuading) people to understand and act on the research and 30% of their time actually doing research. More on that here.
  • The two week rule
    Don’t design anything for more than 2 weeks before you watch people using it. More on that here.
  • More than three, less than ten
    Working out how many people to recruit can be tricky. It is much more important that you just get started doing research and keep doing it, than it is to tie yourself in knots working out sample size. That said, three people is almost always too few. For qualitative research, in the first instance, ten is very often more than you need. More on sample size here.
  • One researcher per team
    Don’t spread researchers thinly across a bunch of teams. Researchers working across multiple teams tend not to be able to do the 70/3o rule and their research is less effective and impactful as a result. If you don’t have enough researchers to do this, prioritise your projects, let researchers do a good job for at least one team rather than a mediocre job for everyone. Also, you should read this as ‘at least one’ rather than ‘only one’. Some teams require multiple researchers. Avoid discussions about ratios of researchers : designers : devs whenever possible.

I’m aware some of these are a bit contentious, but they’ve worked for me. I’d love to hear any you’ve been using that work for you.

Collected UX research posts from my government days

I’ve taken some time over the new year to repost some of the blog posts I wrote while I was working in government. These were originally posted on government blogs, first in the UK and then in Australia.

Can’t guarantee I still agree with everything I wrote back in 2013 but perhaps you’ll find something useful here.

How we do user research in agile teams (GDS 2013)
This was probably the first time I’d ever seen user research work really well in agile.

User research not just usability (GDS 2014)
It’s pretty typical in low maturity organisations that they think usability testing is everything that user researchers can do, right?

What user researchers do when they’re not researching (GDS 2014)
First time I wrote about the old 70:30 rule…

It’s user research, not user testing (GDS 2014)
Call me a pedant. I still think it matters.

5 ways to help user research work better in agile (GDS 2014)
Summing up things that I found myself saying over and over again.

Sample size and confidence – how to get your team to trust qualitative research (GDS 2014)
My response to the ‘oh, but its not statistically significant, how can we possibly trust it’ objection.

Anatomy of a good sticky note (GDS 2014)
The building block of good research analysis. Surprising how few people get it right.

So, you’re going to be a user researcher: top tips to get you going (GDS 2015)
What I recommend when people ask me how to get started with user research.

Doing user research in the discovery phase (GDS 2015)
No, discovery is not for validating the ideas you want to proceed with, it is – surprisingly – to discover,

We need to talk about user needs (GDS 2015)
User needs are not user stories, they are so much more!

Improving internal services and tools to help make the end users experience better (GDS 2015)
A few notes on the particular challenges and rewards of doing internal facing user research.

How might we improve the voting experience? (GDS 2015)
Very occasionally I got to actually do a tiny bit of research rather than just fighting off bureaucracy so that others could do great work. This was one of those times. The other time was the Welsh project.

‘I want a pony!’ or the critical difference between user research and market research (DTA 2017)
The evergreen discussion of why user research methods are different to market research methods and how they’re both valid when they’re used for the right things in the right ways.

Why we say no to surveys and focus groups (DTA 2017)
Why many organisation’s research tools of first choice is generally my tools of last resort.

There were a few more blogs from DTA days but they were very project specific so I’m going to leave them where they lie for now.

And, of course, the summary of that government experience:
If I could tell you 3 things – notes from a brief career in the public service

And hopefully, if the new years resolutions hold, some more original content soon.