Enterprise Design Sprint

Peter Zalman
Enterprise UX
Published in
4 min readOct 26, 2017

My actual Design Sprint practice started with skepticism. I believe, that in an enterprise environment, we are facing complex problems that just cannot be solved on the spot. But what if the goal of Design Sprint is not to provide a definitive solution or even hurry things up?

One of my honest motivation to embrace Design Sprint technique was the current adoration of Startup techniques in the Enterprise world. Accelerators, Startup Pitch Decks, Hackathons and Innovation competitions…and yes, Design Sprints.

As designers in enterprise environment, we should embrace the change and all attempts for innovation. We should offer our craft and skills, empathize with stakeholders motivations and steer the design process to the right direction — a direction matching user goals and establishing the balance between technological and business constraints.

Just NO. If you want a Design Sprint, go to Google.

My intuition is also telling me, that Design Sprint is a great technique to replace a classic corporate workshop format, where a group of people is locked in a room and shoot questions on each other. In this setup, there is only one overarching theme in the air — Just say what do you want, then say who needs to do what, and let’s code.

A classic meeting-room workshop replaced with collaborative activity.

Goals

Before introducing the concept, it is important to set the honest goals for the organization. In the Startup world, the fairly realistic goal of a Design Sprint is a shortcut to learning without building, in terms of coding. This learning increment covers the end-to-end user journey and can incorporate realistic real-world constraints including preliminary user research and subsequent validation with real users. The outcome is most likely an artifact capturing the future user experience — UI Prototype.

In large enterprises, the projects are rarely initiated with a simple bright idea or elevator pitch, that immediately goes into validation or execution phase. This process takes months and there are many stakeholders involved until the project idea reaches the green-light stage. We might need to work on a new reporting function or other areas that have a significant impact on people’s life and productivity, but they have very little known GUI to sketch on a whiteboard on-the-spot.

The initial enterprise project discovery and governance create a handover moment, since the actual team accountable for designing, developing and shipping the actual product was not involved in all of the initial negotiations and preparation work.

The goal of Enterprise Design Sprint is to use established set of design techniques to connect a multidisciplinary team accountable for product design and development to reach a common understanding of the problem from the perspective of an actual user.

Form

I adopted the 3-days Design Sprint workshop format, and I found this to be a reasonable expectation for a distributed global team to co-locate. The quality of the outcome is directly related to participants selection, and the goal here is to have a true multidisciplinary participation - Engineers, Architects, Users, Team Leaders, Operations Managers and other key decision makers. They all should gain a common sense of ownership.

A 3-ay Enterprise Design Sprint Schedule.

The key of a successful Design Sprint workshop is customization. I tailor the detailed agenda and design techniques for every instance based on the project stage, audience and specific stakeholder goals and expectations.

For the skeptical voices — what was the outcome of the Design Sprint outlined above? Did we actually “designed” a product in 3-days?

With Lighting Talks, we shared individual functional angles and included external perspectives of people from different teams and companies. We created Empathy maps to identify areas and inform our user research objectives. In this case, we had the luxury to have actual users on-site, so during the real contextual inquiry and user research interviews, we learned about actual user pains and goals. We synthesized the research findings into a common artifact capturing an ideal experience with the future product— User journey. On the third day, we validated the product impact with another round of interviews and established actual SCRUM roles. We started with the actual iterative design process the week after, all aligned to same objectives and sharing a mutual experience of initial cross-functional teamwork collaboration.

Design Sprint participants interviewing users on the spot.

Conclusions

I believe Design Sprint can be successfully applied in enterprise environments, but as any other design technique, we need to adapt its content to match our goals. Design Sprint is a great alternative to replace unproductive corporate meetings that involve more than 3 people and takes longer than 1 hour, such as “Random Workshop” or “Kick-off”. The great variety of various UX Design techniques provide us almost endless possibilities how to customize the workshop agenda for common 3-day structure — Learn, Define and Validate.

--

--

Peter Zalman
Enterprise UX

I am crafting great ideas into working products and striving for balance between Design, Product and Engineering #UX. Views are my own.