I’ve just been at this year’s UX Hong Kong conference, where Jesse James Garrett‘s keynote on Designing the Designer resonated with much of the thinking I’ve been doing in recent years, particularly around UX skills. It reminded me that I never did get round to posting the notes from my talk at UX Malaysia some years ago – oops… So here they are.

Disclaimer for anyone who was there… ;-) What I actually said may have been a little different – I don’t read my notes verbatim, but I do like to write out my thoughts in quite a lot of detail before condensing them into a presentation. These are those thoughts.

I started out calling this talk Real World UX, because I was originally intending to focus on the challenges of implementing UX processes – particularly Lean UX – in the real world. But then Izwan promoted it as Rockstar UX and actually as it turned out, as I got into preparing my notes, it ended up being more about that anyway – so hat-tip to Izwan for his foresight! ;-)

I want to talk a little bit about what User Experience actually is – as I see it – and in particular about Lean UX (which seems to be increasingly becoming synonymous with UX – not sure that will last though), and I will talk a little about some of the challenges of implementing Lean UX processes in the real world of agencies and client projects.

But mainly – at the risk of being controversial – I want to talk about why we still need rockstar UX designers. And why we should all aim to be rockstars – and the skills we need to do so.

What I hope I can do is give you some food for thought, and hopefully some tips that may help you to become better UX practitioners or, if you’re responsible for hiring or managing a team, the kinds of skills you might want to look for or nurture.

The idea of a rockstar designer seems to have come in for a lot of criticism lately. I think that’s partly due to the current trend for all things lean.

So let me start by saying I’m a fan of Lean UX. I’m probably going to sound really negative about it now, but that’s not because I don’t like it.

If anything it’s probably just because of a couple of frustrations – the way it has suddenly become a massive trend, with everyone jumping on the bandwagon even when it might not be the most appropriate approach, and seeing it so often implemented badly or bastardised, or just done as a token gesture, lip-service to make an agency sound on-trend. And also perhaps because, for all the fuss being made over it, I’m not sure it’s actually anything particularly new?

Lean is a good methodology. And in many ways it’s absolutely the right way to go.

The basic principles – engage your users (and other stakeholders) as early and as often as possible; test your ideas, prototype, validate, iterate as quickly as you can; prioritise collaborative design, cross-functional teams and shared understanding over linear process, lengthy documentation and handovers between siloed specialists, results rather than deliverables – that’s all absolutely correct.

But there’s a couple of points I want to make.

One is that I’m not sure user experience is really anything new. It’s really just product design, but in the digital space. And much of what we’re talking about here is just good design practice.

Understanding the problem space, going out and talking to real users, understanding their needs and expectations – that’s what good designers have always done.

Prototyping, testing – again, nothing new. You don’t design and build a car or an aircraft without making some models first, doing some wind-tunnel tests, getting reactions from potential customers, going back and tweaking, refining, and repeating the process.

It’s all just product design. Or rather, it’s GOOD product design.

Of course, the fact that we work in the digital space makes it that much easier and quicker to prototype, test and iterate – which I think is really the main difference, the main change over physical design, or over linear design-then-build production processes, but I would argue that the principles are the same.

Perhaps what Lean UX brings to the table is a way to focus our minds right down to specific, measurable results – hypotheses that we can test, a way to really focus on just those things that will add value to the product, a way to reduce time wasted on unnecessary features, on frivolity if you like. Which is good, although I do think there are issues with that, which I’ll come on to later.

But ultimately, as I see it, it’s all just product design. If giving it a new name, like user experience, helps us persuade decision-makers to adopt the right approach, to let us do the job properly, then great, all the better. If it helps new entrants to our profession understand what it’s all about, then brilliant. And if it gives us a handle, a label, that gives us a common frame of reference, then that’s fine. And whatever we call it, the discipline it represents, the skills and expertise it embodies are absolutely crucial to our industry – they’re at the heart of what we do. But let’s not kid ourselves we’ve invented anything new – it’s just product design.

And I do wonder sometimes, if we just called it digital product design, might we have an easier time getting it accepted?

I think a second point is that Lean UX is just a tool and as such it’s not the only option, nor is it necessarily always appropriate to use it. And even when it is appropriate, sadly it’s not always possible to use it to the extent that we might like.

