In this user-centered age, product designers have to understand every client/stakeholder need—and how your design meets each and every one. And with all that knowledge, you’re bound to become the go-to for developers and clients wondering, “What does this button do? Why is this here? When do I show this page?”
Welcome to the design-to-development gap.
Maybe you’re already putting together a design spec sheet covering fonts, spacing, icon sizes, colors, etc. This definitely helps developers reproduce your design, but it doesn’t dive into any of the technical specifics of the app.
Related: 6 tasty ways for designers and developers to collaborate better
Now, you may be thinking, “This isn’t my job. I’m not a technical person. I’m the creative, not the developer or project manager.” True enough. But if you don’t document, you risk seeing your vision derailed.
“The best products result from design/development harmony.”
3 steps that help bridge the gap
Designers and developers think very differently. But incorporating these 3 documents into your handoff process will give the developers working on your design a whole new vantage point.
Step 1: Create a component diagram
Developers don’t care (much) about icons, hues, or gradients. They just want to know what the requirements are. What information the system needs and what actions it should perform.
With this in mind, give your developers something they can process easily: the component diagram!
The component diagram details every system component and its contents, and is fairly easy to do in a developer-friendly Freehand. With this we can document all the types of information the system will need.
For practice and to get used to this way of thinking, imagine you’re building a mobile trivia game app. First, walk through your design’s registration screens, noting all the info you ask for. Call this component “User Information.”
While the user won’t necessarily provide all of these items on registration—things like profile image, location, and password may come later—they all belong to the category “User Information.”
Now that you’ve had a bit of practice, let’s try it with another, more complex section of the system. In this trivia app, one playthrough requires many items, such as a user 1, user 2, category, subcategory, questions of various difficulty levels, etc… To compile all these items, we go through the entire workflow, noting all of the items required to play. If an item (like a category) constitutes its own component, underline it so others will know to look for more info elsewhere.
As you can see, even though the requirements are relatively complex, placing them in this diagram creates a lot of clarity. Once you’ve done this for all components and items of your design, create a sequence that captures the main user flow.
Success! Don’t you feel more technical already?!
Suddenly, it’s easier to wrap your head around the project from a technical standpoint. Don’t be afraid to take off your design hat and think like a developer. It’s good practice for a product designer to walk a mile in someone else’s shoes. Plus, you’ll work more effectively and get clarity on projects like never before.
Now, let’s let’s define all the items listed in your component diagram.
Step 2: Define terms from your diagram in a project encyclopedia
With all your components diagrammed, it’s time to elaborate on the items that need it.
The project encyclopedia serves as its project’s bible—the go-to guide for the lost and confused, whether they’re developers, project managers, or clients.
To get started, create a Google Sheet, enter all the terms from your component diagram in one column, and add a brief description of that term in the right column.
As you can see, there’s a dynamic requirement here with the in-game currency, fortune cookies. The user can earn up to 3 free cookies—no more. If the user has more than 3 fortune cookies, they won’t be able to earn any more. These types of requirements can easily fall through the cracks without this sort of documentation.
The encyclopedia lets you share your knowledge of each and every item in the project and define terminology. And that helps everyone speak the same language, cutting down on confusion in conversation, collaboration, and project meetings.
Step 3: Annotate your designs
By now, the project requirements and your design solutions for them should be pretty clear in your mind. You just need to tie it all together. To do that, it’s time to return to your actual design deliverable.
Label your design with the terms you defined in your component diagram and encyclopedia. Be sure to only use items you defined in your components diagram and encyclopedia. That way, any stakeholder can look to the encyclopedia for answers on each and every screen, icon, button, and text element.
This stage might spring a surprise or 2 on you. Did you miss an item during your component diagram phase? No worries, just update your diagram and add that item and its definition to your encyclopedia. Labeling your design not only clarifies things for all parties involved, but also serves as your fine-tooth comb. Nothing gets missed here, buddy!
“The more you think like a developer, the more seamless the handoff will be.”
This labeled document, along with your component diagram and encyclopedia, will eliminate all confusion for any stakeholder. The client, developers, and project manager can all look at these documents and clearly understand the function of each and every single screen, icon, button, and font at any point of the development cycle.
Congrats! You’ve closed the design-to-development gap!
Think like a developer
The best products result from design/development harmony. So the more you think like a developer, the faster, easier, and more seamless the handoff to dev will be. Following these simple steps to produce powerful documents will help you take your first steps into the development world—and expand your design toolset.
