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.

And, at first glance, often this appears to be the case.

It’s been my experience that the main reason most designs go unsolved is not the lack of talented designers or their interest in solving the problem. Instead, the problem is with the organisation themselves  - their inability to allow themselves to implement the right design, or even any good design.

Many times I’ve suggested a design approach only for the in house designer on the team to literally pull the design from their desk drawer or computer and to tell me how they tried to get the organisation to go this way two, three, maybe four or five years ago. They tried and tried, had no success, and filed the design away so they can get on with the work the organisation deemed acceptable or appropriate. It’s kind of depressing, and almost embarrassing when my main role is to advocate for work that was actually done years before I appeared. And sometimes it works.

Politics and egos are the main reasons that great design goes awry – either it is never presented (because presenting it is a risk to those egos and would be not wise politically), or it is presented and dismissed, or it is presented and then changed such that egos are not wounded and the politics are in tact, the design integrity is hardly a passing consideration.

Organisation processes and complexity are another common killer. As more and more, the digital products replace the previous products and functions of the organisation, this requires a transition in how things should be done that most organisations are unprepared for an unwilling to support. They’d rather keep doing things the way they always have, and craft a design that doesn’t trouble their processes or require additional resources. You know you’re designing for an organisation on the way out the back door when you come across this – disrupt yourselves or be disrupted, Peter Drucker, amongst others, has been telling us this for half a century (or more). Still, it can be surprisingly hard to do. We don’t like change and the changes required often threaten the existing egos and power structures. See above.

At first glance, the solution is strategy. Get more designers higher up the food chain and involved in the creation of strategies that would guide an organisation to make better decisions. Sounds right, but the reality is different. Most places I encounter these problems have all kinds of strategies talking about how important design and the end user is to them. They all handwave the right way, but the execution doesn’t match the strategy. This is the reality we live in – almost every organisation you come across is loudly proclaiming their interest in the customer experience and surveying you within an inch of your life to prove it. They’re talking about the importance of design and hiring expensive designers (who are then nobbled by the organisation). None of this matters if the execution, the tactics, don’t fit the strategy. And most often, it doesn’t.

I’ve tried approaching this two ways – firstly playing the politics and trying to get involved higher up, spending lots of time in meetings, or secondly: just executing – making things that actually live out the strategy that mostly lives on posters and induction manuals and giving the higher ups a better choice to make, giving them a good choice to make not expecting them to get there on their own and then brief the design team. These days I don’t get too much feedback throughout the design process (forget wireframes) – make it and then iterate. It’s been the second approach that has worked better.

‘Show, don’t tell’ is a design principle that seems to work well in design practice as well.

It saddens me how many great design solutions are hidden away in filing cabinets. It’s not enough to know the right answers, the real design challenge is in getting the organisation to adopt and implement and maintain (a whole other challenge) good design. It feels to me like we  need to focus on this more.

Although I’m no expert on public sector projects or the history of the UK Government’s web presence (I’ve done bits and pieces as I suspect many of the UX Community in UK have done), I want to take a moment to commemorate the impact of this achievement for anyone who is trying to encourage large organisations to embrace better digital work practices.

This is a big deal.

It’s important because Gov.UK arguably brings a new high standard of design, content and overall user centricity to public sector digital projects. It’s true that the UK Government has engaged its share of designers and user experience (or, probably more accurately, usability) people over the years, until now it has felt as though they were constrained to making things less bad, rather than aspiring to really create experiences that citizens wanted to engage with.

That’s because this is not really a design case study – it’s not about the government finally finding a decent designer to pretty up the interface or a usability person to write the perfect report telling them what to do. It’s about actually creating an environment where, having hired those people, they are able to do what they are good at and to actually get their work, relatively unscathed, through the complex web of stakeholder engagement and approval processes, and into ours – the citizen’s (or in my case, resident) hands.

