There are a lot of ways to start a project. Most of them do nothing more than set up the project for failure. As decades of software development and design methodologies have proven, there is almost no scenario where upfront planning can solve future problems. However, there is a framework that can reduce risk significantly. That framework we refer to as a Deep Dive. (To better understand how Deep Dives work, watch the video below.)
What is a Deep Dive?
In order to understand the problem/s we are trying to solve for our clients we need to know as much as possible. A Deep Dive allows us to dig into the problem and uncover details that a requirements gathering meeting or website brief would not generally describe. The objective of the Deep Dive sessions are to develop stories, map timelines, determine significant touch points and identify key ‘actors’ (personas) that will ultimately become the backbone of the customer experience. This is mostly a strategic planning and Design Thinking exercise and not just a scoping exercise, although it will certainly provide the basis of a thorough scope.
What does the Deep Dive achieve?
Stories and story arcs are the brains way of making sense of the complicated. Translating the solution into a story via the ‘Deep Dive’ sessions is a powerful way to simplify the experience map and provide a design and development pathway. Connecting these customer stories to practical and emotional triggers generates a roadmap that becomes the path for all future design and development work.
What is the structure of a Deep Dive?
The Deep Dive is often divided into two separate sessions with about a week in-between for additional research, assumption testing and reflection. These dual sessions are based on a tried and tested structure but because each project is different there is always some customization – it’s a framework not a checklist. Remember too that our primary business is designing UX/UI solutions for apps, web products, and the public websites that support those products; this structure might not apply to all project development cycles. The dual sessions also give us the opportunity to define the vision of the product we will eventually build. We describe this vision as a story so that is can be clearly understood.
How do you prepare for a Deep Dive?
We ask the client to prepare for the session by answering a series of survey of questions designed to get some preliminary business information, for example: What is the problem you’re trying to solve? Why does this problem need solving? Does your audience value a solution for this problem?
We also send clients a single page “Rules of Engagement” document which is intended to coach them on how the sessions will be run and what their team’s involvement will be. Keep in mind that many of our clients won’t have experienced this type of Deep Dive so preparing them on etiquette is essential. Remember, this is not an opportunity for the client to “escape the office and brainstorm with some creative folks”. It’s hard work and needs full attention from the entire group.
What’s the agenda for the first session?
The agenda will change slightly from project to project but below is an outline that works for most engagements.
- Rules of engagement
- Vision, values and objectives
- Audience Analysis (Who/Do, Put Your Money Where Your Mouth Is and Empathy Map exercises)
- Story Arc(s) (…of user journeys and touch points)
- Snapshots (…of key experiences and touch points)
- Next Steps
What should you do in the first session?
The first session normally starts with a reminder of the rules, a walk through of the agenda and some quick mental loosening-up exercises. Once this is complete we dive into understanding the vision of the project and the underlying business. This is often framed by questions like “When this project launches and is covered by [insert name of industry magazine here], what will the magazine cover look like and what will the headline be?” We’re looking for an overall visualization of a successful product here, not a mission statement or a positioning tagline. I’m over-simplifying this part a lot, but you probably get the picture of the types of exercises you might do.
Once we’re done with vision, we turn our attention to the audience. This generally is the longest part of the first session. We have several tools that help craft the persona types and give us insight into the stakeholder’s needs and wants. The most useful in a Deep Dive are the Who/Do exercise and the Empathy Maps. Very often there are internal customers that need to be considered and understood. The Who refers to the role of the actor and the Do refers to the actions/thoughts/emotions they experience.
Story arcs and high-level user journey’s follow the audience development. The idea here is to understand how, where, when and why the users/personas interact with the business and potential product or service. This is not a functional user story list. These are very high level ‘epics’ that describe the typical day in the life of a user/persona. A lot of these epics can be used later to create the more specific user flows but for now we focus on the generalities. We’re also probing into the emotional content of the user’s experience at this stage to get an understanding of their core motivations.
We will construct stories based on vision and not on technically feasibility. We will use metaphors and storyboards the way concept cars or architectural renderings are used to sell a vision.
Almost all this work is done on whiteboards and post-it notes. It’s a very inclusive process with 100% engagement of everyone in the room. There are no spectators.
What do we do immediately after the first session?
We send the client a Capture document that incorporates pictures of all the white-boarding, post-it notes, and anything else that was created during the day. The page layouts looks like a photo album with pictures on one side and typed notes on the other. This document often poses several questions or identifies gaps in our knowledge that need to be answered or researched.
What do we do between sessions?
The week (sometimes longer) of time between sessions is for us to digest the information we have received and do some of our own research. We check any assumptions discussed in the first session, we do some preliminary competitive analysis, and when necessary we’ll call several potential customers and ask them questions. For example, when we did this for Medlert we called a dozen users to double-check some assumptions the client had presented. We were able to show there was some discrepancies in their predictions and we were able to adjust our understanding and the scope accordingly.
What should you do in the second session?
The goal of the final session is to frame the MVP (minimum viable product) for this part of the project scope. We want to be able to walk away with a very clear idea of the project objectives and deliverables and then map those to time, money and team members. Most of this time is spent asking questions like, “Last time we met we discussed [insert idea or issue here], since then we’ve found out [insert insight here]. Can we discuss this in more detail so we can figure out how that affects the product design?”
What should be done after the final session?
The project team meets the day after the second session for a final debrief and discussion on scope. This normally takes about an hour to clarify scope, scheduling and budget. The PM then writes up the SOW (Scope of Work) and MSA and sends it over to the client for approval. If this is approved, the SOW becomes the contract to start the design and development of the product.
The Deep Dive cannot answer every question and provide a flawless roadmap but it can set a stronger foundation than the traditional requirements gathering process does. We’ve delivered over forty Deep Dives in the past 2-years with astounding results. Every Deep Dive has generated a design and development roadmap that has gone on to become a successful product or website launch. Only one company didn’t proceed with the product development after the Deep Dive. This was because it was determined that the product would not be able to generate sufficient revenue.