Working collaboratively in cross-functional teams, reducing documentation and building shared understanding is a great philosophy, and one we should absolutely strive to follow. But we live in the real world, and we have to be pragmatic.

We face a number of problems. Firstly, and perhaps the easiest one to resolve, is that there will almost always still be a need for documentation. I have to say, if I never have to write another functional specification in my life, the only tears I’ll be crying will be tears of joy. But I rather suspect I’ll be writing a fair few more of them before my career is over.

Agencies love documentation, and deliverables in general. Aside from the contractual aspect – proving that you’ve done what you said you would – there’s the simple matter of money. Deliverables can be followed by an invoice.

And clients like documentation – and deliverables – because it’s tangible, it shows progress, it helps them see what they’re paying for.

And developers like it because – assuming it’s done properly – it gives them a clear brief to work against.

(And yes, maybe we should be trying to change these attitudes, but it’s not going to happen overnight – we have to be pragmatic).

The important thing is to make sure the spec follows on from the design, not the other way around.

But for many – perhaps even most? – projects, there will always still be a need for documentation.

In the same way that Agile development all too often seems to get used as an excuse for skipping design altogether – often resulting in a rag-tag collection of widgets, functions, bits and pieces, with no clear overall vision or coherency – so too it seems to me that Lean UX is all too easily used as an excuse not to document the project, the design decisions, the product specification. That’s not the fault of either Agile or Lean, but rather the fault of those who implement them badly – which is perhaps far too easy to do.

And yes, designers and developers should be working collaboratively together, and yes in theory development shouldn’t come after design, and that’s great while you’re prototyping, but that’s not how it works in the real world – when you’re building an enterprise web application, or a global intranet or a multi-lingual marcomms site, there’s always going to be a process of design, develop, deploy. But what we can – and should – do is bring the developers into the design process right from the start.

Which brings me on to the next problem. Resources.

Yes we want cross-functional teams (or better still, cross-functional individuals – but they’re rare and our education systems aren’t well suited to developing them, which is a shame – and a whole other talk!). And we want them on the project from the beginning right through to the end. And maybe that works if you’re a small start-up developing your own product, or a small studio where everyone’s working on the same project.

But in agency-land, that’s not how it works.

Agencies operate in the other sense of lean – they aim to maximise resource utilisation. They don’t have people sitting around twiddling their thumbs. If staff aren’t doing billable hours, the agency’s efficiency is reduced. They never have spare people. Far more likely they’ll be scrabbling around trying to pull in freelancers at the last minute. You’ll have project managers fighting over resources like a pack of tigers squabbling over a fresh kill.

And even if you do manage to get someone resourced 100% on the team for however many weeks, they’ll almost certainly get pulled off it at short notice because of some emergency on another project, or because an urgent pitch has come in.

And when a project kicks off and the team gets put together, you’ll typically have the project managers requesting the ROLES they need and someone else, someone in HR or a traffic manager or similar, will decide which actual PEOPLE get assigned to those roles. Which is fine on paper, but doesn’t account for team dynamics.

Great teams don’t just happen overnight. It takes time to get the right mix of personalities, the right soft skills, the right inter-personal skills.

It takes time for team members to understand each other, to recognise each other’s experience, expertise, ways of working, foibles. To play to each others’ strengths and make up for each others’ weaknesses. To be in the best position possible to develop that shared understanding that we seek. You don’t get that by throwing together an ad-hoc team at the last minute.

On top of that, their individual skill sets really do make a difference. The right mix of skills, experience and expertise will allow the team to get to a viable solution much more quickly. You don’t want to put someone on the team just because they represent a given function. You want someone who knows their stuff in the context of the specific project.

Let’s take an analogy. Imagine you’re building a skyscraper. You’ll want an architect, structural engineer, maybe an aerodynamics engineer (I don’t know, I’m not an expert on buildings, but I imagine the taller you go, the more wind and aerodynamics become important), maybe a wayfinding designer.

And preferably people who have previously worked on tall buildings. They’ll already have a certain amount of shared understanding, common frames of reference, that will enable them to intuitively understand a certain amount of the problem space, to recognise and rule out unviable solutions without the need for discussion, to more quickly get to potential solutions. To use their time efficiently, in other words.

