🤠 Executive summary/TLDR

Consistency and reusability are the goal! — There is usually a different design that will get to the same goal if something is ever a major pain to build

Make calls and use your design intuition, but also please ask me to double check 😺 a note on the story is best

I will try to always explain the why of any design calls in that context, so we all grow in design skills

Personally as a designer, I would consider screens in zeplin to be a good map to what we are aiming for, but definitely a living document with space for compromise and conversation.

And I know that in the process of building a design, engineers make a lot of design decisions, in one way or another.

eg:

• How exactly is it responsive?

• How and when is the data loaded?

• How does this one thing stack at tablet-width which laid out in the designs?

• etc

So when it comes to making design calls in the engineering process there are some principles to know:

The big goal is consistency and reusability of components.

Yay for any decisions that help us to maintain consistency / reuse existing components!

Overall, it’s good for the user experience if the product feels super consistent, and I am always open to any suggestions you have on how to do that regarding reusability of components.

Anything that feels like an inconsistency or missed detail

If you spot an inconsistency in the design which feels like a mistake or a missed detail — ie.

• One thing looks visually like the same colour but is actually a slightly different colour

• there is a difference in spacing than what we usually use

• there’s one thing with slightly different data or info that seems like it’s not intentional,

then usually it is in fact a design mistake/missed detail and I will appreciate your help if you spot it :)

80/20 rule moments

In my experience at least, occasionally when building front end you hit the 80/20 rule, where you have a thing built to 80–90% pixel-perfect in 20% of the time, and then can spend the rest of the time f*cking around trying to get the final pieces to get in place to look pixel perfect….

I would suggest if you hit that point, reach out and have a conversation about it, as there’s a good potential there is some design compromise that can happen to hit the end goal of the user experience in some slightly different way that isn’t a major pain to build.

Generally immutable design philosophies: things to keep in mind when making design calls

Alignment (left, top, right) is SUPER IMPORTANT!!

If the left or top or right edges of things are aligned, they generally need to be. Bottom alignment is usually not as important, unless it’s something like a grid or a table.

Why?

A very core design principle is basically — if things are aligned to a grid they will just look better, which makes it look more professional, which makes the product look more trustworthy and feel more well-designed, which is good for a business. If the alignment is off the whole thing starts to look just… wonky and unprofessional

If in the build it looks different in a way that impacts the way the whole page or whole section looks.

ie. Changing the spacing within table rows from 4px to 8px would obviously change the feeling of the whole page as the whole table will be way taller.

vs. Changing the spacing between two unique elements from 9px to 12px = probably fine, but ask me to double check

Information hierarchy and visual rhythm

If changing something changes the information hierarchy or visual rhythm of the page. ie. If in the design, a heading is clearly “the first thing that catches your eye”, and in the built version it is no longer that, then it’s likely the core message of the design might have changed.

Ask: Does the visual element contain meaning?

ie. Sometimes a drop shadow can have no meaning and just look pretty. In other situations it can mean this element can be scrolled to the right or this is a modal on top of other stuff so you can close it. A keyline can have no meaning and just look nice, or it can mean this is a new section. If the design element contains meaning but is a PITA to build, then it’s probably still possible to find a compromise but will mean we have to find a compromise that could look different but communicate the same meaning.

Process: How to do design decisions in the eng process

1. I would appreciate a quick shortcut message + screenshots to double check — if you ever think it’s annoying, I promise it is not (this already happens and i love it)

2. question: if it would be picked up by QA, then does the design in zeplin need to be changed too? Or is recording the decision in shortcut enough?

3. Dev-design pairing about every 4 weeks?

For a smooth and focused user interview

Even though I’ve been doing user interviews for a while, I still write a conversation guide every time.

I know researchers who prefer topic maps, thought clouds or just keep all their goals in their head and wing it (dang!). But I still prefer a conversation guide — mostly for the process of writing it, more than the process of using it to any strict extent. Taking the time to pre-think about how I’ll phrase my questions, and what questions are most important to cover, makes the interview roll so much more smoothly.

I was talking to a client recently about the mindset you get into when you’re in a user interview, and we were trying to nut out why exactly it’s so exhausting. Definitely it’s because you’re always “on”. But what does “on” actually mean?

I think it’s because there’s a set of layers that almost every thought and sentence has to pass through to be said, and all of those layers need to be operating at an almost automatic level for the interview to feel natural and relaxed to the person being interviewed.

Here’s what layers are going on:

You’re listening to what they’re saying.

You’re thinking about what question you want to ask next.

Then you’re translating that question from totally leading-question phrasing into open-ended phrasing.

You’re also thinking about the topic they’re talking about, and measuring whether you’ve covered everything you wanted to cover in that topic. You’re thinking about how to smoothly transition this topic into the next one. And thinking about how you’re going for time.

On top of all this, you need to be really listening to what they’re saying, and focused enough on hearing it that you take it in, enough to actually learn from it.

And! As well as all this, you’re trying to create a sense in the room of comfort, trying to build rapport with the interviewee, be charming, build trust between the two of you and allow them the space to be honest and open.

And! There’s a high chance you’re also doing all of this while being observed by eleven of your colleagues, clients and stakeholders. Possibly being filmed too.

No wonder it’s exhausting. If it looks like you’re just having an hour long conversation, you’re making it look good.

This is why I write conversation guides with fully phrased questions. The process of pre-thinking about what I want to talk about with each interviewee, and writing out the questions beforehand helps take one of the stresses off. Even though I always go off-script (and in fact would never want not to), having those non-leading phrases and ways to frame questions prebuilt in my head is really useful.

Here’s how I write a conversation guide for a user interview.

Starting the interview

I always build in time for some small talk at the start of the interview. I’ve written before about making user interviews feel like conversations, and why a natural-feeling conversation with a person who’s feeling comfortable can result in far more open and nuanced insights. Building rapport is so important, if you can nail it.

