Different hats


It’s not just the design doing design…

Today I overheard two conversations going on between groups of our developers, preparing for new projects. I was suddenly struck by how different these sounded to the conversations I used to hear a year ago.

The guys were talking less about features and backlogs, and more about who they’re building the product for, what they need, and how we can involve them. There were conversations going on around me about UX, and I had nothing to do with it. Fantastic!

I should elaborate. A year ago, we were making our first, occasionally fumbling attempts to integrate UX with the agile and scrum processes our developers already use daily. Read any published book on this kind of endeavour – I’ve read my fair share, now – and you’ll quickly realise it’s an awkward marriage. There is little practical advice out there* Despite this, when we stopped worrying about process and just got on with it – developers, designer, product owners and users all mucking in together – it usually worked. Putting these people, with their slightly different mind-sets, in a room for an honest discussion always seemed to help us progress. With several noticeably improved products in the works and some enthused, reinvigorated users, we’re starting to reap the rewards.

Whereas some teams used to struggle with the true meaning of poorly written user stories and vague requests like “make the product intuitive to use,” we are now recognising where we have gaps in our knowledge and planning user research to fill those gaps. We’ve found out who our users are and have been involving them early in product discovery and testing. It’s started to become a common sight to have our turbine engineers or climate analysts pop over for a coffee and a quick gander at the latest build. This encourages a continual appraisal of what we’re building and why and also encourages us to be honest – if we aren’t sure what’s needed, or if we need to ask questions of our users, it’s absolutely ok to admit that, and now we all know what to do about it.

All of our teams are now trying out story maps as a way of planning the product and setting sprint tasks. To use the story map, you must be able to put yourself in your user’s shoes, and imagine how the product (which by the way, probably doesn’t exist yet) feels from their perspective. For some of us, this empathic mind-set is a marked change from what we’re used to, but mastering it adds a very useful skill to the developer’s toolset and lets them join in those design conversations.

During the project, developers are interested in testing and collaborating with users to get the details they need. How can we determine if our new UI is intuitive? Give it to someone new and watch how they get on, of course. I’ve delivered training in research techniques to several of the team, and am proud to say a few of our coders have begun conducting their own interviews and quick usability tests with a little coaching from me. Whilst before they might have had to wait for advice from the product owner, next time the guys are wondering if the UI is intuitive they have the skills to quickly find out for themselves.

Showing our users software still in development yields lots of useful info we can use to improve it. We have to let go of our pride in our creation and let it be – sometimes brutally – appraised and criticised by the real world. Sometimes this affirms our ideas, sometimes it teaches us some harsh lessons, but every time our software comes back stronger for it. Crucially, it gives us hard evidence we can use to make decisions on the fuzzy, subjective stuff developers are not always so confident with, like usability, language, and visuals. As I work in an environment full of technical, right-brained people, this rationalisation tends to frame things in a way everyone is comfortable with. It also makes our software more likely to be adopted because our users feel they’re shaping it with us, not waiting for something to simply be delivered and hoping it’s right.

The lesson for me recently has been that anyone in the team can wear several hats as the situation demands. Developers can and should conduct research and do a little design on occasion, just as I might help the product owner with competitor analysis and strategy. Ultimately we’re a team working together to deliver something great, and the more versatile each of us can be, and the more we understand of one another’s expertise, the better. It has helped us a great deal to blur the boundaries between disciplines and give one another permission to have a go, without worrying about the extent of our remit.

Particularly when you’re a UX team of one, you are limited in what impact you can have if you try to do every bit of research, concept design, usability testing and graphic design yourself. There are only 24 hours in the day and besides your hair will all turn grey (I’ve a few at the temples, and that’s quite enough for now).

Real impact from UX has come about through a gradual culture change in the software department as a whole, rather than through the efforts of just the designer. It’s contagious. This is very much an ongoing evolution, but I can confidently say that our team is developing a shared understanding that our software begins and ends with people, our users. Most of us now recognise the difference UX activities make to the product and feel empowered to try them for ourselves.

Round here, we can all wear different hats.

* The best I’ve found is ‘The User Experience Team of One‘ by Leah Buley. Worth a read.

Matt Corrall