But you put a different team on the job – let’s say the same architect but a different structural engineer, and an interior designer instead of a wayfinding designer, plus let’s add in a potential tenant or two… You’ll spend a lot more time discussing unworkable solutions, explaining technical issues to laypeople, exploring ideas that an expert would intuitively know aren’t going to fly.

On the other hand you’ll get invaluable insight and you’ll almost certainly learn a lot from the discussions. But my point is we’re really talking about two separate processes – design research, which is when you engage your users, your stakeholders, your non-experts, and quite a few of your other-function specialists, and design itself, which is where you need your expert designers.

Which brings me on to rockstars.

So what do I mean by a rockstar?

Well, I’m not talking about just the ones who are famous! And I don’t mean the lone gun, the ‘artist’ who works in isolation, who gets upset when anyone critiques their work or disagrees with them. I’m not sure good design has ever been about that.

What I mean is someone who can get the job done, within whatever constraints they find themselves up against. Someone who can sneak in the best bits of the lean methodology even in the most adverse circumstances!

Someone who’s pragmatic, but experienced enough to make the right call even in the absence of proper insight. Someone who has the experience, expertise, intuition to make the best guess in the absence of proof.

Someone who’s self-motivated and not afraid to take responsibility for the design, or ownership of the vision.

Someone who’s flexible and willing to listen, who has the consulting and facilitation skills to elicit insight from users and stakeholders, and to promote consensus amongst team members.

But someone who also has leadership skills and is willing to make a decision, to make the call, even if it’s a tough one, or unpopular with the team.

Someone who has the determination to see the product vision through to completion, to stay the course and not cut corners or make compromises for the sake of making the development easier.

Someone who wants to create the best possible product, not for their own glory, but to best serve their users.

Whatever methodology you use, creating a great product still needs design leadership.

Lean is not an excuse to absolve ourselves of the responsibility for owning the design, championing the vision, being decisive.

I fear it’s too easy to use it as a cover for not actually being very good at design. Or as an excuse for not having design leaders.

Yes, design should be collaborative, it should be consultative, it should be informed by insight, it should be tested at every opportunity. And we should be willing to change our ideas, adapt our designs, iterate our product as new insight becomes available or as constraints or opportunities crop up, or as circumstances change.

But design is not a democracy.

The best design is not done by committee. We’re not here to design a camel when a horse is what was wanted.

A phrase I heard recently, which I love, is “Design like you’re right, test like you’re wrong”. Take ownership, fight your corner, champion the vision, but don’t be dogmatic – be willing to listen, to be flexible.

And users are not designers. They don’t know what they don’t know. Or what they could have. Or sometimes even what they want. What they tell us needs to be interpreted, filtered through the lens of design expertise.

My fear is that Lean is all-too-easily used as a way to devolve responsibility down to the users – “the best way to get the best product is to get the users to design it for themselves”. No! That’s risks just being a race to the bottom, to the lowest common denominator.

Sometimes, you have to JFDI – just do it.

And that’s where rockstars come in.

Rockstars are designers who have the experience, expertise and pragmatism to give you the best chance of getting as close as possible to a great product, even where the ideal methodology isn’t possible, or where there hasn’t been the time – or political will – to do enough user research, or enough testing. Or where the whole thing’s last-minute and just needs to be ‘good enough’.

Rockstars are designers who can rapidly get up to speed with the project and its requirements, who can slot into a team they’ve never worked with before and instinctively know where they fit in, and still do great work together.

They’re people who can get you 80% there in 20% of the time – the 80/20 rule.

Which is about far more than just being a ‘creative’ – much much more…

It’s about understanding not just design but also business, content, technology, marketing, people (not just users), processes…

It’s about being a great consultant, listener, facilitator, presenter, salesperson…

(Oh and a good designer too…)

It’s about being able to think both creatively and logically, being able to empathise with both users and stakeholders.

It’s about being able to conduct interviews, run workshops, analyse data and gather insights.

It’s about being able to make decisions, work fast. Communicate, engage, persuade…

(Oh and design stuff…)

So what does it take to become one of those?

What skills do you need to be a rockstar designer?

Of course, a lot of it is down to experience, which comes with time. And unfortunately our education systems are, I think, not particularly well suited to creating the kind of cross-disciplinary people that make great UX practitioners – I’d love to see changes made right back at school but that’s a whole other discussion. But there are skills that can be learned, honed, improved, and things you can do now to get on the right track.

