Artifacts of Experience

—framework —design philosophy

I’ve spent a lot of time thinking about how experiences come together through design artifacts in over the course of my career. I decided to formalize some of that thinking into a system of artifact types when I was managing design across multiple products at Databook and needed to standardize experience communication across teams.

One of the consistent problems in experience design is a lack of understanding of which conceptual diagram to generate for each particular need. Encoding conceptual information visually is an imprecise art. Just as in software engineering in which there are different orientations of programming that best suit different problems, experience design can sometimes benefit from looking at problems from multiple angles.

In order to create some structure around that exploration,, I borrowed concepts from programming: object-oriented, functional, and structured, and encouraged my team to try to express their solutions through these different lenses. What does it do to the object model? What does it do to the interactions? What does it do to the navigation?

After rolling out these concepts, I collaborated with my team to come up with whimsical names for the types, injecting some fun into the design process.


OxD or OOUX (pronounced "ooosh")

best for:
  • relationships between data
  • concept/value mapping
  • edge-casing
  • what is the user working with?


FxD or FunX

best for:
  • workflow optimization
  • interaction design
  • ease-of-use
  • what is the user doing?


Tree or StruX

best for:
  • navigation design
  • classic information architecture
  • implementation documentation
  • where does the user find things?