Giving and receiving design feedback in the product development process is difficult—so difficult that there are whole books written on the topic. Most software stakeholders don’t approach the software development process with an innate knowledge of how to effectively critique a design, and many designers do a poor job of teaching them how to do this at the beginning of a relationship.
As a result, the customer-designer relationship is at risk of devolving into a situation where the customer gives feedback such as “Move that over there,” or “Make that blue brighter,” or simply, “I don’t like that color,” and the designer is left feeling frustrated and disrespected. Feedback like this isn’t useful to the product development process, because it is often based in a team member’s personal preferences or incomplete understanding of a design problem. I’ve come to describe this as “Paintbrush Syndrome,” meaning the customer is treating the designer as his or her Photoshop-wielding paintbrush.
To improve the quality of feedback and guard against Paintbrush Syndrome, I rely on design principles.
Defining a Project’s Design Principles
A project’s design principles should be defined by the team, driven by user research, and customized for each product. They function as the guiding light for a product’s development, defining and communicating the key goals and characteristics of the product.
When established early and referenced often, these design principles can provide an effective framework that all members of the product team (designers, developers, and stakeholders) can use. They provide a solid structure for important processes in both “little d design” (evaluating design mockups, interactions, and workflows) and “big D design” (making product decisions about which features to include and how to prioritize them).
While design principles vary for every project, they share some common characteristics:
A project typically has five to ten design principles.
Unless you’re solving a very simple problem, establishing fewer than five principles means your principles will simply be too broad to be useful. More than ten, and they’re too hard to keep track of. I typically strive for five to seven.
Design principles are grounded in user needs.
As you create your design principles, you should be referencing personas and information gathered during user interviews.
A project’s design principles don’t change.
Unless the product pivots, or user research unveils new, key information, design principles should be established at the very beginning and stay stable throughout the life of a product. They shouldn’t be negotiated and changed as you go along.
Design principles have a consistent structure.
Typically, I use a short, memorable sentence, followed a supporting statement. For example, I might define the following five design principles for a hypothetical digital signage product meant to help people find and reserve a space in a busy area:
- Engage at three levels: Alert, inform, interact.
At a distance (7-15 ft.): Provide immediate information about current status.
From a few feet (2-7 ft.): See an overview of what’s happening now and later.
Up close (1-2 ft.): See detailed information and interact with the device. - Empower local control.
Everything can be done on the device—no need to go to a calendar or a website to claim a space right now. - Enable visual overview.
See what’s going on in the space at a glance. - Don’t create extra work.
Users are busy, so minimize interruption to their day. Offer simple entry and usage for the common use cases. Allow more precision for those who want it. - Consider the context.
Consider how these devices work together as a system, not just on their own.
A project’s design principles may sound familiar.
Sometimes, your design principles may just be good design. For example, say you were working on a point-of-sale app for a checkout counter. In that context, the operator would perform the same set of actions over and over again, so they should be quick and easy to find. For this product, one of your principles may be, “Keep it fast–everything I need should be immediately accessibile to me.” Fast and simple is just good UX, right?
However, design principles are an expression of your product’s priorities. By elevating this tenet of good UX practice to a principle for your product, you’re saying it’s more important than other concerns. Later on, when it comes to the choice between keeping a minimal UI or keeping workflows extremely accessible, you will know that you need to choose accessibility.
Creating Product Design Principles
The best time to establish your design principles is at the beginning of a project. Typically at Atomic Object, we start with a Research, Design, and Planning phase before we start designing and building a product, and this is the perfect time to establish design principles.
We work collaboratively with our clients to generate the principles, by understanding what’s important to them and backing it up with research from their users. Typically, our principles might go through two to four drafts during this phase of the project. We want to make sure that everyone believes in them fully and feels like they accurately represent the product’s goals and direction.
Using Design Principles
Design principles are of no use if you establish them and then leave them in a document repository to die. They need to be printed, hung in the team’s workspace, and referenced often.
When presenting work, you (or the designer on your team) should point out areas where the design is upholding the principles. During the generative process, design principles function as a tiebreaker between two good ideas. If the team comes up with two different (good) ways to create a workflow, design principles can often cast the deciding vote.
When critiquing work, focus on where and how the work fails to respect your product’s principles. If a critique doesn’t reference the principles, say things like, “Thank you for sharing your feedback. Can you tell me which of our design principles you feel is being disregarded?” or, “What part of the interface needs to be changed to meet our design principles?”
The principles are a great tool to focus the discussion on identifying what is really wrong with the design, moving away from Bandaid directives like “Move this over here.” It gives the design team more information about what needs to be improved, and provides the space for team members to go away and think deeply about how to improve it.
Have you ever used design principles with your team? What benefits did you see?