UX Process: How do you know when your design is done? A simple 14-point checklist
When are you truly done with software development? Well, when you are out of time and money, then you are definitely done! In all honesty, it helps to establish a short feedback loop, and then iterate, iterate, and iterate some more, while all the time learning, testing and improving. You will be far more likely to succeed this way than by trying to do the perfect design from day one (if you find out how to do that, let me know!).
>> Get the UX checklist here! <<
The first time I recall that the concept of iteration really stuck with me, was when I read Eric Ries’ book ”The Lean Startup”, where Eric talks a lot about the concept of Build-Measure-Learn, i.e. turning ideas into products, measuring the outcome, learning from the data and iterating until you find a perfect product-market-fit. I am also strong believer in delivering 80% of the value in 20% of the time (and I believe that iterations helps you find where the 80% of the value of your product really is).
In short, iterations reduce cost, reduce risk and makes it a lot more fun to deliver products (as you get more confident that what you are building will be useful to others) — products which in the end also make users happier. Win-win, right? Now, having said that, I still think that a well established design “Definition of Done” (which the whole design team agrees upon) can help you deliver even better products.
A Super Brief History about Agile
In 2001, 17 persons gathered and coined the Agile Manifesto, which main points are:
‘Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan’
To me, the Agile Manifesto is a set of brilliant principles, which also blends well with my personal UX process. Unfortunately, many companies today do struggle with combining agile and UX. According to NNGroup, one of the main challenges in the industry today is that user research tends to get abandoned along the way. UX ”Definition of Done” is one of many pieces that help solving this problem.
What is Definition of Done?
According to Agile Alliance, Definition of Done is described as:
‘The team agrees on, and displays prominently somewhere in the team room, a list of criteria which must be met before a product increment “often a user story” is considered “done”. Failure to meet these criteria at the end of a sprint normally implies that the work should not be counted toward that sprint’s velocity. ‘
In my opinion, what Definition of Done really boils down to, is to know when your UX process is done, while at the same time ensuring you actually deliver products that provide value to your clients and users.
Establishing a Design “Definition of Done” in Your UX Process
There is no silver bullet for establishing a design Definition of Done in your UX Process, and as with many things in life, it really depends — in this case, on your project / product / context of use / user goals, among other things.
With that said, here is my go-to 14-point checklist. The checklist is based upon multiple sources, including the work from Nordnet and Joel Sandén. Both the checklists from Nordnet and Joel Sandén are fantastic and I do recommend these checklists as well, kudos on the awesome job guys.
A Design “Definition of Done” Checklist
1. Do you feel proud of the design?
I believe that it’s super important to maintain ownership of your design. Both for personal motivation, integrity and to ensure the best product quality (good process quality builds good product quality). As a UI/UX designer, you are the expert after all!
2. Has the design been tested with real users?
A good design solves a real problem for a real person. It doesn’t matter if you are working in a Business to Consumer or Business to Business context; in the end it’s Human to Human. Sometimes this is forgotten when working with technology all day (I have to remind myself a lot about this!). What’s good is that usability testing doesn’t have to be expensive. I do recommend Steve Krug’s book ”Rocket Surgey Made Easy” for more tips on how to run usability tests in a very cost-efficient way.
3. Does the design work properly in the context of use?
It’s easy to forget context of use when designing something. Will users use your product in sunlight / when raining / when it’s dark? Is the user sitting a quiet office, or a noisy environment, when interacting with your product? Is the user travelling, or is the user always in the same geographical location when using the product?
4. Does the design work with realistic data?
An example could be doing a UI design that works well with 10 items, when in reality the users are more common to have 1000+ items. Always design for the most common use cases first, then cover edge cases.
5. Does the design work on the intended target resolutions?
This criteria is mainly relevant for web design (which I focus on). It is very likely your design will have to work on a range of screen resolutions. After all, people use websites in many contexts these days. Brad Frost said it best:
A good basis is to cover the top 10 screen resolutions mentioned by W3CStats. As of writing this blog entry, the 3 most common screen resolutions are: 640x360, 1366x768 and 1024x768.
6. Does the design follow your company’s design principles?
This depends on the company you work for. Some companies have an overall brand style guide which outlines aspects such as which fonts and colors to use, as well as overall design prinicples (see Apple’s design principles for an example).
7. Is the design using elements from your company’s UI kits / templates?
In some companies there is a common branded UI kit in place, which for instance can contain the style of different UI components (e.g. Buttons, form elements), as well as full screen templates (e.g. login screen, landing page).
8. Is the design coherent with the rest of the product?
It is much easier for the users to learn using a product when the UI elements look and behave the same way all across the product (ideally across products as well, given that the target users are the same).
9. Have edge cases / corner cases been considered?
Ensure to not only cover the ”happy path”, but also the various cases that can go wrong when interacting with the product. For instance:
- When filling in a web form, what happens if the user tries to navigate away from the web form without saving?
- What happens if the data for each item can’t be retrieved from the database?
- When trying to register a new user, what happens if there already is a user with the same user name?
10. Have the ”no content” design states been considered?
We tend to design for the common scenario but often forget how the product looks like when starting from zero. Some examples:
- How does the system look like when you log in for the first time?
- Does the user already have data that will need to be imported from another system? If yes, how can the user import this data?
- How will you ”onboard” the user (so that the user quickly can get started using the product)?
11. Has accessibility criteria been considered?
I’m very happy to see that more and more companies pay attention to designing products which work for everyone (regardless of background or abilities). Microsoft do for instance put ”Inclusive Design” as one of their main design principles.
12. Have you discussed with a developer and confirmed that we can support all the data in the design?
Another design handover criteria from Nordnet. It’s also important to secure that the data can be fetched from the system within a realistic time frame. For web I very much recommend the RAIL (Response, Animation, Idle, Load) model, a user-centric performance model by Google.
In some cases it might also be relevant to prototype parts of the design directly in code, for instance when checking whether it’s technically feasible to implement the design in the given project time frame. I also do recommend to do as much research up front as possible. Ask yourself, ”Has anyone else implemented a solution to this problem, and user tested the said implementation already?”. If yes it might be possible to re-use the same principles in your design and by doing so, save time for yourself and money for the company you work for.
13. Has the writing been reviewed by a content writer / copy writer?
Writing is definitely something I need to practice more. In fact, one of the reasons I started this blog was to further improve my writing! In all seriousness, I think that having a professional copy writer who proof reads your product’s content, makes it much easier to ensure that that you convey the message you want with your design. Your tone of voice can also very much depend on on your company’s brand guidelines. For instance, Mailchimp has a whole Content Styleguide, outlining anything from tone of voice, down to how to write legal content.
14. Have you prepared (and presented) relevant hand-over documentation / assets for the development team?
Mark things such as font sizes, spacing, color hex codes. Ensure to have all image and icons exported. This may also include any proof of concepts done in code (e.g. HTML / CSS / JavaScript).
There are many tools that can you help you with doing the design handover, such as Zeplin and Avocode. I also do recommend to go through all the design assets and handover material together with the development teams that will implement your design, so that the developers know where to find all the design assets, and to avoid any misunderstanding.
Some Final Words
To summarize, this is a checklist I use in my personal work (again, kudos to Nordnet and Joel Sandén for a lot of the inspiration). I still strongly recommend to avoid one-time sign-offs / handovers. Collaborate with the clients, users and developers as much as possible. At very least I hope this checklist makes it easier for you to remember it all.
I also encourage you to continue to iterate on the design ”Definition of Done”within your team — just as we should apply a ”Build-Measure-Learn” mindset for designing our products, we have to do the same with our UX process as well.
Download the UX definition of done checklist here.
I am also very open to hear your thoughts and feedback on this topic, so please leave your comments below! Thanks for reading!