What the Government Digital Service have given us is a brilliant case study in overhauling the way things were done before and changing them around so that they can support the creation of better user experiences online.

I thank the @GDSTeam for giving me the case study I need to present to large complex organisations who are trying to revolutionise their  user experience without changing the way that their organisations work. Now I can say,  ’Well, if the UK Government can do it, I’m sure we can’. In my experience, it’s quite  compelling.

A page like this doesn’t come into existence because one designer had a good idea. This is no vanity redesign project, these designs and this content has gone through the complex series of stakeholders and approval processes to get from ‘good idea’ to ‘actually live’.

Being able to sell something as radically different, to give stakeholders the confidence to go with something like this -that is a tremendous achievement.

Remember – this is the typical approach to public sector content:

This is not a story about interface design (although kudos to the designers who have worked so long and hard on this project). It’s a story about organisational design. The changes that the GDS Team made to how digital design is done in government is what enabled design like this to emerge.

Changes like:

• moving to a centralised, multidisciplinary team who work in close proximity and are able to focus on solving particular problems, not get hauled around from project to project to project with no time to focus.
• housing this team in a space that facilitates close teamwork between the members of these small, agile teams (including, from what I’ve seen, plenty of wall space. It matters!)
• using an iterative but agile project methodology that involves regular testing information gathering allowing the team to make decisions driven by data rather than opinions
• working openly, sharing what they are doing (including the code) and why they are doing, inviting others to participate in the process and inviting feedback often.
• having clear and inspiring leadership who continue to evangelise for the team higher up in the organisation and be the battering rams driving change throughout the organisation.
• having vocal and consistent support from the highest parts of the organisation
• spending time on creating artefacts that allow the team, as it grows, to maintain a clear shared vision about the way they are approaching challenges and defining solutions.

and many more I’m sure.

More than anything I’m thankful for the final point – the openness and the time spent creating and sharing artefacts.

From the very beginning, the team have been sharing their methodology and rationale, their project documentation and even their code. They have been helping to enable the rest of the world – not just governments – to improve their practice and make better digital products.

Some of the treasures that they’ve provided us with include:

• Design Principles
• Content Principles
• Performance Framework (measuring effectiveness)
• and lots of discussion around user research and design decisions made on their blog.

There is plenty to criticise, there always is. Nothing is perfect, and even less so in large and complex projects like this. And yes, the real challenges are ahead – can this scale and can it be maintained for the years to come now that the ‘launch’ has passed.

Most of all though, here is an amazing opportunity for all of us – public sector or otherwise, UK and around the world, to take advantage of the awesome work the team has done and the resources they’ve provided us with and to use them ourselves to no longer accept ‘the way things are done around here’ but to require and facilitate transformation.

The space you work in, the size of your team, the access to and interest from upper management, your project methodology – all of these things and many more will directly impact your ability to do good work, to deliver good experience. If you want to fix the experience, it’s critical to look at the environment that is impacting the ability of your team to deliver.

People often talk about Apple’s design process, but I think equally important is the way that Steve Jobs took the focus off the Profit &Loss statement- making that the responsibility of just one person and, apparently, running just one P&L for the world’s most valuable company. (Most companies run multiple P&Ls between departments (functional or product), and crazy decision making and politicking ensues).

Only through transforming the way your team, your organisation works will you really be able to transform the experiences that the organisation is creating for its audience. It’s not a UI problem, it’s an organisational design problem. Those things do matter.

So, get stuck into addressing the environment as well as the experience design and when you’re feeling challenged, remind yourself and your colleagues, ‘well, if the UK Government can do it… ‘

Most of us with any agency experience would have no doubt been nodding in agreement to read:

Big digital agencies especially, will kick off a project with a “discovery phase” (which may or may not actually discover anything), and quickly jump into a waterfall-style design process of UX sketching, wireframing, and client meetings/approvals. Then after many (many) rounds of visual design… and only then… will agencies start to move into the development and tech stage. Only after every pixel has been pushed and use-case documented, will something be made that is working and actually functional.