So I’ll always spend a little time just chatting about how they got here today, how the weather is, whatever comes up. Don’t let them feel like a cog in the wheel.

Frame the situation, to help them feel comfortable.

Then we’ll jump into the interview.

I’m a big proponent of framing, whether it’s in sales, in facilitating meetings, or in conversations. How you set up the situation can have a massive effect on how the situation plays out. I’ll frame the user interview in the terms I want the participant to understand it: they’re providing me a service by providing their information and feedback.

I’ll give you a bit of background on what we’re doing here and why. We are part of the software design team here at Listen. Part of our design process is talking to people about how they think about topics we’re designing around and getting direct feedback on what we’re making, so that’s why we’ve brought you in today.

Just so you know, there are no right or wrong answers.

We have about an hour of your time, is that right? We’ll go through a few questions we have for you, and then do a little activity / show you a prototype.

Do you have any questions before we get started?”

Letting the interviewee know how long we expect from them and what the plan is also gives them a sense of security about what’s coming up. Nobody likes being at the mercy of a researcher and wondering what’s coming next.

Start with simple questions that are easy to answer.

Never skip warm up questions!

Think about how your participant might be feeling right now. Potentially, the only situation they’ve been in similar to this is a job interview. They’re liable to be kinda nervous - maybe wondering whether they’re fully prepared for this. The last thing you want is to get them feeling like a failure by throwing tough questions at them right off the bat.

“Tell me a little about you. Whereabouts do you live?”

“What do you do for work?”

“What devices do you use the internet on?”

Start to direct them into the mindset of what you want to talk about.

Warmup questions also serve another very valuable purpose — getting the participant into the mindset of what you want to talk about. If you want to learn about the ways people think about saving contact information, you can’t just slam that topic on them while they’re thinking about breakfast and expect to get interesting insights. You’re going to be better off starting asking an easy-but-related question and going from there.

“Do you have a business card?”

“When’s the last time you gave one to someone?”

“When’s the last time you got given a business card?”

“What did you do with it?”

“Did you ever contact them?”

“If you wanted to contact them now, how would you find their details?”

If there’s a ‘burning issue’, let them get it out early.

So, your participant knows they’re here to talk about business cards. They answered a screener with questions about their business card, they saw the sign on the door that said “Welcome, business card research participants”.

They’ve been running through everything they know about business cards for the last half an hour. It’s on the tip of their tongue. If you try to start by asking them about their wallet, they’re just going to, in some part of their mind, be waiting for the business card stuff to start.

Ask about that early and let them blurt out their story.

Reword leading or single word answer questions.

Now we’re getting into the meat of the interview. A trap I see people fall into a lot is asking leading questions. A leading question is one which, in its own phrasing, includes an assumption or a possible answer.

It can be especially tempting to fill in answers for people when you’re talking to someone who’s not very talkative.

“Why did you take a photo of their business card? Was it because you thought you might lose it, or you don’t like carrying them, or…*trail off*”

Don’t do this! Asking questions like this can skew your research findings, because the phrasing indicates to the participant that those are the answers you’re looking for. If they’re an agreeable person, they might (even without realising it) give you the answer they think you want.

You’ve laid a path of least resistance, and so now if their reasoning is different to the ones you suggested, they have to take a more difficult route to give you a correct answer. You made it easier for them to just agree with you.

Instead, just ask:

“What made you take a photo of their business card?”

And let them answer on their own.

Look for comparable behaviours rather than asking “would you use this?”.

It’s very hard to get reliable information about whether someone would use an app by asking them, “Would you download this app?”. It’s impossible to predict the future, so you’re at best getting their best guess.

Rather than that, a more interesting line of questioning is to dig for comparable behaviour that would indicate a desire to solve the problem you’re solving.

Let’s say our hypothesis is that people need an app to replace business cards for contact management. Perhaps we ask them to show us their contacts in their phone, and see how they’re managing their contacts on their phone now. Maybe we can learn a lot about what their problems are by seeing if and how they’re solving them.

Don’t be afraid to ask questions.

It might sound silly, but don’t be afraid of a direct question. It’s unusual how much we don’t ask direct questions of each other socially. Try it today: ask a friend a direct question, like, “What’s the best thing that happened to you today?” Does it feel a little bit odd or uncomfortable to ask it?

Now watch how they respond. I think you’ll be surprised by how comfortable people actually are answering direct questions about themselves. You might have to get over a little hump to get used to asking direct questions like this, but once you’re used to it you’ll be a better interviewer, and perhaps a better conversationalist too.

Ask one question at a time.

Another common thing that trips people up is asking long, drawn out questions that contain a bunch of words.

“When’s the last time you gave someone a business card, and why was it? And tell me about where it was and what happened before and after, and how you were feeling about it…?

The problem with this is that as soon as you’ve finished asking the first part of the question, the participant is probably poised to answer. They’ve like, already drawn the breath to answer, and for the rest of the time you’re talking they’re just waiting to talk — as well as now gathering in their head all of the different things you’ve asked, and they’re now feeling unsure where to start. It makes it harder for them to answer you.

Instead, try to ask one question at a time. “When’s the last time you gave someone a business card?”

Easy to answer. Un-distracting. And ask the rest of the questions as follow ups.

Gracefully signal you’re close to the end of the interview by saying:

“We’re just about coming up for time, but I have one final question for you: ___”

I use this phrase every time.

It can feel kind of awkward to end an interview. You’re working on building rapport, getting to know this person, having a really good conversation, and suddenly, you have to cut it off. By letting them know it’s almost over, you pre-empt the end without it feeling abrupt.

Wrap up with a final, broad question.

“We’ve been talking about managing your contacts for a while. Has this brought up anything else you’ve been thinking about lately that we haven’t talked about?”

Then throw it over to the note taker to ask any questions they’ve had during the interview.

I love it when people give me advice.

It feels like a mental hug, from one mind to another. The person giving the advice wants the best for me. They know things, and they want to share them. It’s a gift, and I receive it gratefully.

