2020 User Research Summary
- Matthew Hall
Research source: github.com/bcgov/Common-Components-Wiki
Overview
The Common Components teams’ research hypothesis is that we can reduce the time and cost of delivering digital products and services by making it easy to find, onboard to and use components like code and microservices that solve common problems across government. We know that there have been previous attempts at this work in B.C. and elsewhere in the world, and that not all have been successful. We think that by taking a user-centered approach and understanding our users’ needs and journeys, we can design Common Components so good that technologists in BC prefer to use them.
Who are our users?
We started our user research by identifying and interviewing users of Common Components. We confirmed that our users are:
Technologists like developers and architects who help select technology and build digital products services for government.
Service/Program Owners who need to deliver part of their program or service digitally.
Designers who design and prototype new government services and applications;
Procurement/Contract Managers who shape procurement processes;
British Columbians - the people and businesses that use online government services.
Technologist user journey
Discovery Research
In January 2020, the Common Components Team began a Discovery Phase to understand our users and the problems we’re trying to solve with Common Components.
To that end, we conducted extensive user research with technologists, designers, service/program owners and others in the BC Public Service. We’ve also reviewed previous research, analysis and service design work to avoid duplicative work. We also used prototyping to learn about users’ needs and test for desirability, feasibility and viability.
Who we interviewed
In total, there are thousands of public servants in B.C. who fall into one or more of our user groups. To make user research and outreach more manageable, we started our research by focusing specifically on teams located around us in B.C.’s Exchange Lab, along with other teams from across government connected to the Exchange Lab’s community.
To date, we’ve conducted nine interviews with teams from the five Natural Resource Ministries, the Ministry of Health and the Ministry of Citizens’ Services. For each of these teams, we met with product/service owners, developers, architects and designers to understand their product development journeys and the related technology choices they make along the way. If you’d like to participate in our ongoing reasearch, please reach out to our team.
What we learned
Based on our research, we came up with a set of design criteria that should guide our work on common components. These principles will guide our work moving forward.
Common Components should:
Be easy to find. Teams struggle to find reusable components today, and wanted an easy place to go to find BC’s common components. Notably, teams often go to Google first to find reusable components built by other teams in BC, so search engine optimization (SEO) is also important.
Have simple, plain-language descriptions. Teams need simple, plain-language descriptions of common components, including key features. This should be easy to read and understand for everyone - not just technologists.
Be easy to onboard to. Once they’ve evaluated components, teams look for good developer documentation with clear instructions, sample implementations and even a sandbox to test a component. All of this can remove friction and facilitate self-serve onboarding.
Have published usage information. Common components aren’t common if they aren’t being used. Teams like to see usage data, like the number of services onboarded or the number of transactions. This helps inform their decisions about whether or not to onboard to a component.
Include user testimonials and reviews. One of the first questions teams ask when evaluating components is whether their peers like it or not. Having an easy way to see reviews and testimonials from existing users will help teams decide whether or not to onboard to a component. In absence of this, technologists have been polling a “shadow network” of knowledgeable architects to inform whether or not to onboard to a component.
Be supported, with clearly articulated uptime and support information. We learned a lot about how much teams dread “shelfware” software that isn’t supported. Before they onboard to a common component, they want to know that someone is supporting it. Teams running critical apps also care deeply about uptime and SLAs.