What walls are for

Leisa Reichelt2 Comments

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?

Leisa Reichelt2 Comments

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 it. Teams 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 solutions. Sometimes 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.

Passwords that make you feel good

Leisa Reichelt1 Comment

On my first day at Atlassian, when I was first got my macbook and was setting up my password I had one of my favourite ideas.

Having a good secure password is important. You can (and should) use password managers so that you can have lots of different very strong passwords.

But perhaps for one password you find yourself typing in very frequently you might try something different… I think of it kind of like a password mantra. I like mine so much that I sometimes choose to type in my password rather than use my fingerprint to get into my computer.

Here’s how you do it:

  1. Think of a positive, affirming message that you’d like to tell yourself multiple times a day – it might be something about thinking more positively, living more healthily, swearing less often… whatever is your thing. Just make sure that you turn it into a positive message and not a personal rebuke.
  2. Then make a little passphrase that would be a good reminder of your affirming message. Check to make sure it is nice and strong and add a capital letter or numeral or something if you need to (to make it stronger or to meet whatever annoying requirements the system you’ll be using it for requires).
  3. Use this passphrase somewhere you need to sign in on a regular basis. (eg. your single sign on password for work).

Et voila –  a password that is not only secure but also a micro-moment of positive affirmation when you’d least expect it.

xkcd comic on password strength

Five user research rules of thumb

Leisa Reichelt8 Comments

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.