But as with gifts, each of them has a different role to play in your life. Some rare and excellent gifts become constant companions in your life — the things you keep around you, look at every day, and become part of who you are. And, as minimalist Marie Kondo wrote, sometimes the role of a gift in your life is simply to be a vessel for the good feelings the giver gets from giving it, and the good feelings you get from receiving it. Perhaps after that interaction, the role that particular gift played in your life has finished, and you can, with quite total good conscience, let it leave your life.

As with some advice I received recently. After I shared the next big project I’m working on with someone close to me, he told me:

“Don’t tell too many people about it, or someone will beat you to it.”

It’s the fear: if I tell too many people about this good idea, someone’s going to steal it and do it first.

I meet startup founders who have this fear sometimes. They start to tell me, with sparkling eyes and enthusiasm, about their startup idea. And I ask questions — I want to hear about it! I want to share their excitement! I want to engage with this concept! Maybe something I know that they don’t know will be helpful for them! And then at some point… they shut down. They look at me shiftily… start speaking in vague terms, hide behind a wall of vagueness and generalisations — and the conversation is over. They’re suspicious of my enthusiasm, and anyone else’s. They want to keep this to themselves, lest someone steal their idea.

Sadly, this is the moment I know it: their big idea will never come to life.

I wish I could tell them something I know, through experience: The more I talk about my crazy ideas, the closer to reality those ideas get.

To lock away an idea in your own brain, away from the light and sustenance of others' creativity, is to starve it of the water it needs to grow.

I’ve noticed this pattern over and over again. When I talk about my ideas or my projects, they move forwards. If I’m stagnating on something, all I need to do is talk to someone about it — and voila — it gets moving again.

To share is to grow. To hide is to wither.

There’s no one reason why. Humans, and therefore conversations with humans, are complex, multicoloured, unpredictable. Maybe my idea gets moving again after a conversation because the person gave me a new avenue to investigate. Maybe they mentioned a book, a podcast, or a documentary I should watch. Maybe they introduced me to someone. Often it’s simply because through talking about the idea, my enthusiasm was sparked anew.

So I share what I’m working on with other people as much as I can. Whether they’re strangers, friends, or colleagues. People who know a lot about the industry or people entirely outside the industry. People who I think could have useful knowledge, and people who had useful knowledge I would never have guessed in a million years. (Those are actually the most important ones, and you have no way of guessing who they are. Uber drivers are great for this.)

Of course, I understand why people hesitate to share their ideas. They’re afraid that someone will steal the idea, and get to it first. They’re afraid they’ll open up Facebook one day and see an ad or an announcement from a “friend”, and there it is: their idea, their precious idea, played out by someone else’s hand. It’s any entrepreneur’s worst nightmare, right?

Nope… it’s the worst nightmare of anyone who’s never actually made a big idea come to life.

There is a phrase: ideas are cheap.

I’ll add the unspoken second half to that: execution is expensive.

To execute on a big idea is an enormous investment. It takes time, dedication, investment, money, passion, people, knowledge, and a hundred other things. Who would devote themselves to that extent, to execute on someone else’s idea?

There’s another side to it too. Ask yourself: what is there about you that makes this idea something only you can make happen?

Who has the set of knowledge, skills, context, situation and network to make this work? Who has the time, the people around them, the knowledge, and the desire, right now? And if they do, would they throw caution to the wind and devote themselves to someone else’s idea? Unlikely.

For sure there are a few people out there who would be in a position to do the thing you want to do. But would they go ahead and devote themselves to your idea, for years, to make it happen? Making a startup happen isn’t an easy thing.

Nobody’s going to steal your execution.

Everyone should do retrospectives — not just agile software teams.

Agile retrospectives. If they have a reputation at all, it’s not for being very exciting. Not many people think: You know what? I freaking love retro! It’s just a meeting, right?

Wrong!

Why? Because great retros make great teams.

And great teams are the ones that communicate with each other. The ones that consistently make small course corrections to stay on track. The ones that trust each other, boost each other, share in each other’s successes and failures equally. The ones that know, without a shadow of doubt, that they’re all working towards the same goal.

Great retros are an amazing tool to get teams there.

Retros came from the world of agile software development. That’s where you tend to see them happening. But the more I speak to people about the retro process, the more I see the good word spreading. I have friends who are counsellors who do retros. Primary school teachers who do retros. Recruiters who do retros. I even have a friend who did a “marriage retro” with his wife.

For any group of people doing something creative or productive together — great retros will make you do it better.

So. How can you run your own great retro?

Here’s what you’ll need:

• The immediate team in the meeting

• A whiteboard + whiteboard markers

• Cheese, wine, or snacks of your choice — trust me, this is important 😊

Step 1: Invite the team

Retros need to happen regularly. I recommend once a week. Last thing on a Friday works well. Invite the immediate team earlier in the week.

Pro tip: Only include the immediate team who work together. Retros are a safe space to talk about everything, even things that aren’t going well. So don’t invite anyone who may compromise that feeling (think stakeholders and managers) — have them sit this one out.

Step 2: Snacks! 🍷🧀

A great retro is one where everyone feels relaxed, open, and up for a good chat. After a long week, consciously switching up the vibe can really help to take the team from normal mode to retro mode. Snacks, drinks, music — they all help.

The courage to speak truths, pleasant or unpleasant, fosters communication and trust. Wine helps.

— Kent Beck & Nicola Rushton

Step 3: Happy, wondering, sad?

Draw three columns on the whiteboard.

The first is the happy column. The second is the wondering column. The third is the sad column.

Now it’s time for everyone to take a whiteboard marker, come up to the board (together), and silently write in the columns.

Prompt your team. What went well this week? What questions do you have that we should talk about? What’s puzzling you? What was hard? What was just downright bad?

You can also have everyone write on sticky notes and just use a wall, if you’re missing a whiteboard.

Step 4: Talk about each item

