Glossary

Designers use certain words time and again in the design process. Since we use them every day, we may not always remember to explain them to you (though we should). If you’re working with a designer and they mention something you aren’t familiar with, don’t hesitate to ask them to clarify. If their eyes light up at the prospect of explaining it, you’re working with the right people.

I’ve taken the liberty of defining terms I’ve neglected to explain to clients in the past. This isn’t an exhaustive list, but I hope it’s helpful.

agile — A process for design and development that values speed and prototyping above documentation. It works great for small product teams and less so with outside agencies who deliver work to others for final implementation. Ironically, a lot of documentation exists on how to work this way. Whatever process you go with, hire people who work fast and enjoy making things.

artifact — Things made throughout the project that aren’t deliverables (for example, Photoshop files). Personally, I work out concepts and the first few simple layouts in Photoshop. Once we’ve sorted out major decisions, our team moves into code, where we make tons of adjustments that we don’t reflect back in Photoshop. Those Photoshop files are artifacts; they helped us get to our final deliverable, code.

When you ask if you can have the Photoshop files, the answer is yes. After all, we made them on your dime. (Other studios’ policies may differ.) But don’t expect them to mirror the final work.

budget — What we’ve agreed the work is worth. Work requested after that agreement requires extra budget and depends on the designer’s availability. (Unless of course you control the designer’s time.)

comp or mockup — Comp is short for comprehensive layout. (Now you know something your designer probably doesn’t.) A comp shows the final placement of objects on the page or screen. Think of it as a painting of a website. It’s the fleshed-out version of the concept and should start resembling the final thing (it isn’t real until it’s coded). Mockup is also acceptable. Mock is not. I mean, c’mon.

concept — An idea. Before your designer spends time diddling with little interface elements burning through hours, they should put something in front of you that illustrates a basic idea. They should also talk you through where it could go.

content — Content is every possible reason someone comes to your website: the writing, videos, stuff in your databases, pants you have for sale, photos, plane tickets, etc. Design’s job is to make content easy to find and present it in the best light possible.

deadline — When things are due. A project is a series of deadlines. You’ll have some, the designer’ll have some. Everybody knows the project’s final deadline, which also is the least important. The most important deadline is the next one. Because if you miss it, you miss all the ones after.

deliverable — The thing you get at the end of this whole process. While your site or app may be your final deliverable, you’ll have interim deliverables throughout the project. Remember that the interim deliverables are important for two reasons: they inform the final deliverable, and they help gain stakeholders’ approval. Don’t ignore that second one. We’ve made many a wireframe or comp presentation to the CEO to alleviate their anxiety mid-project.

discovery — What some design studios call a project’s research phase (us included). Because we discover things. Sometimes things you don’t want us to.

feedback — Constructive response to the thing you see. Feedback can be positive or negative. “I don’t understand what you’re trying to do here” is also helpful. Both clients and designers should give feedback during the design process. A designer giving you feedback on a decision you’re making is totally fair game.

iteration — Nobody gets it right the first time. With helpful feedback from you, the designer gets closer with every step. Iteration is part of the process; that things get better incrementally with your feedback is a feature not a flaw.

prescriptive feedback — Also known as trying to do the designer’s job. “Move this twenty pixels to the left” isn’t feedback. Prescriptive feedback hinders a designer’s ability to do their job as they spend the next three hours figuring out the actual problem you’re trying to solve.

prototype — A quick and dirty version of the design used for testing or convincing the client that an idea has legs. Also called a proof of concept. Thrown away after the point is made.

responsive design — A design solution that allows one codebase to work across platforms: desktop, tablets, and mobile. This means you don’t need to maintain multiple versions of your site, which is a good thing. Responsive design optimizes a site’s layout based on your device. When your designer presents you with the first bits of a coded site, they’ll sit there expanding and shrinking the browser window so you see the page’s elements rearrange themselves. Your designer will keep doing it even after you’ve gotten the idea.

scope — The amount of work everyone has agreed the project entails. Once you’ve agreed to the scope, you can’t increase it without revisiting the budget and deadlines.

spec work — Short for speculative work. This means asking your designer to do the work first, with payment dependent on getting the work approved. Which is like agreeing to pay your therapist only if you stop doing terrible things like asking designers to work on spec.

waterfall — A linear process where each team finishes their part of the project in its entirety before handing it to the next team. For example, the visual designers make 300 Photoshop files and dump them with the front-end developers, who are probably seeing that work for the first time. This is like the telephone game, where the first person whispers, “Potato,” and three people later, it’s “You walk the dog. I’m trying to finish my book.” Waterfall’s biggest problem is the amount of knowledge lost between phases as you have little to no collaboration.

wireframe — A blueprint of the stuff needed on any particular screen or page. It’s usually a bunch of boxes with annotations. The person who shows them (e.g., an interaction designer or information architect) will make a big deal about how a wireframe doesn’t imply layout, even though things are totally laid out. A good designer sees past the layout and moves elements around as needed. There isn’t an industry standard for making wireframes, so they can be as simple as a sketch on a whiteboard or complex and carefully designed objects in their own right. But if your design team spends their time prettifying wireframes, they’re wasting your money.