Using Archetypes to Guide Cloud Adoption
Date
August - December 2019
Team
Ian Petruziello
Anke Stohlmann
Amanda Kennedy
Methods
- Surveys
- Interviews
- Archetype Development and Implementation
My Role
- User Researcher
- Service Designer
The Opportunity
How do you use archetypes that don't just sit in a drawer but build trust and drive change?
Summary
CMS is in the process of adopting cloud infrastructure across the agency. This adoption involves technical, cultural, and behavioral shifts at tremendous scale for its workforce, which has ripple effects across the services that our government partners provide to its 149 million beneficiaries.
In order to get there, we need to equip our government workforce to not only endure but enable cloud adoption. How do we support the end users of this cloud adoption effort who have a range of experience? How do we help the users of our workforce grow from novices to experts as the navigate the same internal government services as users with advanced skillsets? How do we move the needle?
It starts with archetypes. By creating, socializing, and applying archetypes to design and development, we can use archetypes to facilitate cloud adoption over time. This timing piece is key. Archetypes don't solve today's problems — archetypes sustain our government partners, teammates, and end users across longer time horizons to create more sustainable and effective change. Here's how we did it.
Approach
Step One: Identify descriptive attributes.
We accomplished this by conducting interviews with stakeholders, end users, and service providers. With our interview participants, we used a Mural activity to brainstorm, define, and categorize attributes needed to operate in cloud environments, to get a better sense of patterns and themes of the teams we were serving.
Step Two: Visualize attributes across a scale.
Once we understood more about these very disparate user groups (who were, in our case, internal to the agency), we created cloud competency attribute scales -- as this is the most meaningful measurement in how we need to differentiate our services. In other lines of work, for example banking -- this might be ‘financial literacy for end customers’. Whatever it is, make sure it will later help dictate a meaningful range of the kind of system or product you’re building.
This let us as researchers efficiently group common combinations into a first pass of archetypes -- which we called "proto-archetypes".
Step Three: Measure the population.
To test our proto-archetypes we needed to understand the developer team population at large within our agency. We developed a survey that we sent out to developer teams who are already in the process of onboarding to the cloud. The attribute scale helped us easily map the criteria to survey questions. One of our government product owners established credibility in our survey by giving teams a head's up that we would be reaching out them individually. Relationships are incredibly important in a government context, so we were grateful for that support. Once we received a significant number of responses, we then mapped survey responses back our attribute scale so we could see at a glance where developer teams landed in terms of their cloud competency.
Step Four: Identify needs of common groups.
We also set up qualitative interviews with survey participants who opted in to participate further research. These interviews helped us to dive deeper into grouped user type needs, approaches, and development practices.
Step Five: Get the full picture.
After conducting synthesis across both methods, we iterated on our proto-archetypes. We used a matrixed approach, with two our dimensions: cloud competency —and application origin. Per archetype, we paired the attribute scale from the survey with the qualitative insights from the interviews to give us a full picture. We also used multiple illustrations per archetype to remind ourselves that our users are not really each one person, but made up of large teams, some with over a hundred members due to the complex government systems that they work on.
Step Six: Socialize across the CMS Cloud program.
If you take anything away from this portfolio piece, it is this: socializing your archetypes is key to driving change. Archetypes do no good sitting in a drawer -- and bringing them to life as powerful artifacts of change within an agency requires trust.
We achieved this stakeholder trust through socialization, and co-ownership of the artifacts.
Step Seven: Use archetypes to drive service strategy and offerings.
These socialization efforts fuel the trust needed for our organization to adopt archetypes in design and development.
We also socialized our archetypes beyond the stakeholder level so everyone in our organization can have a sense of co-ownership over them.
Our archetypes needed to be visible and findable. In this current moment, where many of us are working remotely, we can't just stick our archetypes on a wall in the hopes that our stakeholders will notice them. We need to think strategically and creatively about how we socialize our archetypes.
For people onboarding to our project, we introduce the archetypes during one of a handful of our regular onboarding sessions, "Overview to Human-Centered Design". As a result, the archetypes are foundational to our organization's understanding of our users.
Outcome
Archetypes have helped the CMS Cloud program create...
-
Training pathways to nurture cloud competency.
-
Cloud offerings to support a range of needs.
-
Support models to guide decision making.
Our long-term vision is to establish specific service pathways through onboarding per archetype. This vision will take time to come to fruition, just as digital transformation will. We are making strides toward this effort based on the examples I have shared.