Now, talk through everything written on the board, item by item. If you’re running the meeting, it’s your role to direct the conversation by picking which item to talk about next.

Pro tip: If it’s important enough for someone to have written it on the board, then it’s important enough to talk about. A great retro is one where everyone’s voices are heard equally.

Step 5: Create action items

During the conversation, listen out for action items.

Ask: Is there something we can experiment with next week to fix this?

Write each action on the whiteboard as you come up with them. Give each action an owner. A good action item is actionable and ownable.

If there are things on the board in the sad column, focus hard on coming up with actions to address them. If something isn’t working, think about what you can experiment with to try to fix it. Remember, the whole reason you’re here is to iterate on your process and keep getting better, one baby step at a time. That’s only going to happen if you actually make changes.

In next week’s retro, you’re going to check back in with that person. Did they complete the action? If they did, check it off the list. If not, it stays.

Step 6: Don’t forget to drink the wine.

Like you’d forget.

Step 7: Actually change things

So, a single retro can feel great — to air out feelings, to come up with some things your team can try, to talk about things that aren’t working.

But don’t forget the purpose of retro: to mindfully iterate on process. That means that you need to actually do the action items you wrote down. Nothing kills team morale quite like having the same old junk come up over and over again and doing nothing to fix it.

Take action to make changes. Listen to your team. Talk to each other. Be kind. There! You retro’d.

🦋 say hi on bsky: nicolarushton

A few years ago I was walking down Glebe Point Road after a pleasant morning at the markets. Suddenly, a guy with a big microphone came up to me and asked if he could record a vox pop for his podcast. I said sure. He pointed the mic at me and asked me, right off the bat,

“So. How has social media changed your life?”

No warmup, no intro. I went from walking along thinking about what I was going to make for lunch to being asked about the impact of a very large abstract concept on my life over the last decade or so.

Very hard to answer.

I was like, “ah… ummm… well, I was just using Instagram to stalk my ex from high school??”

I walked off feeling horrified at myself, like, I just gave the most vapid-sounding answer ever. Needless to say, I don’t think he used that soundbite in his podcast.

I always tell this story as an example of the purpose of warm up questions when you’re running a user interview. I definitely have things to say about how social media has changed my life. But that interviewer didn’t get to hear them! Knowing what I know now, I think how things might have been different.

He should have warmed me up.

If he’d asked a few easy questions first, easing in to the topic of social media and building up to the big question, I would have been so much better set up for success, and he would have got such better answers.

He could have asked first, “So tell me, what social media platforms do you use?” That’s easy to answer. Facebook, Twitter, Medium, Instagram, Reddit, Designer News, Quora…

Then he could have directed the conversation towards thinking about social media over time. “What was the first social media you used?” That would be MySpace for sure. Now I’m in the frame of mind of thinking about way back in 2006 when social media felt brand new.

“What did you do before you first used MySpace?” Actually. I remember, before MySpace, I used MSN Messenger in 2004–2005. Is that social media? I used to be obsessed with MSN Messenger as a teenager. I remember having conversations with friends every night and feeling like we could talk about stuff online that we would never talk about face to face.

Do you still feel like that?

Where do you have conversations online now?

Do you ever talk to people you don’t know IRL online?

How do you think social media is changing your life in that regard?

Has it changed anything else in your life?

…And so on. Rather than blindsiding someone with a slammer of a hard question — gently directing them into the frame of mind through the topic, until you naturally get to the thing you want to talk about. It might take longer, but I think it’s non-negotiable. Not just for the comfort of the interviewee, but for your sake, in actually getting the useful information out of their brain.

I wonder how many useable quotes that interviewer got that day, putting people on the spot like that.

He didn’t set his interviewee up for success, so he didn’t get good results.

That’s the worst thing you can do in a user interview — set your interviewee up for failure.

Here’s how not to make the same mistake.

Never skip warmup questions.

This story right here is the purpose of warm up questions — so you don’t do the equivalent of blindsiding someone on the street and getting in return a blurted out vacuity about Instastalking. Be kind to your interviewees and set them (and you) up for success, by taking your interviewee on a journey and building up to the hard questions.

Create a storyline.

Think about how you can create a storyline in a user interview. That might look like a set of questions you pre-wrote beforehand, or it might just be some scribbles on a piece of paper — the important thing is that you thought about how you could naturally get a person from zero to sharing good insights.

🦋 say hi on bsky: nicolarushton

The case for relaxing in user research

There’s something I’ve realised lately, that’s making my user interviews go smoother and getting deeper, more nuanced insights. I want to share it with you:

The key is this: relax.

Take a step back, for a moment. What is a user interview? If yours are like mine, it’s essentially sitting down with a complete stranger, asking them quite personal questions about their life, and hoping they’ll answer truthfully and openly enough that you can use what they say to design your product. It’s kind of weird, really.

Essentially, you’re fast-forwarding a relationship in just a few minutes, from first meeting to sharing life truths. How do you get there? How do you get them comfortable enough to talk to you and really share their truth with you?

The answer is build that rapport. There’s an art to interviews, and really, I think of it as being a sister to the art of conversation. I think when people are learning how to run user interviews, there appears this balancing act between ‘user interview skills’ and ‘social skills’. Sometimes social skills is the part that falls into the cracks when you’re learning the basic skills of user interviewing.

If you can level up by remembering your user interview skills and also relaxing and having a conversation, the person you’re talking to is going to be that much more engaged. If they’re engaged, what they tell you will be more natural, your insights will be deeper and learnings more nuanced. If they’re disengaged, you’ll get your yes, no answers, but they won’t feel like going deep, sharing their feelings, and opening up to you.

This is my argument for losing a little of the formality and relaxing —with the aim of creating a relaxed, friendly feeling of talking to a new friend, rather than the stiff, nervous feeling of being interviewed.

How can you do it?

1. Little things matter. When they arrive…

