seltar's soup - everything web

A few years ago, the company I was working for ran recruitment for an entry-level position in which they asked applicants to email over samples of their work as attachments. Aside from the work itself, I was fascinated to see the different filenames applicants had chosen for their attachments. Most of them were named according to the project they had come from or were just called something like sample_for_companyname. Some, though, used names like theirname_jobrole_application. I had a good feeling about those ones.

Whether you’re sending a file to a friend, colleague, or potential employer, context is important. The project title might have been a useful file name to applicants on their own computers, but to us – stored in a folder full of resumes and samples – it was meaningless. The people who’d told us who they were and what the sample was for in their filename had given consideration to the recipient of their application.

“That’s the spirit,” I’d say to myself. They were thinking like UX designers.

The point of this story is that we spend a lot of time thinking about people in the experiences we create professionally, but not enough time applying these insights personally. Doing so can help us create with less friction as we function within our teams.

A powerful mental model

When we’re designing, we often consider our audience’s mental model – how do they perceive the world? Mental models are created from a mixture of past experiences and assumptions. Computer filing systems offer a classic example. Files can be grouped together and stored in folders. People get that concept pretty easily because – just like real life filing – it fits their mental model.

Icons help interaction designers communicate abstract concepts; how can we do the same?

Consider mental models when talking to your colleagues and clients, too. If we talk about ideas in a way that draws on what they already know, it’ll be easier for them to slot new information in alongside it. We can use analogies to show how what we’re doing relates to something they’re already familiar with. I was once working with a client who wasn’t following the difference between client-side and server-side code, so we started using a shop window/shop storeroom analogy, with reloads being like a trip to store room. It made the conversation easier for both of us.

It works it the other way around too. Elements of our clients’ business that we’re not familiar with can be baffling, so we can try to make sense of abstract or complex concepts by suggesting comparisons. We might get the comparison wrong at first, but that doesn’t matter – it’ll still get them thinking about alternative analogies that do work.

Plain language

Clarity is essential to good design. There’s not much point in something if people don’t understand what it’s for or what it’s trying to say. This applies to any communication with our clients and colleagues, written or verbal.

Keep conversations, emails and documents straightforward. Professionally, we’d never fill a website with long text, written in the passive voice and packed with jargon, so we can’t let that kind of language creep into our emails either.

Other people might do it sometimes – people often get a bit strange and formal when they’re writing – but their job probably isn’t focused on how the person on the other end will react, so they’ve got an excuse. We haven’t.

Add helpful headings

Another simple way we can make ourselves clearer is by making good use of subject lines in emails, section headings in documents and slide headings in presentations. In her book, 100 Things Every Designer Needs to Know About People, Susan Weinschenk provides the following paragraph without a header:

First you sort the items into like categories. Using color for sorting is common, but you can also use other characteristics, such as texture or type of handling needed. Once you have sorted the items, you are ready to use the equipment. You want to process each category from the sorting separately. Place one category in the machine at a time.

It seems almost meaningless – abstract sentences about sorting things into categories. Then she shows it again with the header “Using your new washing machine,” and it makes perfect sense. As Dr Weinschenk says, “Provide a meaningful title or headline. It’s one of the most important things you can do.”

Keep everyone interested

We often think about how we can grab users’ attention, so we know it’s not easily done. Keeping it is even harder.

One of the best ways to stir emotion and grab attention is to employ a story. Think about how often we see case studies on websites explaining how something worked. Think about how charities don’t just give us statistics about the number of people in need of our help, they tell us the story of one person’s individual struggle. Stories, especially with characters we can relate to, make things more real, more memorable. The need for a story is the whole reason we use personas to help the team focus on who we’re designing for.

We need to keep stories in mind when we’re making a case for a particular design option. We can use a character – usually one of the project personas or a research participant – and tell the story of how the character would use the product and how they would react to it. Using a story like this to make a case will be interesting and memorable, which means it’ll be a far more persuasive than relying on statistical findings alone.

Cater to wandering minds

No matter how driven and committed the team is, people’s minds are going to wander. Research by Jonathan Schooler has shown people’s mind wander even when they don’t notice it happening, so almost no one is going to have caught one hundred per cent of what went on a meeting or a phone call.

We need to make sure that we allow for wandering attention by always doing thorough recaps at the end of any conversation. We can send summary emails around the whole team and ask everyone else to chip in and add a note if anything’s missing. This takes the pressure off any one person, and stops vital pieces of information slipping through the net.

Recaps are useful for both informal chats as well as organised meetings. If you came up with a great way to deal with that navigation problem with your developers while you were waiting for the kettle to boil, send a quick round-up email afterwards outlining what you agreed upon.

Give people control

The self-determination theory says that people find autonomy and competence most motivating. We all like to feel that we are in control of our own lives, and that we’re developing our skills and capabilities. These things motivate us far more than any external influences like earning more money or fear of the rules. We also like to feel like we’re getting somewhere so we’re constantly on the look-out for signs of progress.

Increasingly popular websites such as Treehouse make great use of this theory. Not only are they giving users an opportunity to take charge and develop on their own, but they’ve grouped tutorials into badges, giving people something tangible to collect in order to track their progress. It’s not the badges themselves that people are interested in; it’s the sense of achievement.

Applying this theory to our team has obvious implications for anyone who manages or mentors others – give them plenty of opportunities to develop their skills and give them freedom and independence in their work – but we can apply it to our clients too. They might have come to us for a service but that doesn’t mean they want to lose control of their project, and anyway, it’s likely that they know their business better than we do. We can’t confuse providing a service with taking over. We need to find ways to work collaboratively and help our clients feel as much ownership of the project as us.

Be careful to keep them in the loop, with frequent, informal catch-up calls. You don’t have to wait for scheduled deliveries to get their feedback. Even if they don’t want to actively contribute at every stage (or if you can find reasons why their suggestion isn’t the best) they’ll feel like they’re valued if you’ve take the time to ask their opinions. Sometimes it can be tempting to save things up for a big reveal, but this rarely has the effect we were hoping for. Clients will automatically feel more strongly towards an idea that they feel they had a hand in, even if none of their ideas made it into the final design.

Put yourself in their shoes

This one’s last for a reason – it’s what all the others boil down to.
UX design is all about empathy. We spend all day trying to imagine what’s it like to be the user – what they would want to read here, which button would they press there – so it shouldn’t be too much of stretch get into the habit of imaging what it’s like to be in our colleagues’ and clients’ positions, and thinking about what will make the design process easier for them.

We know that good design isn’t about us – the designers – at all. It’s not about showcasing our skills, or trying to impress anyone. It’s about giving users what they need and want. This mindset can be applied to whoever you’re dealing with. Don’t focus on making yourself look good, focus on making the team feel good.

Turning design principles inwards

This article considers just a handful of the psychological principles that we use every day. There are plenty more that I could’ve included – just think of all the lists of heuristics and design guidelines you’ve ever read!

Those design principles aren’t based on what computers can do or how code works – they’re about people. Our colleagues and clients are people too, so we need to keep the principles in mind all the time – not just when we’re thinking about our end product.

Each time you make a design decision, think about the principles that guided that decision. Then think about how that same principle can be applied to your team to consciously create great team experiences. The better we can make the process of designing user experiences, the more people are going to want get involved and embark on their own UX design projects. And that means better user experiences for everyone.

The post Designing the Team Experience appeared first on UX Booth.