Introducing user experience to an open community
OpenStack is an open source project that enables enterprises to provide cloud services within their firewalls. Think AWS on your own infrastructure. Companies contributing to OpenStack include Redhat, Intel, HPE, IBM and Cisco. This is a story about how a multi-functional team of user researchers, operators, designers and project managers made user experience a priority within an open source community.
This is beyond design and extends into building user-centered culture within a developer-driven open source community by building credibility, community involvement, design tools and governance. To add more complexity, this story is also about navigating internal corporate politics that may conflict with community goals.
The first step was to build credibility within the community by providing something tangible that could be implemented by the developers. The team then began standardizing by creating personas and design guidelines which have been included in the official OpenStack developer documentation. Finally, the combination of credibility and standards allowed the community to quickly build effective interfaces (cadence).
The existing portal design had failed to address priorities including content needs and using controls that were more appropriate for production environments.
The team proposed alternatives that simplified workflows by addressing eighty percent of use cases while allowing operators to easily add more sophisticated options after completing the workflow.
In addition, we also addressed information needs for new users while not burdening advanced users with content they do not need.
Finally, design and research aren’t enough. You also need to communicate your efforts in order to gain visibility and build momentum.
Do your customers even want your proposed product?
A Director of Product Management noticed that teams were developing before establishing whether customers wanted the product. The PM’s solution was to adopt Amazon’s approach to identifying product strategy by building a fictional press release for a new product and vetting it with both his peers and customers.
To support his approach, I created a research protocol for a remote, unmoderated study hosted in UserTesting where customers were asked to read the press release and answer a series of questions about the intended value of the solution, whether its value resonates, intended customers, and what information was missing.
The responses were posted as individual stickies in Mural so the cross-functional team could cluster them into different themes.
How would your customers prioritize the value of your product?
One of the benefits of testing fictional press releases with customers (see above) is the feedback from customers enables the product teams to identify 7-10 high level values being sought by our customers.
At that point, the team is able to conduct a MaxDiff study to begin prioritizing values from least to most important.
MaxDiff analysis, also known as the best-worst scaling is an analytic approach used to gauge survey respondents’ preference score for different items. It is like conjoint analysis in many ways. However, the only visible difference being MaxDiff is easier to use and is more comprehensive when you want to analyze critical research situations.
We also conducted separate MaxDiff studies with both task workers and executives to better understand how they prioritized the value of the product.
How can product teams create personas based on the specific needs of their product while maintaining consistency across the entire portfolio?
Our team had a persona problem.
Our gallery of personas was widely used by product managers, researchers, and designers, which should have been an indication of success. However, teams were borrowing personas from other projects as-is, rather than creating their own or enhancing the existing personas. The impact was that teams weren’t taking the time to learn about their customers.
The Persona Toolkit includes standardized components that are relevant for the entire organization including roles, context, and action. Teams could then assemble standardized components into a persona using a standardized Mural template.
Finally, standardizing on components simplified the process of moving the personas to planning tools like Aha!
What work activities are the most important for compliance professionals that are currently underserved in the market?
The DBA User Research Team was asked by product management to identify and prioritize areas for innovation within data governance. The results would also be used to evolve the governance persona with both qualitative and quantitative data.
For this study, we chose to use the Jobs to be Done methodology to identify and prioritize unmet needs within the market.
Job To Be Done (JTBD) is a framework for viewing your products and solutions in terms of the jobs customers are trying to get done. In other words, the JTBD is the reason why your customers hire your product or service. According to the author, it is a starting point for innovation and a critical element when devising strategy.
The concept of the JTBD was developed by Clayton Christensen at Harvard Business School and has emerged as a helpful way to look at customer needs by focusing on their fundamental motivation.
You’re a Product Manager who reviews hundreds of documents including competitive briefs, analyst reports, and customer segmentation data. How do you retain and organize your notes into meaningful insights?
I had developed FluidMemory as a user-friendly qualitative data analysis solution that enables teams to collect and analyze written content, including notes, analyst reports, and presentations, across multiple tools including Miro, Mural, Google Sheets, and Google Docs.