When the interviewee arrives at the office for their interview, I greet them at the elevator with a big smile and a handshake. Then I take them to the kitchen to grab a cup of tea, offer them a snack, make some small talk. How’s your morning been? Did you find the office okay? I want them to feel like a valued guest - my goal is for them to actually enjoy their hour with us.

Don’t usher them in and plonk them in a waiting room like the next in a line-up of people. Don’t let them feel like a cog in the wheel.

2. Build in time for chatty warmup questions.

I always ask warmup questions at the start of the interview - easy to answer things like What do you do for work? Whereabouts do you live? What devices do you have at home that use the internet?

Part of it is to get them used to talking, and feeling comfortable in the space. Part of it is to assuage their fears — maybe they feel nervous, like, “am I prepared for this? Are the questions going to be hard?”

Answering easy questions can help them breathe out and realise —yes — you’re perfectly prepared for today, just by being yourself.

3. Try and find out what they’re enthusiastic about.

Before I ask anything tough, I really want to see some spark of enthusiasm for the conversation in the person’s eyes. Think about your social skills again. You wouldn’t just jump straight to asking a deep personal question when you just met someone. You need to establish a little rapport, and a good way to do that is by getting them to talk about something they’re enthusiastic about.

What’s the last thing you watched on TV? What made you watch it? Where’d you grow up? What was it like starting that job? How’d you get into being a teacher?

Key to this is: Actually be interested in what they’re saying. You definitely can’t just ask “What’s the last thing you watched on TV?” and then jot down the answer like ok, good, ticked that one off. That totally defeats the purpose.

4. Embrace non-formal language. “I was like F&*# that!”

I love it when people swear in user interviews. I think that's a sign I'm doing my job right.

I deeply, almost desperately, want to know their real emotions about the stuff we’re talking about. If it’s internet outages we’re talking about, I want to know just how mad they were when Netflix stopped working and what exactly they said on the phone to Telstra at 11pm that fateful Monday night. If they can feel open enough with me to share the real truth and not censor themselves like they’re on their best behaviour in a job interview, then I am winning.

5. Try and create a smooth flow between questions, by engaging and actively listening.

If you’re actively listening, and you have a good idea of the general topics you want to cover in your interview, 80% of the time you should be able to smoothly flow questions and topics together in a way that makes sense and also covers most of what you wanted to talk about.

There’s a fine line between directing the flow of an interview and actually engaging in a conversation. You don’t want to talk much at all. But you can definitely engage with the conversation just enough to not seem like you’re a researcher.

For example, if you’re asking someone the last thing they watched on TV , it comes across as pretty weird if they tell you and you just reply, “Ok” and move on to the next question. It’s more natural if you’re more like, “I love that show too! What made you watch it?” It’s okay to engage with them a little. You don’t have to hold yourself behind a stuffy wall of researcher-formality.

6. Be open to learning stuff you didn’t expect, and going off-topic.

I like to think of a moderator guide more as a guideline. It’s likely in the course of your conversation they’ll bring up something interesting you hadn’t thought of before. It’s great to follow those paths and explore the unknown unknowns.

Where you stray off the map is where you start to really expand your knowledge about the area you’re talking about. You can only do that by actively listening and really knowing your moderator guideline. The benefits of following unexpected paths have often enough far outweighed the drawbacks of having a topic you only spoke about with one person. If it’s interesting enough, you can build it into the next round of research.

A caveat…

Relaxing and treating your user interviews more like conversations doesn’t mean you can throw away everything you’ve learned about being a good user interviewer! It’s still important not to ask leading questions, to ask storytelling questions, to give them space, not make assumptions, and all the other techniques you know. This is about relaxing just enough to connect with the user on a non-clinical level, so they feel comfortable talking to you and being open.

So what’s the takeaway? Relax! You’re talking to a human, who is sitting in front of you, being very kind to answer all of your nosey questions. Try to help help them feel like they’re talking to a new and curious friend, rather than a buttoned-up researcher, and watch how your insights blossom.

🦋 say hi on bsky: nicolarushton

This article has been translated for Chinese readers

Cross-functional collaboration, for empathy and results

Around about every two weeks, I spend half a day pairing with a developer on my team to fix design tweaks. I enjoy it — it’s fun to stretch my CSS muscles and spend a little bit of time with the code. I always walk away feeling good — like I’d had one of my shoes untied and now I’ve fixed them. Everything was just a little wonky before, but now the world is in order. 🙏 As a designer, fixing those little design tweaks is the difference between 😕 and 😍.

Before we jump in — what’s pairing?

Pairing is two people working on one problem at one time. Two mouses, two keyboards, two screens, two seats, two desks… and the screens are mirrored, so you’re working on the same thing, at the same time.

Why do dev-design pairing?

It’s a much faster way to communicate design tweaks.

I use dev-design pairing as a quick and easy way to iron out those final design tweaks in new features as they get built. Talking and doing the work together is way faster than trying to communicate fiddly design things in writing.

Sometimes the changes I want to make sound something like, “Fix up the spacing in the header.” For a designer it’s pretty easy to look at a header and see immediately what’s misaligned. But it’s super annoying to try to communicate that via text — especially as it can take a little bit of trial and error and doing things by eye to get it right. It’s so much easier to just sit together and talk than try and write, “Move left hand side of navigation ~10px to the left” and leave your developer having to work out how to make that happen in real life, and then work out whether what they’ve done is what you wanted. And then communicate it to you that they’re done, and then have you communicate back that it’s still not quite right, but you haven’t seen the code, so you don’t fully get why it’s just slightly off…

If you’re anything like me, after 2 rounds of this teeth-pulling traditional “design UAT” process you’ve more than had enough, and you’ll probably let the design go out to the world looking the way it is just to avoid any more rounds of tweaks. Plus, that time-consuming and frustrating process is exactly how engineers begin to hate designers. We don’t want that. Let’s all be friends.

Pairing timeboxes the 10% design tweaks that can take 50% of the time.

