Stamping Out User Experience

by on December 4, 2010

I think I’ve been a user experience designer for about 10 years now. I say “I think”, because I regularly read descriptions of methods of working and relationships between people in multi-disciplined web and software development teams that I don’t recognise. It is of course with great interest that I like to find out about these, but I often get the impression that either the proponents of these methods must be working in situations fundamentally different to my own, or they are just imagining ways of working without actually trying them out.

It’s possible that my career has not been representative, but I think it somewhat unlikely. I’ve worked in small teams (less than 5) as the only UI designer, in both waterfall, scrum and other situations. I’ve worked as one of several user experience architects on large projects for multi-national brands. I’ve been in agencies, and in-house, and I’ve worked a little bit on my own. Even with that comparative variety, I think I’m not being too dramatic when I say that in all that time, I’ve not repeated the same “design method” twice.

Quite why this is I don’t really know. Perhaps it’s because with only very few exceptions, I’ve been pretty dissatisfied with every project I’ve ever been involved with. Most things I’ve produced have either suffered from being compromises to some or other factor out of my control, or have been failures for other reasons probably down to my own doing.

Be that as it may, the latest idea about UX design is born of Agile methods: that responsibility for UX, like software quality, should lie with the team as a whole, rather than any one individual. My natural reaction to this view is to think that those who espouse it do not know what UX design actually involves, unless we’re going to discover the UX equivalent of test-driven programming.

However, UX being my only marketable skill, I would say that, wouldn’t I? So what follows is an attempt to explain why it’s misguided to think that when you are working on the construction of a piece of software, leaving user experience to “the team” just isn’t a good idea.

Before I do though, I need to define “UX design” for the purposes of this argument. I’ll do it by exception. It is anything that’s not the execution of the design ideas. This means that visual (AKA “graphic”) design is execution. UI engineering (AKA markup and styling) is execution, as is “back-end” application development, marketing and PR. The UX designer is responsible for coming up with the fundamentals that are then executed; the first sketches on the blank canvass. These are of course changed, and hopefully improved upon, by the rest of the team, but it’s up to the UX designer to ensure that.

I also want to point out (because so few people who pontificate on UX seem to) that I myself have designed some web sites. hotels.com, where I am currently the lead UX designer, is the current example Before that I was the sole UX designer for singstargame.com some three years ago. Feel free to have a look and draw any required conclusions from them. Most sites previous to that are either no longer up, have been re-designed, or a too old to be good examples.

So here’s what I think. The main issue with devolving responsibility for UX to people who are also responsible for things like mark-up and styling, marketing, visual design, SEO or Java, is that it fails to account for the fact that UX design isn’t just about considering what’s best for “the user”. Indeed, that aspect of things can be devolved quite easily because everyone is entitled to have an opinion about it, for obvious reasons.

You don’t have to be a lawyer to know that using a photo from The Times Online without asking is a bad thing, or that sharing your client’s sales figures with anyone would be a breach of contract. Taking analogy further still, you might want to use a code snippet that you wrote for a previous client in a new project for a new client. Is that a breach of contract? Ask the lawyer. How about the work of drafting a contract for a merger of your company with another one? Even supposing you could attempt that on your own, would you have the time to be able to discharge your other responsibilities as well? So it is with UX design.

Without giving a laborious explanation of the work of a UX designer, let me say that the fundamental business requirement of UX design is to reduce business risk by designing something that is not going to tank. There’s a lot of perspiration and detailed thinking to be done to ensure that (communication of concepts to those that are paying for the work, user research, delicate interaction design, the balancing of pros and cons…). If anyone has the hours in the day to do this as well as, say, business development, project management or CSS, then the aforementioned fundamental purpose is being actively betrayed.

There is also another view on this as well, which seems to address a perceived weakness in UX design itself. Consider this recent quotation, from Anders Ramsay:

“The visual designer knows very little about coding and the developer knows very little about visual design. In an Agile model, that is ok, because if they, for example, are co-located or maybe even pairing cross-functionally, i.e. sitting side by side and working on creating a design solution to the same design problem at the same time, then they can cross-pollinate their knowledge. The developer can look at the problem from the coding dimension. The visual designer can look at the problem from the visual design dimension. By virtue of their conversation, they can have a rapid exchange of ideas and develop a design that is cross-dimensional, i.e. a whole design.”

Ramsay doesn’t give a specific example of what kind of thing these people might be talking about to arrive at a “whole design”, but I suspect it’s something I have experienced quite often. It goes something like this: I do a sketch of some interaction or other and take it to somebody who might execute that design. They then tell me it’s of course perfectly possible to do, but rather difficult. They suggest something else that I then consider as a compromise, and suggest a middle ground of some kind after thinking about it some more.

Calling the result a “whole design” is something of a euphemism. I’d prefer to say “compromise”, but I’m willing to accept it at a pragmatic level to “ship product”, as those Agile people like to say. But in compromising like this, doesn’t it just get us back to the old days? The days in which 16 characters was all the database could accept, or having a “save” button because the PHP library doesn’t do anything else, or not being able to undo actions because of the stateless nature of HTTP?

Don’t get me wrong. I’m not saying that only UX designers can have good ideas about design. Good ideas can and should come from anyone at any time. But the current state of web and desktop application usability and overall experience is terribly dire. Drive out the UX designers, and it’s only going to get worse.

Comments

OK, I’m not sure who’s saying UX should be stamped out, I haven’t heard it.

There are problems with the UX community and UX as a discipline. I see them every day. I don’t think they will be solved by stamping out UX, they could be solved by making UX better. Here’s what I spot every day from the fringes of the user experience discipline –

User Experience, like many things, is design. Design only works with a deep understanding of the context. The context here is (typically) HTTP, HTML, browser rendering, server-side architectures, database platforms, and so on. Not to mention brand, content, system management, customer support, system fulfillment and so on.

Design without context is not design, it’s just painting. It’s not possible to design a good experience by just drawing pictures and expecting somebody else to ‘implement’, not unless you have sufficient understanding of the context to know how to specify completely, accurately and correctly. There is way too much contempt for the technical in UX, and it shows in the result.

I see UX professionals who hand over wireframes and then never test what’s built. Never even look at it. That’s not design, that’s arrogance.

Could you imagine (I’ll take this example as it’s easy for UX professionals to relate to) Jonathan Ive *not* spending much of his time inspecting materials, manufacturing processes, UI behaviours, touch, feel, and costs? I couldn’t.

Something being limited by implementation isn’t “compromise”, it’s design. That’s what differentiates it from painting. yes, recommend the best solution – but don’t do it in a vacuum. Budget, timeframes, platform restrictions, are all part of the process, not obstacles.

So do it from some level of knowledge and understanding. That way you get the better solution, not the “compromise”.

Why do I see this so rarely in the UX field? Is it arrogance? Laziness? Or simply lack of education? I don’t know.

Compromise extends to not being able to communicate the design to those that may need to know about it before its implemented. It also extends to not having the ability to test or iterate on the design, and it extends to not knowing that a technical limitation exists. So I agree with you when you characterise design as compromise. There are many reasons for this, and I would suggest the are not limited to arrogance or laziness. Maybe compromise is what Anders Ramsay is in fact talking about when he used the term “whole design.”

Note, however, that I’m not saying that compromise is to be condemned. I say I’m willing to accept it – indeed do so all the time. That doesn’t alter the fact that most of what I regard as good stuff often gets left on the cutting room floor. This feels bad to me. But maybe that’s just design failure in action.

But what do you think about the notion that developers create better designs than “UX designers” because they know about the systems they are designing for? And the further suggestion that developers should in fact perform the role of the UX designer for that reason?

That’s my main issue here.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>