Experimentation beats expertise

I found the design process utterly transformed once I decided to stop trying to be the expert and start trying to encourage a culture of experimentation.

Battles that would rage, angrily, for months – dying down when the provocateur was busy with other work but rising up as soon as they had a little time on their hands – these battles began to go away. Long frustrating and unproductive sessions of trying to explain, defend, rationalise why the design that I suggested had more merit than the many and varied suggestions (or requirements) coming from stakeholders all but disappeared. People who would usually sneer derisively at the design team became participating members of the design process.

It’s not perfect, it’s no silver bullet, but for me, it’s been a transformation.

And it’s pretty simple. To embrace experimentation you just need to stop talking about design in a Socratic way (other related but less civilised methods are also very common) and start formalising hypotheses and tests.

Stop having meetings to argue about which design approach is better  – endless meetings with stakeholders full of defensiveness and crazy arguments where the people who tend to win are those who are loudest, most persistent or highest paid. Start making decisions based on lightweight research that provides evidence (sometimes stories, sometimes numbers) to support the design that most strongly supports the agreed goals.

Goals. That’s one pre-requisite you need for this experimental approach to work. You need to have agreed what your goals are for the design. What success looks like. Without this agreement, no change to methodology will save you.

The experimental mindset is an egalitarian approach to design. It allows that anyone can suggest a design solutions and, rather than argue endlessly about whether it is better or worse than other approaches, you design a test. Find out how to find out which design works best.

Hypothesis, prototype, test.

There are loads of tools you can use to test ideas quickly – from some quick in person user research, to some A/B testing (if you’re not set up to do A/B testing, meet your friend Google Content Experiments and get onto this immediately), to an online card sort, to one of the range of tests that places like VerifyApp offer. The methods for testing are limited only by your creativity and are mostly inexpensive.

Sure, you can’t design from the ground up this way – you will still need a good designer that you trust get you to a good starting point from which you can experiment up, but once you’ve got the framework in place, don’t waste time and goodwill bickering about the details but encourage experimentation throughout the entire organisation. You’ll raise the overall ‘design IQ’ and happiness quotient of your company, your design team and, most probably, even yourself.

Cognitive Psychology UX Bootcamp Exercise: Killer Tips for writing a better blog post.

I’m writing this post while attending Cognitive Psychology UX Bootcamp. This is an exercise that we’ve been set to do and I’m working with Tara and Jerome of Ribot. This is the incredibly laymans version after half a day of the two day program so don’t take any of this too seriously. If you disagree with any of this, you can take it up with our Bootcamp trainer, Joe Leech:)

Tips we’ve learned so far:

  • Limit the line length to around 95 characters per line, allow plenty of space between lines, make sure the colour contrast is sufficient and be aware of the impact of colour choice and colour blindness
  • Aim for a reading age of around 10yrs (using the Flesch-Kincaid readability test), especially if your audience is multitasking
  • Write using upper and lower case unless you want people to read REALLY SLOWLLY  and find all your typos
  • Don’t put lots of flashing stuff in the peripheral view but also don’t rely on something animating to grab attention in my field of focus
  • Try to keep hyperlinks on the same line (not broken over two lines), and don’t put too many links off to other pages/sites if you want to keep people focused on your article (hyperlinks create a fixation point and draw attention)
  • If you want to look smart on your blog, include a photo of yourself that is closely cropped around your face. If you’d rather look less intelligent (and possibly more sexy), include a photo with more of your body in it (Note to self: get new profile photo).
  • Group similar things together, make use of established/known patterns.
  • Make sure any buttons are sufficiently large targets (ref: Fitts Law)
  • Encourage psychologists to do a lot more research about the effects of design on reading on the screen because there seems to be a lot of things we don’t really know for sure.

Why most UX is shite

I was invited to speak at the MonkiGras event this week where getting a little sweary and ranty is kind of encouraged (it goes well with the craft beer consumption that is an integral part of the conference mix). This was my contribution.


When I checked the agenda to see what I was supposed to be talking about at Monkigras, I saw that I was down to talk for 15 mins about ‘Crafting Good UX’. Where to start. I suspect James expected me to come up with something like this post that ReadWriteWeb published the day before my talk:  Five Signs of a Great User Experience If you’re interested, the five signs (aside from simply *being* Path), are:

  1. An elegant UI
  2. Being Addictive
  3. A Fast Start
  4. being Seamless, and
  5. It Changes You

I hate these kinds of lists. You look at them and you go – yes, that makes sense doesn’t it. We just need to do those things and we’ll have great UX. Simples.

If only that were true, we’d be overwhelmed by UX amazingness. Instead, here we are, using the same handful of good examples in ever conference talk or article written about User Experience this year.

