If you’re working on a digital product or service for a larger organisation, you may be working in a multi-disciplinary team utilising a form of Agile methodology. Your team might be made up of many people each with their specialisms in design, development or research, or there may be fewer of you and that cover more areas of expertise as required by the team. Whatever the composition, you will (hopefully!) have some process to track your upcoming work, the progress during it, and the completion of it.
In the world of business, product teams such as these are ultimately measured on their ability to deliver. It can be used as a single indicator of how well a team is performing in terms of being able to release new software into the world. Now, I have many arguments against finding a single indicator to measure what is an extremely complex process of inter-related tasks and disciplines, but that is a whole subject that could be discussed across numerous blog posts or its own book, so we’ll deal with this as a given for the time being.
If your team is put up alongside others in the number of releases made in a given period, initial impressions will be that the teams releasing often and successfully (by which I mean not breaking everything once the release has been deployed) will be held aloft as a shining example, whilst those working on something much larger that requires bigger releases with more risk will be under far more scrutiny. Yes, there is far more nuanced reasoning behind why teams are working the way that they are, but again, we’ll have to save that conversation for another time.
These releases are ultimately a measure of developers reaching their definition of done. The work that was set out before them has been completed, it was deemed to meet the acceptance criteria, and has been tested and proven to meet those criteria. The criteria defined by the work done by designers and researchers. But what criteria do designers have to meet for their work to be considered done?
Designers, how do you know when you are done?
You can look to answer this question in a couple of ways.
If you’re a design idealist, you may be thinking something along the lines of “the work is never done”, and there’s always something that can be made better, or there will be changing needs of the user for which we will need to provide.
If you’re more of a pragmatist, your focus might be delivering the minimal viable product, with your focus on the minimal. What is the smallest amount of work that can be done to move things forward and make things slightly better than they were before?
Business analysts and developers will set their definition of done for a given ticket using the agile ceremonies at their disposal and create the set of criteria that must be fulfilled before the ticket is considered complete.
Without having all of the requirements and specifics to hand, the designer’s role and progress to completing their design work on a given task are obfuscated by the nature of design work itself; the discovery and exploration involved in the design process to uncover what it is you should be building for your users.
Every block of stone has a sculpture inside it and it is the task of the sculptor to discover it.
~ Michelangelo (not the turtle)
What do you need to understand as a designer before you can set your criteria for you to know when your work is done?
Are you building a product or a service?
In reality, the nature of business — and the role of digital product design attached to it — requires things to be finished at some point, especially if you’re creating a product. The parallels with the real world still exist when it comes to shipping products; once the product is completed, it is shipped and available to customers. Yes, in the digital world we can improve upon it and iterate based on how people are using it in the real world, but for the business, it can be seen as something that has been completed, and to spend more time on something that is already out there being used has diminishing returns.
Unfortunately, the same kind of expectation can be held against a digital service. A quick distinction is probably needed here… I see a digital product as something which can be designed, implemented and released, and can be bought again and again by consumers with little changing over time, whereas a service is an evolving piece of software that will likely launch with core features and will improve over time to meet the ever-changing needs of its users.
In either of these scenarios, whether you’re building a product or a service, you will have a goal that you are aiming for to be able to say that it is ready for release; this could be a beta version with only a core set of features, or a fully-fledged product with all of the bells and whistles.
Do you work alone or in teams?
Working in teams tends to provide a framework within which you can set your own definition of done, and find a consensus within your team of what that means for you. If your work doesn’t reach that definition of done in your given timeframes, it will have a negative impact on your team and its ability to deliver overall. The constraints provided by the combination of timeframes and your definition of done make it easier for you to break up your work into manageable chunks that can help you keep up your momentum (or velocity if you want to use agile terminology) of work.
If you’re working alone, whether on a side project or running your own business that focuses on a digital product — and I’m leaning heavily on my own experience here — it can be difficult to set your sights on what done means to you. I have always had the temptation to continue working towards perfection when your product is already “good enough” and it should already be out there in the hands of your users. Again, much like when working in a team, defining what done looks like, and sticking to that will help you to deliver your products into the real world.
How to set your definition of done for design
Depending on your situation, whether working solo or in a team, or building a product or maintaining a service, there are still some guidelines I would recommend that you follow to know when you are done as a designer and help you to draw a line under one piece of work so that you can move on to the next and keep moving things forward.
Set your criteria
As part of understanding the work that you need to do, and that you need to reach an endpoint for a developer to pick up and implement the work you have done, you can define the amount of work you need to do in each specific instance.
Understanding what the developers need from you to complete the work, or what a business analyst may need to write the ticket and acceptance criteria, will be the main factors that help you to set your goals at the outset.
Do you need to have tested your work with users and for the findings of that research to have been acceptable before you are happy for developers to pick up that work? Do you need to have ironed out all of the possible bugs and loopholes through multiple iterations before you’re happy for that to go into development?
Understanding how your organisation works and what they value in terms of delivering to their users will be a useful guide on how to set your criteria. However, you should not use this alone…
Adapt to suit your team
Maybe your team is small and low on budget and as a result, you have to move quickly to deliver things into the hands of your users so that you can evaluate the impact of your work, and quickly iterate on those to help fix the experience of your users. Or maybe your team just likes the “move fast and break things” approach to get real data from real people using your product.
Perhaps you have a larger multi-disciplinary team which includes user research capabilities, meaning that you can iterate on your design work to a point where you know what will work best for your users before you even go into development.
These scenarios represent different ends of the same spectrum, and where you are upon it will help you to determine what your definition of done as a designer should look like.
At the end where the speed of delivery and putting things in front of people is paramount, your live product is your sandbox in which you are playing, and your definition of done will be less detailed as there is less for you to do before things will go into development. At the other end of this spectrum, there is more likely to be a lot of iteration, testing, and proving that the designs work as needed before they go anywhere near the developers to build and deploy.
Of course, there is everything in between these two extremes, and part of your role as a designer will be to understand where you fit in that spectrum, and the amount of specificity required from your design outputs will vary accordingly. By understanding your team, you can adapt your definition of done — and the work needed to get to that point — so that it aligns with the needs of the team as a whole.
Iterate on your process
Once you have found a method or framework for setting your definition of done, you should always bear in mind that circumstances may change, the dynamics of the team may shift, or perhaps your role may take on a different meaning or change in terms of responsibility.
One thing that we can always be sure of is that things will change over time, and that will include how you do your work and what your team may need from you. Your ability to iterate should already exist and be well-practised in your line of work, and this concept of iteration can be transferred to your process and how you work with your team.
Be sure to revisit how you do things and how you define when your work is done whenever it feels like things are becoming misaligned, or maybe just to check in on a regular basis to keep yourself familiar with how you should be working and whether you need to make any adjustments.
You have to be willing to evolve the way in which you work so that what you do and how you do it can be integrated as successfully as possible within an ever-changing workplace.
Originally published at https://westleyknight.com on November 10, 2020.