If you’re a designer, I’m sure you’ve heard the age old question, time and time again — “what does your design process look like?”
This is a notoriously tough one to answer, considering that a design process is not a hat you can take off of one team or project and place onto another. The process itself will always be fluid, depending on a variety of needs and factors! However, what if I told you that you could employ a specific framework to help in uncovering the right process?
A Definition of Done (DOD) is a practice that comes from the scrum framework in the agile methodology. While Scrum has laid out a clear methodology for software development, there is a gaping hole when it comes to the design work that precedes it.
Overall, it’s up to us to take this concept as designers and do what we do best — redesign it to work for us.
Defining a definition
If you were to ask me how I define a DOD for designers, I would say that a definition of done is a way to establish requirements and touch-points in order to stay accountable, organized, and build up/maintain a team understanding of one’s individual design processes.
Specifically, a DOD can help:
Create transparency around our personal process as a designer
Educate our teams on what it takes to create quality designs, in turn building empathy
Hold ourselves accountable
Achieve a sense of completeness in design work
Getting started
A DOD should be established on a case by case basis. In order to begin crafting one for your situation, ask yourself the following questions:
1. What are important milestones I want to be held accountable to?
Think about who you want to get sign off from, and whose input is valuable along the way. Also think about forcing functions you can set for yourself and your team that could help achieve these milestones in a timely manner.
💡Example: perhaps upon the sprint where you’re starting to user test, you want to setup a meeting to align on and establish high level goals of the user testing.
2. What materials do I want to gather for this particular project given its scale?
Scale is very key here. Meaning, is this an MVP? Is it an iteration? Is it a grand undertaking or simply low hanging fruit? The size of your project ought to dictate what supporting materials you want to create.
3. What pieces of my process do I want the team to understand/be a part of?
It’s okay to be a bit selfish here! Really — what things do you want to put on this checklist for your team to see? What do you want them to know goes into crafting your designs and solutions? Also, what parts of your process do you want to include folks in?
4. What things will make me feel like this project has been completed?
As the lead designer, what will make you feel good when handing this off? This is a great opportunity to focus in on your grand vision and lay it out for yourself and your product manager to revise later on.
Wrapping up
In short, a definition of done ought to fit the mold of your team or project, and should look different depending on individual needs, team setup, and project scopes. Here are some final key points to remember:
A DOD is meant to set high level goals and milestones
A good DOD should feel attainable and inclusive
🧠Can you think of a recent scenario when you’ve encountered a challenge and a definition of done may have helped?