It’s not that simple right. So, I changed my topic to ‘Why Most UX is Shite’. The audience was people (especially developers)  from start ups, open source and enterprise software – I figured this topic would probably resonate with them.

Now, there are plenty of ways you can make a user’s experience of your product rubbish, but in my experience, there are a handful of serial offenders. These are not things you can add to the backlog and bug fix next week, but if you know what they are you can stop wasting time fiddling around with things that, ultimately, don’t matter if you don’t get these other things right.

1. You’re not making decisions (so you force the people who use your product to make them instead)

So, this one I see ALL the time.

From a start up who doesn’t want to rule anything out of its value proposition so doesn’t really know what it is so, as a consequence, no one knows what problems it’s solving so they don’t engage. To open source software that tries to be Rails and WordPress at the same time and is consequently a usability pariah. To a page that is so full of content with no hierarchy, or a form with too many fields, meaning the customer gives up and goes somewhere that makes mores sense.

Decisions like: WHAT A COMPANY STANDS FOR, or WHAT WILL NOT BE IN THIS PRODUCT, WHAT YOU WANT PEOPLE ON THAT PAGE TO DO, or WHAT THE BEST PERMISSIONS SETTING FOR MOST PEOPLE. These decisions don’t get made, and these are reasons that people look elsewhere.

You can’t designs something if you don’t know what it is. If you don’t have constraints or priorities.

Here’s the choice – YOU make your end users choice easier and you’ll have more customers.

This starts at the top. What does your company do and not do. What does your product do and don’t do.

Get a vision already.

These decisions don’t happen because people and companies are too gutless to make them and to potentially be wrong.

From a UX perspective you are BETTER to make them and be wrong and then make a better one based on what you’ve learned than not make them at all. Preferably in testing, BEFORE you inflict it on your paying customers.

In reality tho, most people are much more interested in their own careers – not being wrong and getting a bonus – than they are in really delivering good user experience for their customers.

 2. You think your opinion counts (unless you’re the end user, it probably doesn’t)

You can probably get all pedantic on this with me, but but make sure you understand the point I’m trying to make here.

As a designer, there are two sets of people who will influence you: the end users you’re designing for, and the stakeholders who you work with every day, who you want to impress and have a good working relationship with, who will write your performance review and recommend you get a bonus, or not. Who will think you are cool in the open source community or a pain in the ass.

End users who you probably don’t get to see all that often, co workers you see every day.

Which do you think will have most influence?

I would LOVE to believe that all designers are able to put the end users needs ahead of their own personal ego, or their end of year bonus, but, let’s be realists. If you’re my boss and I know what’s going to please you, your opinion is going to be influential. Chances are strong this is not going to lead to your product having better user experience.

If you’re not an end user of the product (really), or your not regularly talking to or observing your end users to understand how to design for them, seriously consider holding your tongue rather than giving your opinion.

3. You don’t measure it (you’ve probably not even defined metrics for ‘good experience’ let alone tried to gather data for it )

You hear talk of the ROI of design every now and then but in reality, Most organisations do very little about trying to measure how well they’re doing in giving their customers or end users a good customer experience.

Most companies have no clue about the acquisition cost or lifetime value of their customers, who their most valuable customers are, what behavioural characteristics map to high value customers. This is because, historically, we do functional accounting rather than customer centric accounting.

Most companies don’t have good acquisition metrics or retention metrics or engagement metrics, let alone cohort analysis.

Sure, there are lots of challenges in measuring User Experience, making numbers of it, but it’s super important. Your Net Promoter Score is only going to get you so far.

if you REALLY want to craft good UX you need to understand what people are doing and why, how effective your current UX is and what difference an investment in improving it could have. In NUMBERS. because, really,  that’s what companies care about.

4. You don’t really care (companies who really care shape their organisations, their accounting systems, their culture around their customers)

This brings us nicely to the nub of the issue. Most companies don’t really care. They pay lip service to UX because everyone has started saying that UX is important and because apps like Path look cool don’t they? We need to look more like that.

Why can no other company do design like Apple despite lots of companies doing their utmost to rip off the iPhone?

Because the iPhone is a symptom of a company that massively cares about the user experience that their customers have with their products.  Apple structures the operations of its entire organisation to support the creation of these kinds of products.

This is not new, we know this, right?  but how many big corps do you see trying to copy Apple’s organisational structure, or the way they do communications and accountability, or where design sits in the organisation?

Pretty much none. Because there are too many people in cushy management jobs who have no clue how to operate in this new kind of environment and are too pleased with their current set up to make such big changes. And because most companies are too scared of what shareholders would say about making such radical changes that will cost money in the short term to make money in the long term (I give you Apples most recent balance sheet in response to that argument).

At the end of the day, most managers care more about this stuff than they do about UX. End of.

The UI is a symptom of organisational culture – you need to get beneath the skin to craft really, sustainably good UX

