Adaptability – Essential Soft Skills for User Experience Practitioners

As User Experience practitioners, we spend an inordinate amount of time thinking about the skills we don’t have or have enough of and trying to acquire them.

I don’t hear a lot about the soft skills that, in my opinion, are probably more important than all of the CSS, sketching & typography skills you seek so I thought I’d contribute a short series on some of my favourite soft skills, starting with this on on adaptability.

It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.

– Charles Darwin

Best Practice is a concept that you hear of frequently but very rarely see because very few projects are actually appropriate for ‘best practice’. What most projects need is the best possible practice you can fit in to the constraints of the project you’re faced with. There are usually many constraints.

Typical constraints include a lack of time, budget, people, data, cooperation, interest, and understanding of UX.

You can spend your time battling to remove these constraints – sometimes this is appropriate but usually it is not only fruitless but also places you further behind than when you started. Usually, the best thing to do is to sit down and work out what is the best you can do within these constraints and get started.

Adaptability is about understanding and respecting that, for your client, UX is usually one of many priorities they need to balance. It’s about responding to the environment you find yourself in, building the best process, employing the best techniques you can in the best way you can within the constraints you’ve been given. It’s about doing your job entirely differently for almost every project.

Adaptability is about knowing that you’re not doing things the best possible way but, against the odds, you’re getting them done well enough. It’s about being creative. It’s about remaining aware of the corners you’re cutting and factoring them into the analysis.

Adaptability makes User Experience accessible to all projects.

How to be more adaptable:

  • DO be as familiar as you can with as many different UX techniques as possible – read, listen, talk to your peers, be active in the incredibly sharing global UX network
  • DON’T be precious, or a stickler for process. Don’t expect people to drop everything to do things your way (or the way it says in the book)
  • DO keep doing research
  • DON’T sacrifice time to do analysis and lots of design exploration (sketch!)
  • DO make sure you’re constantly focussed on the end goal – what are you trying to achieve? What is the goal of the redesign you’re doing to that page? What is the goal of that research activity? (Demonstrable victories often buy you more time/budget/participation for future projects)
  • DON’T do it alone – share your process with the team and skill them up to assist, look for ways to work together to save time
  • DO cut corners – interview less people, recruit less fussily, spend less time, prototype more roughly.
  • DON’T forget which corners you’ve cut and why – factor this into your analysis, educate your team on what would have been a more ideal approach
  • DO be creative – experiment, try different approaches and see what works, make up new ways to solve problems (and share them back with us!)

Please share your thoughts on how to be more adaptive as a UXer, and also the other soft skills you think a great UX practitioner needs.

Persona driven user stories for Agile UX

Given how long I’ve been thinking about Agile + User Experience, I can’t believe it’s taken me so long to start doing writing user stories that are centred on the personas we’ve created for the project. Nonetheless, it’s something I’ve started doing recently and I’ve found it to be really successful. I’m not the only one – Will Sansbury has written about it before and Joe Sokohl spoke about it recently at the Agile 2010 conference.

It’s as simple as it sounds – rather than writing user stories that nominate members of your project team, instead write them nominating the persona they are designed to most benefit.

For example, on the Project Verity backlog I’m working on with the team at Mark Boulton Design we have the occasional ‘as the developer, I want to…’ but the vast majority of our stories lead with ‘as Verity, I want to’, or occasionally ‘as Verity’s boss…’

This is, in theory, a teeny tiny change, but in practice I find it has two big effects.

Firstly, it keeps your personas alive and actively in use – this has always been a big challenge for UX people in agile and non-agile teams alike – here is one big opportunity where agile teams actually seem to have the edge.

Use your personas in your user stories and your personas can’t be left on a shelf to gather dust, instead they effectively become active members of your project team. If the stories don’t make sense with the personas, then either your story or the persona is at fault – the team needs to sort out which is at fault and make the appropriate adjustments. Which leads me to…

Secondly – it’s much harder to write a rubbish user story when it’s grounded in a persona. Let’s face it, there are plenty of user stories in most of our backlogs that are really management feature requests disguised as a user story. Transform your backlog so that the user stories that are supposedly there to help the users are given to a persona and suddenly it becomes much easier to interrogate feature requests against real users.

I can’t tell you how many user stories I’ve ended up throwing out because when I try to write the ‘so that I can…’ part of the user story it becomes impossible to make a compelling case because I have to make it gel with the agreed persona attributes.

I keep thinking – because I haven’t heard of people using this approach very much – that there must be some fatal flaw I’ve not thought of or come across yet… if so, perhaps you know what it is?

Making Agile & UX work together can certainly be tough, but this strikes me as one of those opportunities that Agile offers UXers to actually practice our craft all the more rigorously and visibly in our teams. I think I’ll be doing a lot more of it in the future.