Note: Because this is an ongoing series, viewers will not receive a certificate of completion.
Skill Level Beginner
- [Instructor] If you hang around a product development team long enough, you'll undoubtedly hear the term design comp being used to describe pictures of the interface. The term comp is short for comprehensive or sometimes composition layout. Back when everything was done manually, designers would go through four main stages of an illustration, like a poster or advertisement. First, the designer would sketch out several ideas then choose one to take the next stage, layout. The layout would show how each part of the image would fit on the page. The comp would tidy up the layout and use stock images and clean text rather than sketches for the components on the page. The comp would be used to get agreement from everyone involved before the designer created the finished design. Nowadays, in interface design, we follow a similar pattern. We move from sketches to wire frames to comps to code. Comps are higher fidelity than wire frames. They're visual representations of how the interface will actually look on screens before the screens get created in code. Because comps are created using graphical design software, there's less of a clear boundary between these four stages and in fact, because designers often have a library of interface components to copy and paste into their designs, it's possible to go straight to a comp without sketching or wire framing beforehand. Many designers prefer to work at this level of fidelity when they're creating new interfaces. That's great for saving time, but because comps take more effort to create than quick sketches, it's easy to get overly invested in them. That make you less likely to ideate further and explore other alternatives. There are some other concerns with comps, as well. If your design looks more polished than your current level of thinking, people may assume it's more finished than it really is. If stakeholders see images that look like finished screens, they'll often believe that the product itself must be finished, even if coding hasn't actually started yet. Usability testing with comps is a good way to get feedback on the interface, but participants tend to assume that the design is finalized, so they give a different kind of feedback than if you were showing them sketches or hand-built paper prototypes. Comps are built in graphic software, not using code. Unless you've worked really closely with your developers to ensure you've got a standardized set of components in your design software, they might have to do extra work to make the actual product look the same as your images. Any changes from default control sizes, shapes, colors, and behaviors will cause headaches for developers. At best, the developers will spend the extra time to translate the designs into code. At worst, they'll just ignore the design elements and then there was something that doesn't look like your comp design. Comps don't typically show behaviors like animations, transitions, or how elements resize and rearrange in a responsive layout, so you'll still need a way to communicate this to everyone involved. Comps are really helpful for visualizing and communicating design, but be careful not to let them rush you through the design process. Sometimes, the fact that you're showing stakeholders or usability participants a sketch or a wire frame rather than a comp communicates a lot about the stage you're at in the process and the type of feedback you want from them.