Explaining product design as a stack of decisions built on top of a stack of knowledge. With apologies to Jesse James Garrett.

A diagram containing layers stacked on top of each other

Being a designer means making or facilitating design decisions. Your skills are your abilities to do that soundly. But design decisions can be aesthetic, structural, conceptual, strategic and anything in between. And these layers require different approaches and skills.

I was looking for a way to visualise this, and I eventually remembered Jesse James Garrett's Elements of User Experience diagram from over 20 years ago. And it is still a great way to think about design: It's not a process, so much as a stack of decisions.

I hope Jesse doesn't mind, but I've updated the diagram to better fit the language of today's product designers. I de-emphasised the time dependency between the layers, because there are cycles and complexities that mean you don't always start at the bottom. Instead there is a logical dependency. If something in a lower layer changes, it can dislodge the layers above. If the layers above don't map well to the layers below, you'll find yourself with UX debt, and a poor experience. Out with requirements and specifications (considered harmful) and out with the split between software and hypertext which is increasingly blurred. I added a foundation of user research, and made a distinction between problem and solution spaces here too, inspired by Indi Young's writing on that topic. A lot of our energy must be directed to understanding the problem space independent of our solutions, if we want to be innovative.

But remember: products are designed by many people, including people without 'designer' in their title. After all, products are always designed, intentionally or not. A healthy team collaborates on all layers but also takes advantage of specialists who have the skill to make faster, sounder decisions in a certain layer. User researchers are skilled at finding user needs. Product managers are skilled at product & service strategy. And domain experts, engineers and architects have a huge influence on the conceptual model.

And that conceptual model layer is often under-designed, just serving the database rather than the user's mental model and needs. Teams could use techniques like OOUX to work on that more thoroughly.

Use this diagram to think:

  • Do we have a solid foundation for our project? Have we skipped a layer and introduced UX debt? (The conceptual model is often overlooked)
  • Which layer is most of our uncertainty currently in?
  • Does our team have skills to attack the necessary layers?
  • What layer do I most enjoy working in?