Introduction

The explosion of management theory in the 1990’s as pointed out in ‘One market under God’ by Thomas Frank, has created a situation where every one has a better theory than the previous person. This makes me nervous about writing a few posts about UX processes. So I don’t want them to be too theoretical but practical. I also want to credit lots of people along the way, because there are so many clever people out there who have already solved these problems. But I think as a manager you are always looking to find a better way of working. I think as new software becomes available you can practically solves some of the old recurring problems.

So hopefully I will avoid as Frank puts it “Anybody who has had any experience with management theory industry can tell  similar stories: of quotes and dates wildly misplaced, of alarming and misinformed credulity about science, of anecdotes that prove nothing, of patently absurd syllogisms, of meaningless diagrams and homemade master narratives.” I am also willing to admit that these solutions are ideas I want to explore and some of them I have not actually used yet, but would love to, as they seem to offer real benefits. Certainly the designers and B.A’s and Project Managers who have adopted some of these ideas can show their benefits. Of course there is no silver bullet and each project will use these no tools and techniques in different ways to suit their needs.

Design Process

In ‘Sketching User Experience’ by Bill Buxton,  his chapter, ‘A sketch of the Process’ always reminds me of the folly of trying to create a silver bullet for the design process, but it does have a great description of the problem we are all trying to solve:-

“My perspective is that the bulk of our industry is organised around two all-too-common myths:

1. That we know what we want at the start of a project, and
2. That we know enough to start building it

Like sirens who tried to lure Ulysses to destruction, these myths lead us to the false assumption that we can adopt a process that will take us along a straight path from intention to implementation. Yes, if we get it right, the path is optimal. Bit since there are always too many unknowns actually to do so, the fastest and most efficient path is never a straight line. Furthermore, my experience suggests that embarking on the straight-line path, and then having to deal with the inevitable consequences, is a path with the highest risk.

At best, it is a route to mediocre products that are late, over budget, compromised in function, and that under perform financially. At worst, it leads to product initiatives that are cancelled, or fail miserably in the market place. And with it, design, such as it exists, typically is limited to styling and usability”

There are many diagrams that visualise the design and development process and I think the stages are commonly understood by most design professionals. The opportunity to improve the design process I think occur within these stages, and it is these that I want to investigate. But I though I would illustrate a few of the most familiar diagrams.

The Double Diamond was created in 2005 by the British Design council and is very popular, it has four phases, Discover to research the users needs, Define were you use the insights from the research to define the specific problem that needs to be fixed. Hopefully this creates a brief that all the stakeholders believe in. Designers and the team can then develop ideas and solutions which create a final design for the product and service to be launched. The oldest reference I can find held in the National Archives website from 2008. The Design Council have recently posted a page on this as well,’The Design Process:What is the Double Diamond?’. The Design Council website also helpfully breaks out all the stages, Discover,  Define, Develop, and Deliver.

This is Tim Browns, ‘Definitions of Design Thinking‘ from September 2007 and I think its all part of his idea of bringing design into all aspects of organisations. I think it has become their company mantra, and is explained in more detail on the IDEO ‘About‘ page.

Finally I have taken this diagram from Bill Buxton’s ‘Sketching User Experience’, I really like it as it shows the well understood product life cycle but also through the volume of the areas shows the effort required by the various disciplines. The annotation to the chart is also very relevant. ‘No silos. A representation of the proposed ongoing responsibilities of the various teams throughout the overall process. Of central importance for our purposes is the notion that “design” includes the design of the business and engineering plans, as well as the product itself.’

Process Sketch

So I think there is a well understood and obvious flow to most UX projects. What I am really interested in is the issues and problems that come up in these processes and some of the ideas  and techniques that help you overcome them. I have draw up a model of the elements I think are involved in a large web development process. I have divided it into three layers, the User Experience at the top, a technical middle layer, and the foundation for it, all a process layer underneath. This all runs along a transparent versioning and iterations path, which gives you control and momentum. I think everyone is trying to find the ideal mix of tools and systems to get their projects to flow smoothly.

I want to explore a few areas when it comes to the ideal mix…

Research – you can’t always get what you want, but sometimes you might just find you get what you need. A little bit in praise of service design and service transformation, which I think means you have the evidence to give the customer wants and convince the stakeholders to change their ideas.

Invisible UX – who looks after the UX that nobody can see. The simpler it is up front the more complex it is behind the scenes. This is an argument for complex technical issues to be discovered as early on as possible in the discovery phase of any project.

Iterations and version control – All large project seem to suffer from all the scope issues that agile development practises seek to avoid. The project team  didn’t gather the right requirements, half way through they abandoned the brief, and a couple of millions of pounds later launched some thing no one wanted. One of the disciplines that is taken for granted in web/software development is versioning, and I think it needs to be more explicit in the user experience process.