So I recently studied for, and sat, the exam for, the CPUX-F qualification*.
It stands for Certified Professional for Usability and User Experience (that's the UX bit), if you really want to know.
It was interesting, though not novel; most of it was just formalising knowlege I and my colleagues have already acquired, willy-nilly, over the years.
Here's what the process look like.
What's wrong with this picture?
Nothing really.
Plan what you're going to do. That seems reasonable.
Understand your customers, and what they need. Yup, that's a good thing to do.
Establish that the system you create actually does what your customers need?
Seems like a good idea.
Test that all these things are, in fact, happening?
Hmm, well, sounds good.
Here's the problem
- This takes too long. It could take months to go through this cycle. We don't have that luxury any more. On the internet, people make decisions in fractions of a scond.
- Users are not involved until the end. If there's a problem, we'll discover it too late. To paraphrase Frank Lloyd-Wright, it only takes an eraser to correct a problem on the drawing board.
- The deliverables in this model are all documents. No-one reads these documents. Or, if they do, everyone who does comes away with a different understanding of them. All the effort that goes into creating them results in waste.
- There is little or no collaboration in this model. Specific roles perform specific tasks.
Here's a solution
Collaboration > communication > documentation
If a small team collaborates throughout this process, it reduces the overhead of communication and hand-offs, and also contributes to a shared understanding of the problem to be solved.
So, instead of relying on one person – the UX researcher – to research and document the context of use, send the entire team. Even, perhaps especially, if they're not all well-versed in UX disciplines.
Nothing beats watching someone struggle with and ultimately fail to successfully use something you built.
You feel it viscerally.
I know this from personal experience.
After you've observed users, talk about it as a team. Capture the main pain points. Draw on whiteboards, cluster post-its, use digital solutions like padlet or realtimeboards – whatever works for you.
The point is that this will give everyone who will work on the problem a much clearer, and shared, idea of what the problem actually is and what the solution should achieve, than sending a single person to record, document and communicate it.
It seems counterintuitive to pay an expensively-employed .NET developer to watch users for a day or two and not write a sinle line of code.
But, ultimately, it will be a hugely productive investment.
LET US RECAPITULATE A BIT: The great enemy of communication, we find, is the illusion of it. We have talked enough; but we have not listened. And by not listening we have failed to concede the immense complexity of our society–and thus the great gaps between ourselves and those with whom we seek understanding.
Fail fast
This model recognises that iteration is critical. Learn, design, build, test. Repeat.
But by compartmentalising it we create a waterfall process. We don't move on design until we've done discovery. We can't start on testing till we've done the design. We can't feedback to, and improve our understanding of, users until the end of the whole cycle.
This creates dependancies and introduces delays.
Start with what you know right now. Don't wait until you have a perfect picture. You never will, in any case.
Learn what you can about context of use in a day or two, and get started. Design something that fits the bill, build it and get it in front of users within a couple of weeks.
Now you have something to talk about.
Is this better?
If it isn't, that's OK. As long as your next shot is. As long as you're learning. As long as you're improving.
Don't wait to test
It's quite possible to test how your users will interact with something you haven't made yet.
Don't be afraid to test, for example, the questions you ask in a diagnostic with nothing more complicated than a piece of paper.
Create wireframes, as lo-fi as you like. Draw them with crayons, or chalk on a blackboard.
Yes, higher fidelity will get better quality results. But anything is better than nothing.
What can you do today that you can get in front of a user tomorrow?
Always, always, front-load value.
Perfection is not possible
This diagram has an endpoint – "Designed solution meets user requirements".
In real life, in the 21st century, this is borderline delusional.
Do you think your users expect the same things now as they did when you began this process?
In the 6 months you've been working on this, Amazon has released a couple of dozen updates, likewise Twitter, Google, Facebook, Apple, Microsoft …
New design patterns have emerged. New paradigms are established.
You're never actually done, because the definition of done constantly changes.
If this sounds familiar
… it's because it's basically this.
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
I'm a service designer in Scottish Enterprise's unsurprisingly-named service design team. I've been a content designer, editor, UX designer and giant haystacks developer on the web for (gulp) over 25 years.