Developers and tech leaders intuitively get the problem with this. Websites (or anything digital) are not buildings, made the stand the test of time without change — they are meant to be tested and iterated, and improved continuously. But in my experience, it has never made anything of real value to a client.

Ross goes on to advocate that agencies take up the Lean Startup methodology widely in use amongst start ups and some of the more forward thinking and/or buzzword aware larger companies. I concur. This is indeed a fine and very user focussed way to approach a project.

However, Ross glosses over the reason agencies work this way (‘comfort, dogma, and the ease of billing clients’ he suggests). I think a lot of agencies want to work in a more Lean or Agile way (and some attempt to do so), but the nature of the agency/client engagement will have to change substantially in order for this way of working to become widely adopted.

A few things happen when you hire an agency.

Firstly, the client effectively outsources the work. They create a separation between themselves and the people who are doing the work.

Even the agencies who work most closely with their clients (and by this I mean properly in each others faces physically or virtually ALL the time). This creates a different dynamic than what you get in an inhouse team. There is an “us” and a “them” and they have very different realms of expertise and knowledge and often not a great way of combining these two sets of knowledge to make a great product.

The lack of integration between the company who needs the project done and the company who is doing the project creates a very different shape to a typical (effective) Agile or Lean team, and it makes it difficult to work effectively.

It also introduces another ‘customer’ to the mix – one that is not the end user customer, but one who will sign off the project and pay the bills – so, probably, a more important customer to the agency than the *real* customer that the project is being created to serve.

Complicated huh. Makes it hard to focus on what’s really important when there are actually TWO things, often in conflict, that are important. Agencies will always preference making their customer happy over making the customer’s customer happy. That’s understandably, but it doesn’t lead to good project outcomes.

Secondly, when the client outsources the work, they feel as though they’re outsourcing the risk.

They effectively pay a premium for an agency who knows what they’re doing to do that thing well. It tends not to play well for an agency to then spend the duration of the contract being actively uncertain, making hypotheses and validating them, using the client’s money to ‘learn’.

This, traditionally, is not what we pay a top class agency to do. We pay them to know stuff and to get stuff right, and to be the people we blame if it doesn’t work out well. Until clients get comfortable with this (will they ever?) it will be difficult, nigh impossible, for an agency to be properly Lean or even agile.

Thirdly, when you’re paying an agency a lot of money (and you usually do), you want to feel confident about what you’re going to get when then money is spent.

This is why clients are so desirous of spec work in the pitch process – it makes them feel more confident about what they’re going to get for their money. Getting them to let go to spec work in the pitch is hard enough, how much luck do you think the Biz Dev guys are going to have selling Lean, where all we have is a Build, Measure, Learn process that admits we don’t really know anything for sure, and the possibility of pivots along the way. (Not to mention that most biz dev guys probably don’t have the first idea what Lean is and have the wrong idea about Agile).

No one ever got fired hiring a big name agency to do waterfall, complete with functional specs and three different visual design variants for the marketing team to choose from. They probably didn’t get a good product at the end of the process either, but they got a thing that looks as though it probably took as much time as the agency said it was going to take, and looked kind of pretty, and so they don’t feel ripped off and angry. And they won’t get fired.

It takes a special kind of client to take the risk and develop the level of trust and integration required to work the way that Mr Popoff-Walker and many, many other inhabitants of agency world would like to work.

The agency model is certainly pretty broken, but both agencies and – I’d say more importantly – clients need to take responsibility for that, and take both action and a little risk to help mend it.

It depends on what *kind* of a UXer you want to be (there are many types – some are more design-y or research-ish, some some are closer to the business or the interface) and what kind of place you want to work for (there are many options there too).

The tools you use affect the work that you output, so I think you should be thoughtful about the toolkit you decide to use.

To begin with, I would say that no software will ever replace the advantages provided by a willingness and ability to sketch.