Product Managers love dev-design pairing because it allows them to timebox design polish tasks. Without a designer directly involved, it can take a long time for developers to get to final pixel-perfection. Because a mockup is silent. A mockup says nothing about where compromises can be made and where they can’t. If you can let stories be accepted for some time at 90% pixel perfect, you can sit together every few weeks and push through that final 10% that makes all the difference to how polished your product looks.

It grows empathy between development and design

I love pairing because it gives me the chance to talk through my design decisions with the engineers. They get to understand why decisions get made, what things are negotiable and what we’re thinking about for the future. And I get the chance to see under the covers on how the product is structured. That means I get to know what tasks are difficult and what are freebies, and means I can iterate on my designs in the future if it makes sense, to make things faster and easier for the engineers. Empathy is always number one, for your users and for your team!

How to do dev-design pairing in your team

1. Create your list of tasks

During the time between pairing sessions, I compile a list of things I spot in the product that I want to fix. I use a list of tasks in a story in Pivotal Tracker, because that’s the project management software my team uses, but you could use whatever format makes sense. Here’s an example of the kind of tasks I write:

The beauty of this is that because I’ll be there helping do the work, I don’t need to explain it any more than that 💁

2. Get some time prioritised

Book in a time to do pairing. Set aside a full morning or an afternoon. Personally, I find coding a little exhausting so I avoid doing full days or my brain will melt out of my ears by 4pm and my pair will be left to scoop me up. But if you are not like this, you could do pairing less often, for longer stretches.

3. Be a good pair

Here’s some tips on being a good pair in general. For designers and devs, there are a few other tips of my own.

• Always share the why. Don’t say, “let’s change this text size to 16,” when you could say, “Let’s change this text size to 16 so it’s consistent with the paragraph text across the rest of the app.” 
  The more you let your pair in on how you make design decisions, the more they’ll be able to make decisions like you after you’ve been working together for a while. Win, win!

• Have empathy for your pair. Coding is hard, man.

4. Have a quick pair retro

If you can do with communicating about how the session went, set aside 30 minutes to do a quick pair retro ( I recommend using Postfacto) at the end of the day.

Do I need to know how to code?

Nope. It’s helpful if you do, because you can jump in to the CSS/HTML and drive sometimes. But if you don’t know code, you can navigate! Ask lots and lots of questions and get your pair to explain what’s going on to you. You will learn so much!

Remember: Design pairing is for doing styling fixes only — nothing that conveys meaning.

The pairing sessions should only ever be for styling fixes — if there is something visual that is also conveying meaning, it should never be left behind to be fixed in a pairing session.

For example, a timeline. Without the line-through-the-dots styling, the meaning is lost. This isn’t a good thing to leave for a dev-design pairing session.

But — if the meaning is conveyed in the built version, but the styling is just a little off for the designer to be happy — then it’s a good one to leave to fix when you pair.

Equipment you’ll need

A pairing station is ideal. What that looks like is a desk for two and two monitors (one machine) set to mirror screens. Two mouses, two keyboards. How to set up a pairing station >

The only other thing you’ll need is an attitude of sharing and a willingness to learn. It’s not hard. And you’ll see results — better collaboration within your team, empathy between designers and developers, and a better looking product overall. What’s not to love?

🦋 say hi on bsky: nicolarushton

Interview and question techniques for UX researchers

So it seems I have a thing for documentarians. If I ever have a celebrity crush, it’s on a geeky dude bumbling around the world talking to people on camera. I’m talking John Safran, Adam Richman, Louis Theroux. Sure, part of it is that I think they’re cute, but I think part of it is I want to be them.

It’s a beautiful thing to meet someone new, and just connect with them in the right way so as to get to that moment. When suddenly they’re telling you all sorts of things they never planned to and you’re looking right into what the world is like for this other being walking around on the same patch of dirt as you.

In the last month, I made a study of everything Louis. I binged on all his phases - from the gangly guy in the 90s being scarred by sex parties, to someone who can walk into the world’s worst prison and casually ask a prisoner personal questions like they’re having a chat over coffee. Louis is kinda my hero. I try to be like him. In conversations with my friends, when I meet new people, and especially in user interviews.

Louis is an absolute master of the interview. Seriously, this guy can ask anyone anything. Remember when he rocked up to the Nazis house? Within a few sentences, he was saying to him, "the neighbours said you’re scary. Are you scary?" And the Nazi guy just laughed!

So what can we humble researchers learn from the master? Well, here’s a few things I have noticed that he does so well.

He gets on their level.

He mirrors, he validates, he treats them as equals. He uses their language, and asks them to teach him things as they would a new member of their scene. He literally gets into their world, and tries to experience it from within.

Even if he’s uncomfortable, people open up to him because he’s open to learning about them. He doesn’t act like a researcher looking down from above — he’s right in there, naked in the hot tub.

How can researchers use this technique?

• Mirror the interviewee. Mirror their energy, mirror their body language, use the phrases and terminologies they use. That might mean using the ‘wrong’ word for some tech stuff but just roll with it.

• Get in the user’s world, by doing as much immersive shadowing and contextual enquiry as you can. Try to understand their world from within. Feel like a brand new member of their world. Ask to be taught.

He’s friendly.

And what I mean by friendly is that he treats them as a friend. He doesn’t hold himself back behind cool professionalism. He gently ribs them if they say something dumb, he pushes back sometimes if he wonders if they really mean what they say. He jokes around with them like he’s known them for years. That kind of rapport, where someone feels like they’re friends with you, is irreplaceable.

What he’s trying to do, making a documentary, is get people to open up and tell him about their lives, their inner feelings and truths — they’re not going to do that if they don’t feel like they’re talking to someone who cares.

How can researchers use this technique?

• Ditch the pre-planned questions, for goodness sake. Have a conversation with this person. Be nice to them! Make them a coffee. Ask them how their day’s been.