There are no Five Simple Steps to making your UX fabulous, there is no simple fix. All of these things are hard and most of them start much higher up in the organisation than the average UX designer ever gets to.

Good UX is cultural. If you want to hire a freelancer to ‘do UX’ , it’s like putting a plaster on gangrenous leg.

Design good organisations so we can design good User Experience

If you want better UX, stop looking at your design team and whichever new sexy UI you’ve seen this week, take a long hard look at your organisation and whether it caring about UX is part of its cultural make up and what evidence there is, beneath the interface, of this being true.

Go design some good organisations so that we User Experience people can make you some properly good UX.

What is a UX Developer and are they really a thing?

I posted a note on Twitter earlier today about a friend of mine who calls himself (at my suggestion, having worked with him and knowing his skill set and interest) a UX Developer. Several people suggested in response that a UX Developer was not really a thing and that the term was either pigeonholing, unnecessary, redundant or ‘so 1996’.

With respect, I disagree. UX Developers are definitely a thing, and more than that, they’ve become an essential part of my project team mix, especially when I’m working on the UX of an application style system (which is more and more the case).

I’ve been fortunate enough to work with front end developers who have plenty of sensitivity to creating good user experience for as long as I can remember, it makes perfect sense that most front end developers are more interested in UX than those whose work doesn’t touch the UI. These are great front end developers, but, by my definition, they are not UX Developers.

A UX Developer is all of that – a front end developer with a sensitivity and talent for crafting a UI that is going to be better to use – but in addition to that they have a declared interest in understanding more about the User Experience work that goes ahead of the UI design. I doubt many of them would ever be happy doing pure user research, but they’re probably keen as mustard to run some of their own usability tests, guerilla or otherwise. They’d probably go nuts having to do some of the workshops and stakeholder communications that forms a key part of the garden variety UXer’s role, but they want to understand the strategy and customer insight that is driving the bigger picture product decisions.

There are different layers of user experience – these layers sit on a continuum between the pixel and the person.

UXers like me sit further toward the ‘person’ end of the scale, focussed on understanding end users, stakeholders, and what is going to work well for them as a wholistic experience. UX Developers are situated much closer to the pixel. If you’ve met a UX Developer, you will not be surprised to hear them tell stories of videoing a transition in an application so that they could slow it down enough to understand how it was working so they can recreate it. It’s what they do.

UXers like me (and I’m all about Prototyping in Code, I’m just not particularly good or fast at it) work very well with UX Developers. Trying to get the finest details of the UI right is not something that someone with my rudimentary development skills should be doing, and frankly, it’s not where my real strength lies. With a UX Developer on my team, I can involve them in the strategic / research aspects of the project as a second pair of hands, then work with them to create prototypes quickly, moving from sketches direct to code – and really nice feeling code – quickly. Eliminating the need for putting myself or my stakeholders through the wireframing process and being able to iterate on the ‘how it works’ part of the design from almost the very beginning.

The UX Developer, having been involved in the UX process from the beginning of the project, understands the rationale behind the product and design approach and is able to make good, consistent, UX decisions without needing every piece of UI defined. In fact, in my experience, they’ve probably made better design decisions than I would have made… well, sometimes.

Is UX Developer a synonym for interaction designer? Perhaps, except that it makes strong front end development a critical part of the skillset, which I think creates a completely different team dynamic and quality of interaction than an interaction designer who uses prototyping tools like, say, Axure (and there are still plenty of those). If you can’t produce high quality, production quality code, then I don’t think you’re a UX Developer. (Although, you may well be a perfectly competent Interaction Designer ).

How do you work with a UX Developer?

  • get them involved in the strategic parts of the UX process – defining the product, the audience, the research, all the fun stuff. Let them increase their UX skillset and make sure they understand WHY things are happening the way they are in the project.
  • sketch together and get prototyping in code as quickly as possible. This is not a senior/junior relationship, this is the dovetailing of compatible skills to get to a better UI, faster.
  • share ownership of the UX, don’t feel like you have to make all the design decisions, let them own the finer details of the UI and you focus on the bigger things (that are actually pretty hard to stick to when you do get to obsessing about the details on the interface)
  • allow yourselves to push and pull focus from the strategic ‘person’ level to the pixel level – it is difficult for one person to maintain focus on both ends of the spectrum at the same time – a team like this helps enable this rapid shifting of perspective more effectively.

A UX Developer is not a silver bullet. You can’t work this way on all kinds of projects for all kinds of people, and it can be hard to find a good UX Developer to work with. I’m a freelancer, so I used to travel solo from project to project, but since I’ve started working with UX Developers, I now like to BYO team (where possible) and an essential member of my UX posse is a great UX Developer.

Works for me, your mileage may vary.