If you are not confident with sketching you will start designing into software and this is not something you want to do.

The minute you start designing into software you limit the number of options you explore, you move more quickly to high fidelity and are more likely to become attached to your own design. You sit by yourself at a desk instead of collaborating with your team.

Before you learn any software, get comfortable sketching in company.

Another important thing to understand is that most of the time, the tools we use are substitutes and shortcuts for the actual raw material for which we design.

Don’t think that because you have ninja skills in Axure, you don’t need to understand how HTML, CSS and JavaScript work or how a database is designed or how some importnt content management systems work. You don’t need to have advanced development skills but it is more important to me that you understand and have some hands on experience of the how the technology behind faceted navigation works, and what the challenges and restrictions and opportunities are, than being able to fake it in Axure. (I’m picking on Axure, I know.)

The last thing I would say before I give you the list you’re really here for,  is that it is less important which software you learn now, and more important that it doesn’t become your hammer.

(You know the saying – when all you have is a hammer, everything looks like a nail). Every day a new piece of software comes out that might be a great tool for you on the particular project that you’re working on. Get comfortable always exploring, evaluating and learning new tools. In fact, I’d go so far as saying, don’t even bother trying to be a master of one, be a jack of all software! And be prepared to change your mind.

But, tools you must have. Here’s my thoughts what you might find useful.

UX Design

1. A  ‘diagramming’ tool for basic wire framing, sitemapping, content/data modelling and flow charting. Common choices are Omnigraffle (for Mac) or Visio (for PC). There are also a swathe of online (SAAS) alternatives including Balsamiq, Mockflow, Mockingbird, Hotgloo, Pencil, Pidoco and the list goes on (there’s a nice list with summaries here)
2. A tool for making higher fidelity (prettier) wireframes/prototypes. Common choices include Fireworks, InDesign, Photoshop. Keynote (Mac) or Powerpoint (PC) are also increasingly popular with good reason I think – they’re easy to use, flexible and increasingly powerful little apps.
3. A tool for making interactive prototypes. This used to be optional, it’s not anymore. Common choices are: Fireworks, Axure, Keynote, Powerpoint, also HTML/CSS/JavaScript incl. JQuery etc using Text Editing software (eg. Coda, Expresso etc.)
4. A tool for image processing – a lot of people use Photoshop but most UXers could get away with Fireworks or even Preview (comes with Mac) for their requirements

Personally, I’ve moved away from Omnigraffle and towards Fireworks in the past 12 months or so for various reasons, but there are no perfect UX tools. I’ve seen people make a compelling case for moving back to Omnigraffle. Personally, I think Axure is more trouble than it’s worth, unless you are having to do all your detailed interaction design work in the absence of developers. (Which, if you know me, you’ll know I try very hard to avoid).

Some companies will only hire people who have skills in specific software, eg. Axure. This is idiotic as software is easy to learn, being a good UX designer is the hard part.

UX Research:

Good UX Designers will also read this section – there’s not a clear break and more and more designers should be integrating these tools into their daily practice.

If you’re doing UX Research then having some good Excel skills will come in handy for analysis. You might alway want to get handy with SPSS (although, again, this will be overkill for some). I’ve found having some good mind mapping software to be handing for research analysis as well.

Important note:  the best analysis, in my opinion, happens doing affinity sorting using post it notes on a wall – this is research’s equivalent to sketching.

You’ll also need some software to record the user research you do in person. The obvious contenders are Morae (if you’re working for a company with a decent budget) and Silverback which you can run on your Mac.

The tools I find most interesting for UX research tend to be newer web services such as:

• Online remote usability testing: Usertesting.com / Whatusersdo.com etc.
• Other online research tools such VerifyApp and the other tools from the team at Zurb, and OptimalWorkshop‘s great range of online usability testing tools.
• Online analysis tools such as Reframer
• Remote moderated research tools (mostly screensharing/online meeting tools) such as GoToMeeting or Webex
• Apps that can be used for longitudinal contextual studies such as Yammer, Twitter, Facebook, DScout
• Online recruitment tools such as Ethn.io
• Optimization and other measurement tools such as Google Optimizer

This is by no means a definitive list – there are lots more great tools out there that I’ve no doubt neglected to mention. Feel free to add your favourites in the comments below.

Just remember – it’s not the tool you use (although they will no doubt leave their imprint), it’s the way that you use it that really matters.

This is far from a comprehensive list, but is a good place to get started.

It’s also worth keeping an eye on the Harvard Business Review and Forrestor’s CX Blog.

If you’ve got any other recommendations you think people should know about, feel free to share below.

Happy reading.

How many weeks in the past year did you feel as though you were doing the right kind of work, on the right kind of project. How often do you feel as though you’re really being properly utilised, that you’re using your skills and experience in a way that is really helping companies make a difference?

Based on my own experience, my hypothesis was that the answer would be pretty depressing. And, with a few exceptions, it has been.

At a time where companies are crying out for User Experience people to come help them solve problems – and there are so many problems to solve – the people who are at the coal face generally feel as though they’re either not able to work effectively, or they are doing great work but tackling the wrong problems.

What a tragic waste of talent, of time, of money, of life.

The last few months I’ve seen a lot of movement in the UX field – people moving in house out of agencies, starting their own companies, leaving freelancing – it feels like we’re generally a little restless at the moment, and it’s a feeling I’m familiar with. I need to stop taking briefs and trying to reshape them, and instead to work with companies to give them the tools to make better decisions, to give better briefs, to allow teams to work together more productively. We need to get out of the design or UX department to solve these problems.

So I’m shifting my focus to Customer Journey Mapping.

In workshops and conference talks I’ve done recently I’ve waxed lyrical about the Customer Journey Map and how it has, without doubt, been the thing that has most transformed my practice as a User Experience practitioner over the past few years. In particular it does three things that immediately accelerate an organisation’s customer focus:

1. Makes the customer experience understandable and addressable – even for quite small companies, understanding what it is like to be your customer at all points of the customer lifecycle and across all channels can be difficult. Creating a customer journey map helps make the big picture of customer experience understandable so that even as we deep dive on specific projects, we’re maintaining a consistent and coherent experience at all times. By picking out the critical moments of truth and focusing on those touchpoints, we make significant improvements much more achievable and measurable.
2. Unites the silos, ignites customer focus – often organisations are filled with people who are passionate about customer experience but who are functionally separated from each other and have difficulty communicating effectively and aligning their efforts across the organisational silos. A customer journey map gives them a focal point and a shared language and way of communicating the insight they have and activity within their functional group, improving the organisation’s ability to maximise the efforts and expertise of its customer champions.
3. Visibly connects business value and customer value – Peter Drucker tells us that the purpose of the business is to create value for our customers and that profit is the feedback we get from doing it well, but the connection between customer and business value is often difficult to see in today’s organisations. A customer journey map provides a way to show how the critical moments of truth for customers – the touchpoints that should be most thoughtfully designed – almost always maps to places where money flows in or out of an organisation. Customer journey maps provide a way to measure CX metrics that directly impact the organisations bottom line.

I’m not giving up the usual research, design and strategic UX work I’ve done over the years, but I’d like to spend more of my time working on making Customer Journey Maps with clients and helping to focus their energies on the UX projects that will really make a difference for their organisation, and also to bring some more ‘design’ into the world of Customer Experience (CX) (yes, CX is different to UX, and yes, I totally understand how confusing that sounds).

So, if your organisation needs some customer experience mapping done, or you hear of someone who does, I’d love it if you’d send them my way. With a bit of luck and good management I can do my bit to help make sure more UXers are working on real and important UX projects in the coming years.

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.

Slides:

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.

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.