Disco Fever: How we're delivering user-centered products at the Center for Medicare and Medicaid
The room we kicked off our Discovery and Framing in, complete with the research we inherited from a previous team
Background
At Truss we’ve been flexing our Discovery and Framing muscles, ensuring that we allot adequate time to truly understand the problem before iterating on potential solutions. It’s a practice that helps teams get onboarded to the problem, start meeting with real users, and start developing relationships with our clients. Sometimes, it can be a little challenging for our clients to understand why we do Discovery and Framing and the value in pausing development for six to eight weeks in order to really understand why we’re doing the work in the first place.
Once you get past the stakeholder skepticism, taking the additional time at the beginning of a project to really understand the problem helps you and your team deliver the right value in the end.
Getting Started
At the Center for Medicare and Medicaid (CMS) we began our Discovery in Q3 with a high level understanding of the problem: moving through application governance is a slog and no one has any data on what’s going on. Our initial thoughts were “does this really need to be a new system?” “is this a project management problem?” and “why build a tool on top of a creaky process?” With our questions and assumptions logged in a spreadsheet, we dove into onsite research for a six week Discovery and Framing with the client team.
Our Discovery began with a weeklong kickoff with representatives from the client and all disciplines: engineering, product, and design. Our Truss team had a Product Manager, Engineering Lead, two UX Designers, and a couple engineers. From the client side, we had a Product Owner and Business Owner from CMS. At Truss we strive to always have a balanced team, and although Discovery and Framing is often a research process, without deployment there are no digital improvements.
By working shoulder-to-shoulder as a team, we can evaluate the problems shared by our users and stakeholders and identify the right approach based on what’s most valuable from a product perspective and actually feasible from an engineering perspective.
The kickoff was onsite and remote-friendly, allowing for the rest of our team to join via Zoom. Truss is a distributed company, where our offices are a sprinkling of homes and coworking spaces across the US, so it’s important for us to always be remote-friendly, even during onsite workshops. In order to be remote-friendly, we lean heavily on tools like Miro and Google Docs and encourage workshop participants to bring their laptops – this allows folks who are remote to lead workshop sessions as well.
Conducting the Research
Our goal at the end of Discovery Kickoff was to have a better grasp of the problem and a list of names and contact information of users and stakeholders to continue having conversations.
Kickoff morphed into a whole month of generative research, conducting interviews and contextual inquiries with our users. As we began synthesis, Miro became an endless wall of colors and insights, which helped us as a distributed team prioritize our findings and identify where to focus our efforts. The initial synthesis of raw user research was done internally at Truss, in order to preserve the anonymity of our users, and then insights were shared back with our client team so that they had an understanding of how the work was progressing and had an opportunity to influence and color the insights further.
A small segment of our Miro board at the end of Discovery and Framing with CMS
We shared back user need statements to help frame the rest of our work, achieve alignment, and ensure our product decisions were rooted in what was best for our users. At every step of the way, our client knew what we were doing and why, and gave us the autonomy to continue learning about their users and organization.
Framing the Problem
When we felt like we had a good grasp of our users and their problems through our research, we shifted into Framing. Framing is an opportunity for the project team and client to synthesize our research findings, refine the problem space, and align on the priority of the problems we’ve discovered. You can think of it as the first step in identifying what a team might tackle first.
Framing is often a series of workshops, where we leverage different ways of taking all of our raw data and visualizing it, called synthesis. Workshops were held remotely and done collaboratively through pen, paper, and Miro. Some methods our team found useful were: generating How Might We’s tied to user need statements, plotting potential solutions in a 2x2 (feasibility vs value), scenario writing, and holding a Design Studio with our client. After each workshop, a smaller group of representatives from design, product, engineering, and delivery would come together to synthesize results and identify next steps for the product strategy.
Our first round of problem prioritization, which helped us narrow in on user needs to address.
Framing gave us the foundation we needed to really understand where our team needed to focus. For the remainder of our project, we often go back to our framing artifacts to ensure we’re moving in the right direction based on this foundational research.
A few user need statements we continue to reference and refine throughout our project
Continuous Discovery
We are now in continuous Discovery, running experiments with our users every other week to validate our prototypes and product direction. The process of continuous Discovery helps our team prove ideas early on in the process, so that we don’t spend time developing functionality that has little to no value for our user base. A part of continuous discovery is also continuous alignment, where we pull our client into research sessions, ideation, and synthesis to keep them abreast with our research. By involving our client at every step of the way, we are equipping them to not only understand the progress of our work, but also enabling them to make decisions that are rooted in research. Whatever passes Discovery then gets pulled into development and eventually is released to users.
Our testing cadence has gotten us in front of users at least once every two weeks, some weeks (like this week) two different prototypes in one week. All sessions have been led remotely using Zoom, with one to two note takers capturing quotes for the duration of the session. After every round of testing, we look through the notes, affinity map patterns, and then identify insights as a team. Our Insights generation has been cross-functional, with teammates from engineering, product, delivery, and design present so that context is shared. This allows for our engineers to push back on product ideas or come up with simpler alternatives, rather than be dictated to build a feature a certain way.
We have found that our team operates best when we’re all aligned under a similar goal: what will benefit this user the most and how does this align with CMS’s organizational strategy?
We are regularly going back to the insights captured from Discovery and Framing. The artifacts have not only become a helpful way for our team to refocus on real user value, but also a great onboarding tool for new team members and stakeholders. Ultimately, the time invested up front has saved us more time in Delivery because we’re making product decisions based on validated user goals.
That said, Discovery and Framing isn’t just one and done. Once we tackle a new problem space with CMS, we’ll likely kick off another multi-week Discovery and Framing because we’ll be focusing on a different set of problems.
If you’re in the process of kicking off work with a client or internal product team, allow you and your team the time and space to really understand the problem space. It may feel like you’re putting off the “real work”, but in reality “work” starts as soon as you begin learning about the problem. As designers, it’s our responsibility to ask questions, validate the problems we’ve been given, and build the right thing for the people who need it most.