The productivity of a Digital Product Designer is defined by the amount of good work he/she is able to put out into the real world together with the team. This is the place, where you get real feedback to learn and steer your product in the right direction. Unnecessary chaos in the midst of a development cycle often stands in the way of this goal. Sometimes developers find edge cases, which make the design unusable. Other times, a developer messages you asking for missing assets. A frustrating and time-consuming problem. However, there are tools to deal with those types of problems upfront.
As a Product Designer, it is your responsibility to validate, if your solutions are useful, usable as well as feasible. A hard job to keep track of while juggling a dozen other balls like making sense of new research findings, already working on new solutions to new problems or validating, if your design was implemented as intended. But there is a tool, which helps you with that task: a simple checklist.
Here are the questions I gathered for the team I’m currently working with:
1. Do you like it?
In my research to this article, I found a similar question and slightly changed it. It’s so simple and yet so important. Often times, good solutions seem so obvious to us in hindsight. It’s an intuitive feeling you have about your design and if it is the right experiment to go with.
Furthermore, I think that it also forces you to take a second look and evaluate, if it is well crafted and whether it lives up to your own expectations.
2. Does it solve the (right) problem?
Good design is effective and useful. Before thinking about other evaluation criteria, it needs to solve the task at hand. It should improve the qualitative and quantitative metrics you want to achieve.
There is also a second question in there: are you sure that you are actually solving the right problem? Take a step back. Do not only focus on the solution. Keep questioning the problem.
3. Does it beat alternatives?
Another important aspect is the path you took to arrive at your solution. Did you search for alternatives? How many? Under what circumstances are these better or worse? Without alternatives, the current solution is always the best, but also the worst. You should be confident that your approach is the right bet to take.
4. Did you test it?
Are people able to solve the task? Do they think it’s a desirable solution? Are there any variables in the context of use you have not thought about? Usability and desirability of your design are the key dimensions defining its value. If you don’t have access to end users, try to talk with colleagues or friends outside your team. Feedback from colleagues on your team is also valuable because they have an overview of the whole application. Most often though, it’s also biased.
5. Does your design work with real data in a real context?
It doesn’t matter if your design looks awesome in Sketch or feels great while clicking through in InVision. What matters is the real world. Therefore, use real data to test your design and don’t look at big artboards, but try to use it in realistic ways. If you design for the web, plugins like Preview in Browser (Sketch) can help.
6. Is it well thought through (e. g. edge cases or additional states)?
Stress your design to its limits. Look outside the happy path and find edge cases. Click yourself through your design to see if you missed any states (e.g. hovers). On the one hand, it enables you to make a confident decision about which alternative solution to take. On the other hand, you will be able to provide your developer with all the necessary documentation.
Example questions you could ask yourself:
- Edge cases: What happens if a user accidentally closes the browser?
- Empty states: What happens if a search result shows no answer?
- Feedback: Is feedback required in form of error, warning or success messages?
- Interaction states: Are there hover, active or focus states that are important to a developer?
- Animations: Are there any animations or transitions between components?
7. Do you use components from the design system? If not, is the trade-off really worth it?
Reusing components does not only improve consistency but also decreases technical complexity and improves communication between designers and engineers. As a rule of thumb, ask yourself: Is it at least 3 times better? If not, use the component from the design system.
8. Do you have the developer’s input on your design?
Involve developers as soon as possible. Despite the fact, that you might be able to think the design through from a technical perspective, there might also be other functionalities which you do not consider at the moment. Furthermore, this will decrease the time needed for the handoff itself.
9. Do you have concise copy, which is easy to understand for all relevant users?
Words matter. I came across many solutions where two or three sentences in the design completely turned the effectiveness on its head. If you do not have access to UX writers, try to gather some basic knowledge on the topic. There are awesome articles out there on UX writing. Spend time to look at every word in detail. Doublecheck them from the user’s perspective. In my eyes, at least the basics of writing good copy should be in the toolkit of every good designer.
Here are three great posts to start with:
- How to build a better product with UX writing – UX Collective
- How to write for interactions – UX Collective
- 16 Rules of Effective UX Writing – UX Planet
10. Did you provide enough documentation for the developer (including all relevant assets)?
Minimize unnecessary loops until the feature looks and functions as it’s supposed to. If you feel unsure, work on your documentation. It takes discipline, but it’s a small step that might save you a lot of time in hindsight.
Using the checklist
When should you use the checklist? In my opinion, as early as possible. As soon as you’ve found some promising concepts, take a look at the questions listed below. The sooner you make sense of unknown unknowns in your design, the sooner you will be able to make a confident choice about the trade-off you have to make.
This list is far from perfect, but it works as a handy tool in our project. We have print outs in front of every designer’s monitor. Depended on your scenario, more questions might be required (e.g. regarding responsiveness or accessibility). You need to define the handoff questions for your project and especially your team. Where does your team need improvement? Which mistakes are regularly being made? What’s YOUR most common mistake? These are the things such a checklist should address. Take mine as an example, but don’t blindly copy it. Adapt it to your scenario and language.
You can download the A4 version of the checklist. Just fold it three times and place it in front of your monitor.