Study some philosophy. 

It promotes clear, logical thinking (look up truth tables). It helps you appreciate different perspectives. It teaches you how to make a case and how to recognise a flawed argument.

Study some psychology.

It helps you understand users, and user behaviour. It helps you plan navigation (look up mental models). It helps you think about other people.

Learn about your company

Take every opportunity to get involved in wider business activities wherever possible.

Understand the company structure, its ways of working, its methodologies and approaches beyond just your own discipline.

Get to know the project plan and be aware of the budget. Try to get a feel for what’s possible – or what’s being offered – within the budget. Try to be aware of the constraints, issues, risks and scope of the overall project, not just your part of it.

Talk to other disciplines, get to know what they do, their processes, issues, concerns.

Try to find out about the client and their business, and the history of their account. Get to know the politics, the nuances, the things that do and don’t work for a given client. Know when to pick your battles – when to fight your corner and when to accept the client’s request, no matter how badly thought out it may seem.

But above all – get out of the silo. Get away from your desk, interact with other people.

Learn to be confident

Take every opportunity to speak out, to present your work to colleagues and clients.

Take part in debates, play in a band, act, sing, busk…

Give talks, lead discussions, facilitate meetings…

Ask questions at lectures… Ask others about their work.

And if you’re meeting more senior people – relax, be yourself.

On which subject…

Sell your ideas

Practice your presentation skills.

Explain your rationale, clearly and concisely.

Justify your design decisions.

There’s rarely one single right answer; sometimes it’s not even the best idea that gets accepted; often it will be the idea that was best explained and justified.

Be prepared for subjective criticism. Our job is to try to be objective, to empathise with our users, to design for them, not for ourselves. But clients – and indeed anyone looking at someone else’s work – are often far more subjective. It’s far easier to criticise than to be constructive, far easier to give their own personal opinions than put themselves in the mind of the user. So be prepared for that.

And be prepared for someone overruling all your long and carefully thought out design rationale purely because they don’t personally like it.

A good strategy is to de-personalise the design. Use phrases like “The thinking is…” rather than “My idea was…”.

Not only does this help you to let go, to not take offence when someone criticises the design, but it also helps them offer honest feedback, because they’re commenting on the design rather than your work.

Learn to interview

Prepare your questions, but be prepared to diverge from the script – interviews are conversations.

Think on your feet, improvise, adapt. Find connections to link topics, to get back on track.

Think about your body language – and theirs.

Actually that’s one of the nagging concerns I have about user personas – all too often these seem to get handed down from someone else, either because the client’s marketing department already did some research and developed them, or because the task was assigned to the agency’s planning department before UX got a look in. Persona documents are useful, but I worry that on their own they don’t give the full picture. So much can be gleaned from body language, non verbal communication, during the interviews, focus groups, user research. I would argue it’s vital for the designer to be present throughout that process, if not leading it.

Learn some code

Ok, this one’s probably controversial, but yes, designers should be able to code. You can’t design if you don’t understand your materials.

You need to know how your ideas will be built, what it will take to build them. And you need to be able to communicate with developers.

And sure, with any luck you’ll be sat right next to a developer and working together to prototype out ideas for testing. But even then, it helps to have at least a basic understanding of what they are doing, what challenges or problems they might face, how they think. And besides, sooner or later, perhaps even more often than not, you won’t have a developer working with you – you’ll be a team of one, left to get on with it for yourself.

Plus sometime or other, and probably increasingly often, you’re going to be needing to create clickable prototypes rather than just static wireframes. Sure, there’s software that can do that for you, or help you do it, but I would still argue there’s no substitute for knowing how the code works.

You don’t have to be an expert coder, not to the level of a professional developer, but you should know your way around some HTML, basic CSS, maybe a bit of Javascript or PHP.

Besides, coding promotes logical thinking and problem-solving skills, which are a key part of the user experience discipline.

Understand content

Content is ultimately at the heart of most digital products, so you need to understand it to design for it.

Be aware of things like: metadata, taxonomies, controlled vocabularies, classification systems. Ideally get some experience at developing schemas.

Be aware of publishing workflows, policies and governance – why they’re important, when and how they get used. The back-end administration system and the business logic that underpins it are as much a part of user experience design as the front-end interfaces.

Learn about information architecture – especially the principles of site maps and navigation.

