Thanks to a conversation I had with Jack Zerby at Gumroad, I now feel more comfortable working with designers to create a user interface, graphic, visual identity, or any other design artifact and have become much more productive at communicating and delegating design tasks. This is essential because my design skills are non-existent. Fortunately, design skills don't matter in creating a spec, design thinking does. These are my notes from that conversation.
Readers familiar with speccing software or anything else may realize that the advice I'm conveying here matches both your use case and the general case. That, in fact, is the insight that I was missing before the conversation. I already knew how to spec a design, I just needed the right words.
Step-by-Step Spec
If you write a spec with all of this information, your designer should have everything they need to get started.
Step 1: Specify context and canvas
The canvas is the size and nature of the space the designer has to work in. For graphics, it is the literal dimensions, for software, it is the range of screens that a user might interface with the design from. Web vs mobile is also a canvas question.
Context is what else is nearby. This can mean other aspects of the application as a whole, or it can mean where the user is in a certain process when they encounter the design. If you are asking for a graphic to use on Twitter, that is part of the context, and is very different than asking for a graphic to use on a physical billboard in ways that just the size of the canvas doesn't fully convey.
Step 2: List the ingredients
What actually goes in the design? What information needs to be conveyed? What actions does the user have access to? Be complete, if you don't list it, the designer won't know to include it.
An existing stylesheet, illustration, library, or other asset is also an ingredient in the design.
Make sure you have the right number of ingredients for your canvas and context. The more skilled your designer, the more range you get on this, but only to a certain limit.
Step 3: Identify patterns and hierarchies
Tell your designer which elements and ingredients are the most important. When you tell your designer the relative importance of the various aspects they use their tools to communicate that importance to the user.
Work with patterns of information within the hierarchy while avoiding identical sections blurring together. Information should match and rhyme, not repeat. But, without a pattern, the design will present friction to the user.
You can communicate hierarchy in words. Lists, especially nested lists, are important here. Order matters, especially in something that can be scrolled through.
If you communicate hierarchy in pictures, don't go any higher fidelity than a fat marker sketch. Otherwise, you'll artificially limit your designer early in the process.
Step 4: Set tone
Asking to communicate emotions, impressions, and themes is okay, even good. "X but not Y" is a powerful pattern for doing so, like "minimalist but not empty" or "whimsical but not frivolous." The more evocative your description, the better.
Step 5: Send and iterate
Everything in the spec should be written to avoid friction with the designer. Every time they have to ask you what you mean or you go back and forth on an aspect of your spec, that adds friction to the design process. The faster the turnaround, the more specific your request should be. Specify how many iterations your project merits or your timeline allows.
Design iterations alternate between wide and deep. A "wide" iteration yields several versions of the requested design as a whole. A "deep" iteration takes a chosen design from the wide iteration and comes up with variations on the theme.
