The User Experience Design (UXD) team at Red Hat started up our empathy workshop series again with a new developer-focused workshop around software supply chain security. This workshop was run at OpenShift Commons in Boston this past May and was a milestone for product designers as we had not done an in-person workshop in over 2 years! 

The great thing about empathy workshops is that they are a casual forum for our customers to give us feedback around the Red Hat products they use. The workshop in Boston was 2 hours long and involved hands-on activities where participants shared their pain points and needs using sticky notes and markers. UX designers and product managers helped out by translating and finding commonalities in the feedback. The activities were very collaborative and iterative with the following steps:

• Empathize - Discuss pain points in how they use Red Hat products
• Define - Turn the pain points into problem statements
• Ideate - Collectively develop solutions to the problems that have been identified

After a round of introductions, we shared a list of unmet needs for developers and platform engineers that we found through user outcome research and had customers vote for the ones they were most interested in digging into together. We decided to focus on 2:

Empathize

After voting, we asked customers to think of major challenges that prevent them from achieving these outcomes. Working in 2 groups, using whiteboards and sticky notes, we were able to collect and sort the feedback. These themes were seen the most with the highlighted pain points being the ones that participants selected to continue in the next step:

The themes that formed were:

1. Modernization and integrating tooling are a major hurdle.
2. Vulnerabilities are still a concern.

Define

After identifying common pain points, each group was asked to select 1 pain point and formulate a “how might we” problem statement. Here are the problem statements based on the selected pain points the teams created:

How might we … Keep up with the new security tooling changes for the development teams?

How might we … Increase the diversity of ways we can notify devs to take action to address security vulnerabilities?

Ideate

From there we brainstormed ideas with the “Yes, and..” technique to come up with these possible solutions:

Possible solutions around “Keeping up with  the new security tooling changes for the development teams.”

• Develop a “Golden pipeline”--  run it and things will automatically get scanned and passed in a ‘soft release’ or MVP environment to increase developer productivity. In order to deploy to prod, it needs to pass security gates
• Seamlessly change gates / roles that don’t disrupt developer workflow (we want something that happens behind the scenes from the devs).
• 1-stop shopping dashboard to tell me a quick “security scorecard’ to understand my app’s health, to show me what is failing, and show where the next release will happen.
• Just-in-time alerts should pop up with snippets to fix vulnerabilities (‘smart fixing’ was suggested as a feature name)
• Pipeline should integrate all feedback and notify everyone in a notification method of their choice

Possible solutions around “Increasing the diversity of ways we can notify devs to take action to address security vulnerabilities.”

• A channel (slack was recommended) that automatically integrates with the pipeline runs when PRs and commits are made
• A desktop tool that continually runs while you build/write code to inform you just in time if a security rule has been violated. 
• Quick feedback form CI/CD that finds vulnerabilities and recommends how to fix them
• ACS should have a JIRA / ServiceNow integration 
• JIRA to automatically do pull requests so that devs can be notified via their Github settings
• Defining additional escalation overrides/increase levels of management approvals

What is next

These solutions have helped the UXD team to prioritize our work around the secure software supply chain in our products. Listed below are some recommendations we are rolling into product design work right now:

- A single pane of glass - Design a UI where developers can track and manage vulnerabilities throughout the entire app architecture. 

- Trusted content - Offer trusted content in the inner loop and provide quick feedback on the CI/CD pipeline throughout the supply chain. 

- Internal developer portal (IDP) - Understand developers needs around golden paths and provide a framework for customization. 

What we learned (about running an in-person workshop after 2 years)

There are a lot of conveniences in running a workshop digitally like everything can be recorded and sticky notes are immediately digitized. But the subtle nuances in feedback during in-person conversations are priceless. Furthermore, the group setting helps encourage new ideas and discussions that are often challenging in a virtual setting.

Here are a few things we would recommend for future in-person workshops:

• Since there is not a recording, make sure there is a note taker at every table
• Try to anticipate the number of attendees early (we ran out of chairs)
• Clarify what language will be primarily used (a participant had trouble contributing)
• Avoid more than 4-5 people at a table to steer clear of side conversations
• Nudge people from the same company to sit at different tables
• For large groups, have an on-screen timer to keep everyone synced. Or bring a cowbell.
• Try 90 minutes - 2 hours might be slightly long
• Improve the slide deck to have just 1 clear slide per activity, not multiple explainer slides

How you can participate

Would you like to attend a workshop with UXD? We’ll be at OpenShift Commons in Raleigh on October 18 and 19 and would love to have you. Sign up here to participate in our developer experience workshop. Can’t make it? You can also fill out our research form so that researchers can contact you in the future for opportunities to influence our software, services, and websites.