Timeboxing design: knowing when to stop
How often have you heard that design takes too long or a deep sigh from stakeholders when discovery is mentioned or stakeholders say, "Do we need to do discovery when we know what the problem is?"
I often hear things like this, leaving designers in a difficult place. The discovery process is critical to de-risking and designing great features. A designer's ability to timebox design is key, as it enables designers to de-risk features quickly. By timeboxing, I mean giving yourself a fixed amount of time to go through the discovery process and develop potential solutions.
A well-known example of Timeboxing design is doing a design sprint. It's a great way to show the value of design quickly, but sometimes you can't do a design sprint due to people's availability, timing, or maybe there are better approaches for the outcome you need.
Why timebox design?
Timeboxing allows you to get to a potential solution at speed. It's a great way to show how going through the design process can save time and avoid building solutions that don't work for users. Which in turn demonstrates the value of design to stakeholders.
Timeboxing doesn't mean taking shortcuts. It means working out the essential activities you need to do within the time you have. You must plan your time and communicate with people in your team:
The planned activities - what are you doing?
Timelines - how long are those activities going to take?
The outcome - What is expected after an activity is complete?
The above forms the basics of a plan; also, remember to add points to check in and collaborate with Engineers and Product Managers to take them along the journey and ensure alignment throughout.
How do I timebox design?
Firstly you need to know the problem you want to solve and a timeline. An excellent way to set a timeline is against the sprint cadence of the team. You then need to assess what you know and what questions need to be answered to solve the problem. The next stage is to work out how you will answer your questions within the given time. You may need more time, and the sprint cadence is insufficient, e.g., 1-week sprints. If this is the case, create a plan around the minimum time you need with outcomes aligned to the sprint cadence. For example:
By the end of Sprint 1: initial ideas and potential solutions ready for validation
By the end of Sprint 2: Solutions validated with users
Once you have a timeframe, you can look in your toolbox to determine which activities will give the quickest result with the time you have. Refer to previous research that may have been previously done so that you can focus your research on unanswered questions and gaps.
All this information should be enough for you to start planning how to solve the design problem; once you have the plan together, communicate it to the wider team. This is so that you can set expectations for the Product Manager and the wider team.
My preference was to use the same tool as the engineers so that I could give updates in the stand-up, giving visibility to the broader team. Sometimes this isn't possible; a solution would be to create another kanban board that shows your work activities and progress; make sure in the stand-up, you run through what you are doing as a designer.
How do I know when to stop designing?
You will never be 100% certain of a design; the best way to understand if it works is to release it. As designers, it's easy to get into a trap of continuous tweaking of a design. Discovery aims to de-risk a solution as quickly as possible, so ensuring that the design is:
Viable and can be built by the team
Meets the business requirements
Tested with users
Once you have validated your design with the above, you can spend time tweaking and refining it. I would timebox and limit so you don't end up in a loop of continuous tweaking. Once it's released, there will be more tweaks and improvements you will need to make, but the difference is that you will have even more data to guide your design decisions.
Timeboxing design can be challenging, and you feel like you are creating shortcuts that devalue design. Still, I think it's the opposite where you can show how design can be adaptive, quick and agile. Planning your design process around timeboxed milestones and check-in points stops you from going down rabbit holes. It ensures your work aligns with the team and, therefore, the business priorities.