• Be friendly. Can I say it again? Be friendly. Like them. Show them you like them.

He never judges.

Louis is my hero because he’s so entirely, so completely un-judgemental. And I don’t believe he’s acting un-judgemental. I think he actually doesn’t judge them. He’s here to learn, not to judge.

He doesn’t lay his own expectations or experiences over theirs. He’s open to hearing and learning about this person in front of him, without expectation. That is golden. That is kind of the key to human relationships, in my opinion. But it also definitely helps with research.

How can researchers use this technique?

• Be aware that your expectations colour how you see every person in this world. Try to take each new person as a new experience, without letting your preconceptions cloud how much of what they say you actually hear.

• Practise your poker face. You really don’t want someone you’re interviewing to see if you’re surprised or shocked or think the 5-step process they use to find the Google homepage is hilarious.

He pushes.

In a loveable kind of way - but he pushes. If they’re not giving him info about the thing he wants to talk about, he’s not afraid to ask again.

The only way he can do this is by establishing rapport beforehand. Pushing is an advanced technique! He can only do this when he’s established that they’re friendly, that he’s open to them, and they’re open to him. Pushing too hard is risky, but it pays off when it works.

How can researchers use this technique?

• Use your 5 whys. (Though personally I don’t love the word “why”. It’s too direct. Usually I phrase a “why” more like a “what made you do it that way?” or a “what do you think went into that decision for you?”.) Nevertheless, push for deeper information when something is interesting.

• Sometimes towards the end of a usability interview (with interviewees I have good rapport with) I ‘open up the curtain’ and just talk to them like a colleague. I’m totally open about what I’m trying to find out, rather than trying to avoid asking leading questions. Sometimes this leads to really good insights — they start to really engage with the prototype and think about it like they’re designing it for themselves.

So I don’t think I’ll ever be as good as Louis, as much as I wish I was — and I don’t know if I’ll ever get the chance to find myself in the kind of situations he has. But as a researcher and general explorer of people, the more open, bendy and non-judgemental I am, the more I learn about people and the bigger my world gets. It’s pretty magic.

So what’s the takeaway from all this? Well, if you’re a designer or a researcher, or maybe just a person who wants to connect with people better — it’s always a good time to go watch Louis again.

All credit to nocontextlouis for the images. Do yourself a favour and follow them, they’re hilarious.

🦋 say hi on bsky: nicolarushton

Accessibility is for everyone. Following best practises doesn’t just mean that people living with a disability can use your product — good accessibility is also useful for lots of other people. Maybe they’re in a poorly lit space, or are carrying a baby, or using just one hand while they’re standing up on the bus. Here are some resources I use regularly.

Colour blindness

Sim Daltonism on the Mac App Store
A free mac app that allows you to see anything on your screen the way someone affected by different types of colour blindness would. Very helpful for checking your designs are communicating the same information to everyone, regardless of their perception of colour.

http://www.aremycoloursaccessible.com/

Engineering

Teach Access Portal
Learn best practices for making accessible mobile and web apps.teachaccess.github.io

Polaris (by Spotify) on Alt text
Alternative text helps people with low or loss of vision use products.polaris.shopify.com

Designing accessible products
A comprehensive visual guide to making web technology available to a diverse world.uxdesign.cc

React / Single Page Apps

Facebook outfits React with Accessibility API
Facebook is fitting its React JavaScript library and the accompanying React Native mobile framework with an API to…www.infoworld.com

Making React Native apps accessible
With the recent launch of React on web and React Native on mobile, we've provided a new front-end framework for…code.facebook.com

reactjs/react-a11y
react-a11y - Identifies accessibility issues in your React.js elementsgithub.com

Here’s a few of the things I’ve learned.

1. It’s all about the action items.

At their heart, the point of having retros is to enable a conscious sense of shared ownership of the team’s process. We are the team, and we work out how we can be most productive together. Retros help us to iterate on that process week to week.

To that end — the really important outcome of a retro is the action items. If someone has brought up an issue, then we want to do something to solve it.

“I’m always steering people towards actions.”

On that note…

2. A good action item can be owned.

Some people we spoke to seemed to report using action items almost as a cathartic moment —someone has brought up something they need to talk about, and writing down an action item together as a team is something like a denouement for that conversation — committing together to change something.

For that to happen, an action items should always be owned by a single person. If it can’t be owned by a single person, then it needs to be rewritten. For example: don’t write 
“Keep desks tidy (team)”.
Write 
“Schedule team desk tidy-up on calendars (Nicola).”

3. Being able to show personality in a retro is good… because team bonding is good.

For good, productive, open retros to be able to happen, there needs to be trust in the room. A nice side effect of having ‘wine and cheese’ retros on Friday afternoons is that it feels a little bit like just enjoying each other’s company.

With a whiteboard style retro, people can get creative and show some personality with how they draw the smileys in each column, or how they +1, or how they interact with each other’s items. People scribble and draw.

“With a whiteboard retro, we can draw a sparkly unicorn instead of a happy face.”

4. Seeing people’s faces is really important, because it’s all about communication.

We asked people what their focus is in a remote retro — and it’s really all about the video conference with the rest of the team. Retros are about conversations — so of course seeing someone’s face helps.

“When you can see a person, you can empathise with them. Things get lost in translation without face to face.”

5. Timed conversations makes the retro run on time. But not having to be the ‘time cop’ is appreciated.

I’ve sometimes seen people use timers for conversations in retros, putting 5 minutes on the clock when we start talking about an item and roman voting on whether to keep talking if we hit the time limit. But the extra work around making that happen is a barrier to entry. Opening your phone, breaking the flow as facilitator to start the timer, remembering to do it for every item, resetting the timer when conversations organically come to an end — we observed it being just slightly too annoying for it to ever feel natural.

It’s key to our philosophy that you should always get through all of the items on the retro board. For a successful retro, everyone’s voice should be heard.

“To run a good retro, always keep an eye on the time.”

