By Russ Unger, Chief Experience Officer & Brad Nunnally, Senior Director of User Experience
Read Part 2 and Part 3 in our Applying a Flexible Discovery Process Series.
A recent customer in the international security space expressed challenges with understanding the readiness of their personnel, equipment, supplies, and training across their combined network. Their current approach requires manual retrieval of information from across multiple locations, multiple individuals, using low-tech and analog systems. That is, they make phone calls and send emails to track down information, analyze it, and attempt to make informed, mission critical, decisions on data that isn’t produced in real time.
We were determined to showcase how we approach, understand, and solve complex challenges using Discovery and Human-Centered Design practices in an Agile-like methodology to better identify the issues afoot and build a strategy to modernize their systems.
Modernization efforts like this are exciting and provide opportunities to create efficiencies that may not have been previously considered. They can evolve over the period of performance for a program. However, in the case of this particular customer, schedules and world events afforded us only 10 days to respond to the challenge with a loosely defined problem.
Discovery Kickoff
We started our Discovery process with data collection. We held investigative and generative interviews with stakeholders and proxy users, providing us with deeper insight into the operations of the organization, how its users work, and its current challenges.
The information and insights gleaned from the interviews informed the creation of our Role-based Empathy Map, which is a lightweight persona focused on a specific role. This artifact captured the user role of the Readiness Analyst, and provided insight into the ways they are currently working, the challenges they have, and how they navigate those challenges. Whenever new requirements materialized, we validated against the needs of our Readiness Analyst to ensure we were focused on the most meaningful requirements.
We also needed to explore the definition of “readiness” within the context of the Readiness Analyst, surfacing how we would report information and track metrics within the prototype. Through this discovery, we were able create a shared definition and understanding:
The metrics, from 0 to 100% that affect: an individual’s ability to perform, the equipment’s ability to operate and function, the availability of and access to supplies, and the training maturity and competency of a team. These metrics, used singularly or collectively articulate readiness.
This mutually understood definition allowed us to start with an accurate depiction of the scenarios affecting readiness and helped us to scope a 10-day Discovery plan. The plan focused on prototyping limited, meaningful functionality that would allow the organization to envision a future state of working with their data in real time across the network to assess its organizational readiness.
Discovery is Flexible
We tend to view Discovery as customizable 8- 12-week engagements (sometimes longer) that ensure the right amount of rigor is in place to deliver decisional information with the highest degree of confidence. Discovery doesn’t have to always follow that formula – it can be flexible and responsive to the need. In this case, because our customer was under an extreme time constraint, our team focused on just enough detail and information to rapidly prototype a compelling vision of what we could deliver over the course of an engagement.
Once we understood our high-level goals that we would be pursuing, we began to co-create user stories with our proxy users, and then prioritized them to help shape how we’d tackle delivery. We used a modified Scrum approach, with frequent Sprints to track our progress. We utilized Mural for project planning.
Our Customized Approach
Once we established our priority of key Epics, we scheduled frequent working sessions with our proxy user—sometimes daily, sometimes multiple times a day, and asynchronously when schedules were conflicted. Everyone understood the urgency of the Discovery Sprint, and our priority was to continue to move on tasks instead of waiting for feedback.
Early in the process, change is relatively inexpensive, thanks in part to starting with pencils and paper before moving into a no-code Figma environment. The team was flexible with any and all changes; we remained open to new and big ideas; and we nimbly re-prioritized the work as needed.
Next Up: Rapid Sketch Prototyping to Explore User Stories
Our working sessions were used to gain clarity against requirements, validate our assumptions in design activities, and thoughtfully plan interaction and opportunities to surface data in a way that would be helpful to a user. As we worked though these sessions, the narrative for our prototype was starting to come together what would allow us to communicate the value and potential impact of the prototype.
We had quickly amassed enough information and feedback that allowed us to move quickly, iterate, and plan for more detailed design sessions. More on rapid sketch prototyping in the next article in our series, coming March 2023.