vote up 3 vote down
star
1

I'm currently in the middle of an attempt to define and document a UX/User Interface Design/Definition Process for my company. I've managed to convince some of the more senior decision makers that we need something much clearer and more useful than the "ad lib" approach we currently use on a project-by-project basis.

I already have a few ideas but I'd like to be sure I'm coming up with something that's proven, that will be beneficial and that implements what might be considered industry best practice.

What pointers would any of you have for me? Are there any sites or books you'd recommend as a starting point? I appreciate that this is a pretty vague, generalised question, but I have a (reasonably) blank slate to begin with - I'd like to make the most of it.

flag

5 Answers

vote up 5 vote down
check

We’ve been on this journey for a while now and it can be quite a daunting task. I spent some time searching in vain for the right answer but I’m not sure it exists. There are so many methods and huge variability for what counts as ‘best practice’ UX design (or UCD, ACD, IA, usability, … etc). But don’t let that put you off! You have the opportunity to really make a lasting difference and it’s really rewarding when it starts to pay off.

What works in my organisation may not work for you, but here are a few things that I’ve learned:

  • For proven approaches and industry best practice you may want to base your approach on ISO 9241 – they are not likely to argue against an international standard. It’s not the most fun to read but it covers all the basics and underpins many approaches currently in use. The Userfocus Bluffer’s Guide is a good place to start.
  • Get your elevator pitch right. You need a concise description of what you do and why in order to build awareness and understanding.
  • Understand what drives the people making the decisions and give them answers to some of their problems (e.g. if there’s a history of a lack of user/client acceptance, focus efforts on rapid early prototyping).
  • Whatever you do, add value. If you’re a useful person to have on projects you’ll be asked back, whether they think of you as the ‘usability guy’ or not.
  • Make your deliverables stand out in terms of presentation, quality and usefulness. Most documentation on large corporate IT projects is very dry and narrowly focussed so make use of the unique UX view of the world to draw technical, business process and user interface strands together (like the UX Swimlanes).
  • Find gaps in the current development process that you can plug with UX methods and processes. Measuring business benefit (ROI) on internal projects is a big one for us.
  • Go deep not wide. It’s better to get really stuck into a project and deliver measurable value, rather than tinkering at the margins across too many projects.
  • Generate success stories and publicise them by creating slide shows, usability testing videos and other easily sharable case study material.
  • Simplify your process so that (almost) everyone ‘gets it’. Having something that looks too clever is a hindrance in some organisations because people are generally searching for simple solutions. Don’t make UX stuff look too onerous, and phrase it in everyday language.
  • If you need strategy material for senior management presentations, have a look on Slideshare first for inspiration because UX folk are a sharing bunch and someone will have already been through it.

For books I’d recommend a Project Guide To UX Design because it’s really applied and is focussed on making a difference on live projects. And if your organisation likes metrics then Measuring The User Experience is a must-read because it provides great instruction on delivering qualitative and quantitative measurements to underpin claims of “easy to use”.

Hope this helps
R

PS If you are short on inspiration have a look at (and listen to) Leah Buley’s UX Team of One

link|flag
Hi Rich - that's a really, really helpful summary with some great pointers. Many thanks indeed... – Sam K Oct 19 at 7:10
Another interesting ISO standard would be 13407 which adresses quality criteria for user-centered design processes (unlike the 9241 which is about quality criteria for products). For german readers there is a more extensive guideline document published by the former DATech, the "Prüfleitfaden Usability" which explains many methods and how they can be used to fulfil the norm (tinyurl.com/ylhknw7) – Lisa Daske Feb 9 at 8:47
vote up 6 vote down

I would recommend the following books:

  • Creating the Perfect Design Brief by Peter L Phillips
  • Communicating Design: Developing Web Site Documentation for Design and Planning by Dan Brown

The best lesson that I learned from both books was that your documentation should explain how your design decisions answer the clients business needs and requirements. By answering this don't have the debate about aesthetics which is a hard argument to win. If the client doesn't like certain elements of the design then maybe their requirements changed or were incomplete.

link|flag
"The best lesson that I learned from both books was that your documentation should explain how your design decisions answer the clients business needs and requirements" so very, very true. The documentation isn't the point. The communication of the "why" to everybody involved is. – adrianh Oct 14 at 6:10
vote up 2 vote down

Defining your company's process will take time. A survey in The Netherlands showed that it took companies an average of 18 months from start to "finish" (i.e. everyone trained in the process, and maintenance phase started).

I have included an overview of this design-process design-process in several of my presentations. At the German IA Konferenz I gave an overview of UX Design deliverables and processes that may be of use: http://www.peterboersma.com/blog/2009/05/ux-deliverables-in-practice.html (slide 137 shows the process).

link|flag
Crap - I've got 3 months! :-) Many thanks for the link - I'll try to digest that over the next few days. – Sam K Oct 14 at 13:05
vote up 2 vote down

A couple of us at my current company are trying to move from the ad-hoc approach to a more formalised one. It sounds similar to the challenges you are facing.

A couple of articles by Neilson may help: Corporate Usability Maturity: Stages 1-4 and Corporate Usability Maturity: Stages 5-8. They provide a good overall background, and something to aim for.

The one element that seems to be working well for us is that we are weaving the UX Methods, timings and deliverables into our current project lifecycle. This has a few advantages of getting most people to understand the process quickly. The idea is we’ll be in the room when the project is just the germ of a ‘good idea’.

For deliverables, we are using some of the excellent templates available in the community, and have created a diagram that documents the UX Methods, UX Deliverables, and People Involved at every stage of our project lifecycle. We have also detailed what current products the UX stuff gets inserted into. This got people on board very quickly, as they can see the alignment — we didn’t want to give the impression we were re-inventing their wheel.

Another trick was to get UX as a principle in our Enterprise Architecture — it means that it has to be considered before any project gets sign off.

One final thought is engagement with stakeholders. I’m unsure what size your company is, but you’ll need to speak to as many people as possible, and get as many challenges to help refine and test your ideas. We’ve spoken to Solution Architects, Business Analysts, Testers, Project Managers, Department heads…etc…etc…etc. Get them on board as soon as possible.

Of course, each company will be different, so some of this may not apply. Good luck!

link|flag
vote up 2 vote down

Nokia recently published a good resource: Introduction to User Experience

It gives a simple overview of the processes and benefits. Some of the points might be useful for your work.

link|flag

Your Answer

Get an OpenID
or

Not the answer you're looking for? Browse other questions tagged or ask your own question.