3 Ways Design Sprints can speed up your product development
When talking about sprints, people usually think of development sprints, something project managers have to implement for their developers, but you are only getting half the process. Sprints are a way of managing and orchestrating product development, and product development is more than just coding, it’s also about Designing and Usability.
Developer Sprints generally last between 2-to-3 weeks, if we include a week of testing. Design Sprints should go for five-days, Monday to Friday. In these 5-days, designers and UX experts have the opportunity to deliver customer-validated iterate-evolved designs to developers, decreasing the chances of severe pivoting that will disrupt your development and product. Here are 3 ways Design Sprints can speed up your product development.
1 Design Sprints should be a Week long
The more meaningful iterations you can fit into your design sprint, the more refined your concept will become. Being able to build a structure and framework to be able to tap onto test users, design, refine, and deliver a more polished prototype that is validated with certainty, to be queued up as User Stories for the development team.
This is a methodology conceptualised and practiced by Google Ventures, to be able to bring concept to production quicker, giving the design team five-days to answer critical business questions.
“Working together with companies in a sprint, we shortcut the usual endless-debate cycle and compress months of time into a single week. Instead of waiting to launch a minimal product to understand if an idea is any good, teams get great data from a prototype. The sprint gives these companies a superpower: The ability to build and test nearly any idea in just 40 hours.” (source: Google Ventures)
2 Design Sprints are natural collaboration conductors
Design Sprints should encourage collaboration between members of your design team, as well as with managers of other teams. From writing down User Stories on sticky notes, to brainstorming on the white board, it allows for free-flow thinking.
Don’t restrict collaboration but rather nurture openness from everyone. Have technical people sit in on design sprint meetings, from UX design and prototyping, to how tests would be conducted with users during the validation stage of the week. Thinking outside the square earlier on, and flagging issues that designers would not have thought of, thanks to more collaborative discussions will lead to a greater chance of finishing the sprint earlier (in the case of the first point, in the 40-hour week).
3 Prevent Design Scope-Creeping
User Stories need to be self-encapsulating, and not have strong dependencies to other User Stories where possible. This ensures that everything can be measured and done modularly, without dependcy-cycle hell.
In order to prevent scope creep, during the sprint planning, ensure that any design deliverables take into account only what its purpose is within the User Story, and don’t change anything else.
I like to think of it in as time-travel in a way, if you touch something, there is a butterfly effect. If your design adds a new menu, that may affect the architecture of the app for developers.
Point being, designers may not always know what their designs, whether UX or UI may cause, and having developers sit in, and either on-the-spot provide technical validation, or flag for further investigation, it means we assume less and are more accurate in assessing that no other technical changes that will take longer to do, is derived from design planning.
Originally published at www.doronkatz.com on January 30, 2016.