6. The less communication in the team day to day, the more crucial the retro is.

Empirically, it seems rather obvious that when a project is going smoothly and a team is working well together, retros are easier.

We found this was true with everyone we spoke to. There’s a definite correlation between the amount of regular, day-to-day conversation, and the importance of the action items created during retro. If everyone’s sitting together and chatting about things as they come up, then a lot of the conversations might have already happened by the time retro rolls around.

This is desirable, whether the team is colocated or remote. But it’s so much harder for remote teams to get to that point of maturity.

So for remote teams, retro can be a really important chance to have those conversations.

“We communicate a lot through the week so we don’t need to wait for retro. Occasionally a point will come up that isn’t actionable — people just want to let off steam or celebrate achievements. ”

7. Talk about everything on the board. Don’t skip anything.

Some facilitators have the team vote on retro items before the conversation, and order the conversation by what has most votes.

This can be a useful tactic if there are a lot of people in the meeting and/or a large amount of retro items. But whenever humanly possible, you should talk about every single thing on the retro board.

“Make sure everybody is heard.”

Retro is just one practise that helps to build a great team. Talking about every item helps to make sure everyone knows their voice is valued and equal. Setting aside time each week purely for team communication and reflection builds a sense in the team that they can trust each other and that feedback is encouraged. And getting through every retro item helps to make sure everyone’s voice is heard. These are the philosophies that are driving us building Postfacto.

I’d heard of it, and being fairly risk averse, and not a massive partier or a huge fan of crowds of drunk Aussies I’d pretty much decided to steer clear of Vang Vieng altogether.

However, it’s a logical stop on the way from Vientiane to Luang Prabang, and needing to break up our 12 hour+ bus trip between the two, we decided to stop there and take a look.

What we found there was slightly eerie. It’s not quite a ghost town in rainy season, but it’s close. In the town area, there are streets upon streets of mostly empty reggae bars, Aussie bars, and massive restaurants playing reruns of Family Guy and Friends on booming TVs to rooms full of low tables and cushions, but mostly void of customers.

Most of the riverside bars (in fact, all but one) have been closed down by the Laos government after the deaths and bad press.

After deciding on a cheapish hotel whose construction appeared to have been halted at about the midway point (stairwells leading to nonexistent floors, boarded-off upper hallways), we stole a night’s sleep in a room with a tiny balcony which past the decaying roofs overlooked a stunning vista. On the edge of town, the wide river winds sleepily between stunning limestone karsts: surreal, tall rocky outcroppings that jut suddenly out of flat earth.

In the morning we ate what seems to be the tourist breakfast du jour in Vang Vieng — hyper-westernised versions of Laos street food rolls, with any and all combination of fried meats, eggs, cheese and salad. A remnant of French colonial history, baguettes and bread are as big a part of Laos food as Vietnamese. Like the restaurants and bars, the stark difference between the vast number of street food stalls and the dwindling number of customers speaks to the decline of the town as a tourist destination. Stall holders almost beg you for your custom, and when there’s 6 or 8 identical sellers within eye sight, they need to be charming to make a sale.

Despite my reservations, we decided to give tubing a go. Not knowing the circumstances of the deaths but having heard about them nonetheless, I’d imagined tubing to be something like drunken solo white water rafting, possibly with crocodiles or leeches thrown in the mix.

I couldn’t have been more wrong. The inner tubes are hired from a business in the town, who then bus a group of you upstream in a tuk tuk ute. The group in our tuk tuk consisted of myself, my partner, and a southern Chinese family of two teenage children, their parents and an older aunt.

The river is very slow and relaxed. It’s not a hair-raising ride, even in rainy season, when rivers all across Southeast Asia are swollen and faster. I believe it would have been possible to actually ride the river the whole way down without even getting wet, if thats what you wanted.

My only conclusion is that the only way people could die doing this is that in any country, drinking and swimming probably shouldn’t mix.

Almost as soon as we splashed our way into the narrow part of the river that was moving quickly enough to get our tubes moving downstream, we were hooked in by workers from the first bar along the river. It’s a chilled out jungly kind of spot, with a DJ, tourists in bikinis and board shorts, a volleyball net and drop toilets. We chugged a couple of cheap cocktails and then, expecting more bars to be coming along soon, hopped back in the river.

The float down the river is a stunning experience. Travel without the intrusion of a noisy motor or the isolating windows and walls of a bus is a rare and beautiful experience. From your utterly relaxed vantage point in the river it’s possible to see and hear birds nesting on the karsts, feel the temperature of the water and the air and see the wide sky above you. As we meandered down the river, hands trailing in the water, the sun set slowly above us, washing the sky in pink and peach, the thin clouds vibrant with colour turning the rocky karsts into toothy silhouettes.

As we floated further and further downstream, kayaking groups and slow-moving tourist boats passing us by, we began to realise that there may not be any more riverside bars. We stopped at one or two and found literally nobody there. We saw a few gutted out spots with what looked like the remnants of tyre swings, but other than that it was peaceful.

Just as we started to worry that we’d miss the end point of the tubing ride in the rapidly waning daylight, we skidded up onto a shallow sandy part of the river. It appears the town is built around a shallow area of the river, and it’s impossible to float past it. I admit I had visions of floating obliviously past the town in the dark, missing the exit and plummeting down a waterfall in the depths of night, but the river shallows to a depth of perhaps 30 centimetres close to the town, and you’ll find that your tube will run aground naturally.

As we scrambled barefoot up the banks and trudged back to our hotel, returning our inner tubes just in time to avoid a fine along the way and stopping to glance idly at souvenir shops selling Tubing branded board shorts and waterproof bags, I was glad I decided to try it.

In terms of stark karst-dominated landscapes, Cat Tien national park in Vietnam wins over Vang Vieng and Ha Long Bay hands down. Still, it’s a convenient rest stop between Vientiane and Luang Prabang, tubing is nice, and those breakfast rolls are pretty awesome.