Pause and take a deep breath. UX is actively contributing to this future.
“20 years from now … You won’t necessarily know anything about the decisions that affect your rights, like whether you get a loan, a job, or if a car runs over you. Things will get decided by data-crunching computer algorithms and no human will really be able to understand why…”
User interviews are a great way of gaining insights at the start of a design cycle.
User interviews help us understand how people think, their opinions, their attitudes and the way they are.
User interviews that take place in someone’s office, at their workplace, out on a client visit, in context, let us observe other information too.
I work on an application used by the construction industry. When we visit our users on site, it’s always cold, dusty and there’s alway an issue with the wifi.
It’s a world away from my office, where it’s warm, there’s beer taps in the kitchen (seriously) and me and most of my colleagues are tapped into wireless on at least 2 or 3 different devices.
But using interviews to test an actual design is not quite the right technique. Once you’ve taken in all of the information you can, through interviews and other methods, added this information into documents, onto sticky notes, into your design artefacts, and start designing your prototype, then you need to test the way people behave, not the way they think.
These two things are very different. I’ll give you an example:
If you interviewed me about my attitudes to exercise, and how important I think it is, and how much I prioritise it, I’m going to tell you “yes, yes, very important, very prioritised”.
If you come back and show me your prototype, I’m going to say “great, looks cool, nice colours, I don’t like the green though” and you’ll make those changes and release and you’d be fairly confident I’m going to be a user of your product.
Except if you had asked me to use a prototype of your application for a week, and tracked my behaviour with the prototype and how much I used it when I was exercising, or even how much I exercise full-stop, then you’re going to find out that I am a: a little bit not-honest with myself about how much I exercise, I don’t really use tracking tools when I do exercise and I didn’t want to hurt your feelings because you’ve worked hard and done a good job with your product. I’m nowhere near a target market for your app.
So I dunno about the article about asking people’s opinions about a new design, and whether online or offline testing is going to make much of a difference (except that people will be nicer to your face).
No, not if you’re designing for enterprise. They’re not. They’re really necessary because the people using your software are so different to you that you need personas in a way that people designing consumer products may never know.
But don’t treat them like glossy objet d’arts either
I agree with the warning about treating personas as glossy, canonised artefacts. Don’t do that. New insights about our users should be surfacing all the time, if you’re doing it right.
I am going to try the 2 1/2 D approach with my team. But I really, really I liked this bit: “you still need to have done the user research — you’re not going to brainstorm a persona out of thin air”.
I have actually participated in what I think of as creative writing exercises where personas were produced that were free of all facts. No facts to encumber them at all, those personas could be whatever we wanted them to be.
Don’t do that.
At some point in the ux journey the org ‘gets’ ux and then we all argue about style guides and we get a bit less ‘prove your value’ and a bit more ‘consolidate your styles and drive this ship’.
That’s when specialists happen, I guess. We’re all 40 now, at least mentally, and we start to specialise and we get a bit more like “another jquery plugin, another development framework, another design tool to learn, kill me” and maybe a little more “I will not execute against your flimsy rationale” so at that point we specialise and we make the rationales by using the research, and then ultimately we’ve specialised ourselves into extinction and we come back as consultants. But not yet.
This is a long-winded way of saying I am transitioning into a more research-focused role and I’m excited about it, and also about never, ever participating in a meeting ever again when everyone’s feelings about one particular icon is discussed for over an hour. (This is not design. This is your younger self coming and sitting next to you and saying something like “oh really. this is what you ended up doing?” )
Today I was invited to critique a design critique. It’s a little meta.
Who critiqued my critique of the critique? Probably everyone, once they closed the security doors behind them and they had disappeared into their lovely air conditioned offices.
It was nice to be asked to this critique because:
a. It’s nice to be asked to anything, really. Especially when there’s catering.
b. It’s nice to be around established design practitioners because they know more than me and I can steal their knowledge!
The design critique framework
I’ve never been a huge fan of frameworks because they remove all creativity and spontaneity and thinking from the job. Don’t be constrained by frameworks. Knowledge workers, be free!
Except this is ridiculous and exhausting mainly because you have to be all creative and spontaneous and do thinking and it turns out frameworks are just a bunch of rules you start with, and you can change them as you go anyway if something better becomes apparent.
It’s nice to have a framework.
The other dude there critiquing the critique had a framework his team uses which was very good.
I have my own framework, honed from years of being bashed about by critiques and wondering why people were so unkind.
Here’s my design framework critique:
1. We must both be willing participants in the critique.
You can’t look over my shoulder and say “that should be moved 10 pixels to the left, you know”. That is not critique. That is being annoying.
2. Start with questions
Here’s a few examples to show what I mean:
- why are you asking for a critique?
- what do you need from this critique?
- what business problem are you solving?
- what type of users are you designing for?
- what kind of constraints are you working with?
- why did you do it that way?
This does two things.
1. It sets the scene for you as the critiquer.
2. It also displays a bit of professional courtesy, I think.You trust me enough not to assume I am a dumb arse. It’s nice not to allude to your colleague being a dumb arse! Unless you want to. Then you should. There isn’t enough people calling other people dumb arses in business settings, but you can only do this to their face, then fight it out and make up. Don’t do it behind their backs.
3. If it’s at the start of the design process go big, if it’s two weeks from final design go small and detailed, if it’s two days from final design too late just a hug will do (don’t touch me)
If you critique the basic assumptions I made in week 1 but now it’s week 12 you are most probably right and time will prove that you are the better designer and probably also a nicer person but you are serving no real purpose by critiquing that so say it quietly so I don’t hear. Unless I say something like, “It’s all gone horribly wrong. Where did I go wrong in week 1?” then go for it.
Bring that stuff up in the retrospective.
4. Don’t solve it for me
There are many ways to design something, and this is both magical and really fucking annoying. Either way, don’t give me the answer because then you’ve given me the answer but you haven’t really made go through the process to get to the answer and I’ll have to ask you again next time. You’ve caught me a fish but you haven’t taught me how to fish. Fishing is very boring, but it is necessary unless you live near a supermarket where you can just go buy a fish. Be careful with Woolies fish though. Not particularly fresh.
Bonus: Why ask for a critique anyway?
We all have biases and blind spots and every now and then it’s nice to be reminded that we have biases and blind spots. Actually, no it’s not. It’s awful to be reminded of this. Do it anyway. Your employer will thank you.
To be honest I’m not sure if this technically is a framework, or just a list of questions, but I think it’s a framework because I don’t truly know what a framework is. Just quietly, I don’t think the other people who talk about their frameworks actually know what frameworks are either. Isn’t life odd.
This is all very nice but it’s not about the design critique. What happened there.
Some very clever people sat in a room and gave good and respectful feedback to a new designer and it was nice to hear their feedback, because feedback from so many different angles brings up lots of different aspects of a design (or design process).
Can you be more specific?
Not really. No.
Here is some information design that has vital, imperative and potentially deadly outcomes if it fails.