7D Product Design

For a time I have been wrestling with a way to help my colleagues and stakeholders better understand how design can and should be incorporated into the product design process. They have mostly already bought into the end-user benefit of design, delivering a better user experience. However, so long as how I do what I do remains largely a mystery to them, efficiency and effectiveness suffers. Managers are not able to adequately plan and track progress, stakeholders don’t understand what they are getting and when, and I am left trying to rein in developers who want to race to the finish without proper design direction and jumping all over the place in a way that hampers my ability to produce the best designs. I suppose this is no different than anyone else trying to figure out how to implement “design thinking” into their organization, but for me, I needed a solution that was fast and effective. So I did what designers do. I designed a solution.

A few months ago I published my UX Design Process diagram. The idea was to create an accurate visualization of how I design things, one that could be married to the Agile product development process my customer uses, or to any other that might be utilized. From the response I have received, the diagram was a good effort.

However, since then I have more and more found faults with it. First and foremost, it is simply too linear. While my design work has an overall linear trajectory, in truth my process involves lots and lots and lots of circling back, detours and meandering before it is complete. At the same time the various disciplines involved are not strictly limited to specific “phases” of the process, but rather overlap in many ways. In fact, there really are no neatly siloed product design phases, one after the other. Instead, I find that there are simply “types of work” that needs to be done, and which could happen in any order, despite the generally accepted order.

No matter what development process a team uses for creating a product, the design aspect, which can touch on nearly every part of that process, cannot be cleanly pinned down. There is simply too much “Ah ha!” going on, that is intrinsic and necessary to good design, and such moments of inspiration, recognition, and resolution don’t follow a formal process.

So, if a nice linear process diagram is not accurate, how can I visually represent what I really do in a way that can still be useful to my team and stakeholders?

After a good deal of thought, I arrived at what I am calling the 7D Design Process. It consists of seven types of work that occur during product design and development, represented as bubbles, each given a name that begins with the letter D. The relative size and relationship to other bubbles indicates the general order in which each type of work occurs, the relative amount of effort involved in that type of work, and where that type of work overlaps with others, which suggests where multiple disciplines may be required.

As with my previous diagram, for each type of work I have also included a list of the specific things that would be achieved and artifacts that might be produced.

Reflecting on this new diagram, I believe it is a far more accurate representation of how I design products, where and when my skills are best utilized, and the kinds of artifacts that might be beneficial at any given point in the process.

I hope this new diagram proves even more valuable than the last. Here you go.

Oh, and here’s the diagram as a PDF.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.