Improve team communication and speed up your design process by using these standards the next time you brainstorm on a whiteboard.
Whiteboards are a beautiful thing for designers. A temporary and erasable canvas, they are the perfect medium for the initial concepting of a product or design.
But we have a bone to pick with the typical whiteboarding process. First off, it usually involves just one person standing at the whiteboard while others watch. This is terrible for collaboration, as most of the team is passively involved. Then, of course, it’s usually just scribbles, amorphous shapes that hold no meaning. Ultimately, it leads to a messy end-product, something that is indecipherable when we go to work on it. A great strategy derived on that whiteboard may not be implemented because no one actually remembered what it was.
A Better Way to Whiteboard
We grew tired of unstructured, sloppy whiteboarding sessions. We wanted a more effective method of concepting that we could actually share with others who weren’t at the whiteboard. That’s when our “whiteboard framework” was born.
The framework enables your team to work through a story or specific flow with consistent drawing techniques and colors. This makes it clear what needs to be done to anyone looking at the image (whether at the whiteboard, or three weeks later in a photo). It establishes a set of rules and a language that can be used to communicate concepts with anyone from the team.
Establish a Design Language
The first part of the framework is creating a design language for development. Working with a defined design language (normally in the form of a living style guide) creates a consistency in applied styles so everyone understands what the style is and what it should do.
The idea behind our design language is to use simple words to describe complex components to instantly align designers, strategists and developers. For example, we were once working with a radio button group that filtered content beneath it. This button group had a very specific behavior and look, but the team was confused as to what to call it. Instead of nebulously referring to it as the Button Group Radio Selector Filter Thing, we decided to call it a “Boxcar.” Giving this component a name immediately got everyone aligned on what we were talking about. From then on, once someone said Boxcar, all team members understood the visual design, interactions, and functionality.
When you decide how a component should work and behave, and when that component is used, it’s easier to understand how the pieces should fit together when it comes to designing or building that component. Plus, establishing a design language upfront reduces the back-and-forth between designers and developers during production, since the mutual understanding is already there.
Define a Concepting Language
Once we had alignment on what to call specific features and components, we realized we needed to take it a step further. We needed something to unify the interdepartmental teams in the earliest stages of the design process: A Concepting Language. This became the basis of our whiteboard framework, a basic system to facilitate clear communication, consistency and accuracy in the early stages.
This took form by using basic shapes and only four colors for our whiteboarding concepts, easily found in any pack of dry erase markers:
Black = Layout
We use black for page layouts, any of the UI components on a page and basic copy. We keep this very basic to not overwhelm the drawing. There are four primary layouts we use in our framework: Page, Modal, Takeover and External link. Each has its own treatment so we can easily distinguish between them when looking at the concept.
Red = Content
All on-page content is written in red below the layout. This allows the layout to remain clear and uncluttered. The idea is to provide accurate details for anything that is on the page, including labels, copy, buttons, table columns, etc.
Pro tip: Never use lorem ipsum! Use real copy to help make the transition from whiteboard to development much easier. Thinking about the content in advance saves time later on and makes the intention behind the concept very clear.
Blue = Action
User actions are the thread that connects our layouts to complete experiences. By drawing CTA buttons or text links in blue, we make clear exactly what the user is interacting with and where they go once they click. This is the only thing we draw in blue on the whole page to help identify consistency in button placement later on. After a few rounds of concepting in this language, you’ll be able to follow the blue to quickly scan the flow.
Green = Conditional
This is our utility color for all the wildcards. In our concepts, you may see green in the layout and in the content section. Green can show access-gated content, such as admin-only access, or if permissions are needed to use a particular feature.
We also use green for future-proofing. For example, we can plan Version 2 features while working on Version 1 by sketching them in green. The green indicates that the feature will be there eventually, and its placement is being accounted for in the layout.
Go Forth and Create
Before you get started with your team, there are a few things to keep in mind as you introduce it to your team.
First off, it takes time. We evolved this framework over a period of 6 months at Digital Telepathy and we are always considering new ways to improve it (for example, would more colors allow more information to be communicated?).
Secondly, it also takes some effort to stay consistent at the beginning. Many team members using the framework for the first time will want to mix colors, but stick with it! The framework was crafted and evolved by defining intention and purpose for each element.
Finally, make it a focus to get everyone involved. With everyone at the whiteboard, team collaboration skyrockets, and issues are solved faster. With developers, designers, and strategists all contributing in the concepting phase, awesome ideas are uncovered far more quickly, and experiences can be validated more rapidly.