Study some library science.

Write copy

I firmly believe it’s part of our job to write real copy as part of our designs – at very least for interface messaging, instructional copy, errors and confirmations etc. Even if a copywriter is available to edit it for tone of voice, house style etc, it’s still our job to specify what the interface needs to say.

‘Lorem ipsum…’ is fine for showing page content, but even then there are times when it’s helpful to show draft actual, indicative content, to convey intended length, expected scope or coverage of the subject matter, style, tone etc.

Copy is as much a part of user experience as design.

And do write clearly and accurately when you’re annotating wireframes or other artefacts. Sure, one could argue that communicating the design is more important than writing well, but I would disagree – it’s our job to communicate, to remove ambiguity, to be clear about what we mean, to minimise the scope for misunderstanding.

And besides, poor grammar, too many spelling mistakes, more than just the occasional typo – that’s just sloppy. It implies that you’ve rushed, not taken enough care, not given it your full attention.

Talking of which…

Pay attention to detail

Proofread your copy, align your objects, check for consistent style.

Yes, it does matter!

And it need not be at odds with working fast. Creating wireframes, site maps, diagrams etc. doesn’t take long if you know your software. It’s the thinking that takes the time.

Learn to let go

Don’t treat it as your design (remember “The thinking is…”).

Accept that it won’t be right first time (or even ever).

Be a perfectionist but don’t expect it to be perfect. Know when good enough is good enough.

Design like you’re right, test like you’re wrong.

But do take ownership

Listen to what people say – but don’t be a slave to it.

Welcome their suggestions – but assess their merits.

Consider their feedback – but also the context in which it is given.

Draw on as much insight as you can – user testing, interviews, research… they’re all good inputs, but don’t take them as truths. Don’t rely on them, interpret them. And use analytics – but remember they only tell you what happened, not what didn’t happen, or what should have happened. They only tell you about the users who visited, not the ones who didn’t.

Use your judgement, your experience, your expertise, your intuition. Listen, assess, evaluate – but ultimately make the decision.

And I’m going to say this again because it’s important:

Design is not a democracy

Avoid group-think – don’t design by consensus, don’t design that camel.

Ultimately it’s your call – it’s your job as a designer to make the decision.

So to wrap up and summarise…

I think there are really four main points I want to make:

Firstly, User Experience is basically product design in the digital space. I don’t really see a huge difference between good UX practice and good design practice in general. I wonder whether the fact that we’re re-inventing a lot of it, re-discovering it for ourselves, creating new buzzwords and labels for it, has a lot to do not so much with our industry being young, but with it having such low barriers to entry that pretty much anyone can call themselves a UX practitioner, or a web designer, or whatever, without necessarily having the expertise required. Maybe we should all get out there and study a bit more – a lot more – design theory in general?

Secondly, Lean UX is a good methodology but often hard to implement in the real world of agencies and client projects – and all too easy to use as an excuse for ducking our responsibilities as designers, or for not actually being very good at design in the first place. It’s good, but it’s not always right and not always possible and ultimately it’s just one approach out of many. I suppose in some ways it’s rather like the PRINCE2 project management methodology – which tends to work best when you select bits that are most suitable for your project, but don’t try to implement all of it at once. So given the difficulties of implementing Lean in certain environments, I think we need to use what we can but not stress over what we can’t. Don’t be a slave to the methodology.

Thirdly, whichever methodology we use, I feel strongly that there’s still a need for ‘rockstar’ designers. What I l mean by a ‘rockstar’ is really just a truly good designer, who has the experience to select and implement the most appropriate methodology, to work around project constraints when needed, and basically to get the job done.

And finally being a great designer – a rockstar – takes a combination of experience and design expertise, but also a whole raft of skills that are, in themselves, nothing to do with design itself, but which are essential for doing good design that truly serves its users. And we need a combination of creative and technical thinking skills – and ideally we’d be artists and scientists, builders as well as designers – engineers, in the traditional sense.

So what I’m ultimately saying is we need to be really good all-rounders. Or, since we’re using the rockstar analogy, you might say multi-instrumentalists, writer-performer-producers…

Oh, and one final thought…

Forget the job title – UX Designer, Interaction Designer, UX Architect, Product Manager, Consultant, Design Lead, Creative Director…

It’s all about the role – what you do, not what you call it.