This article is also written as material for wallhaus, a community I'm personally involved with where people study design. Since many members are beginners, I've tried to keep things approachable.

I'm planning to write this as a series covering design data from both a designer's and an engineer's perspective. This first part is the preparation stage, covering what a design comp actually is.

Getting on the Same Page About Data

Whatever it is you're building — a website, a web service, an app — the final deliverable is almost never the design data itself (jpg, psd, sketch, etc.). Obviously, what needs to be built isn't the design comp itself, but rather the thing that implements it.

Designers may have different opinions on this, but personally, I don't expect the markup to reproduce the design comp down to the pixel. There's a lot more the engineer doing the markup needs to think about, and the implementation needs to achieve a higher level of polish than the design data — especially nowadays, with so many different devices, being overly attached to the design comp can easily become a pie-in-the-sky exercise.

It's easy to fall into thinking that what a designer produces = design data, but that's really just an intermediate deliverable in the process of building a product. The thing that actually needs to be built is the product that gets launched — it's important to share that common understanding.

A Design Comp Is a Still Image

A design comp is a still image (obviously). You could also call it a snapshot — the data captures a single frozen moment. Because of that, engineers have to infer a lot from it: transitions, display order, transitions and states, and so on — in a real product, the user's actions can change all sorts of states.

These days, various mockup tools have emerged that let you reproduce some of that motion, but designers still need to anticipate the various states in advance.

Common state changes include things like:

• Changes in order or display sequence
• When there's no data
• When there's too much data
  • When the amount of text or number of images overflows
• When data is missing
  • When there's no image
  • When a field hasn't been filled in
• Feedback for an action
  • Added
  • Deleted
  • Saved
  • Loading
  • Reordered
  • An error occurred

What a user does unfolds as a repeating sequence of small actions and feedback. You need to design your data not just for the normal state, but with a sense of the timeline — before and after an action, error states, and so on.

Let's avoid ending up with data that makes people go "wait, what is this?"

A Design Comp Is (More or Less) Built on Rules

I can already hear someone objecting, "what do you mean by 'more or less'?" — but flip it around, and you could say that anything other than a truly unique design that deliberately breaks the rules is built on rules. The tricky part is what those rules are, but personally, what I care about most are the numbers — spacing, font sizes, and the like.

I tend to use multiples of 8 for vertical spacing and a 12-column grid for horizontal spacing. These kinds of frequently used numbers are better communicated directly, rather than left for someone to infer from the data.

How you handle spacing also depends on how you've divided things into sections, and that can be conveyed by properly grouping and naming your layers (which also helps a lot when it comes to marking things up semantically).

When engineers and designers are aligned on what to pay attention to, both sides can work much more comfortably together.

This first installment, being the preparation stage, has mostly been about mindset. A hard-to-read design comp often ends up leading to a hard-to-use design. I wanted to reaffirm that the kind of gap people try to solve with tools can also be closed simply by not skipping the small, careful work.

Cat photo: Photo by Raul Varzar on Unsplash Rothko photo: Photo by Pauline Loroy on Unsplash