Framing requirements as hypothesis

There’s some UX in your PM


Framing requirements as hypothesis

The project
01. Benchmark Research
02. Service Blueprint
03. Facilitation
04. Conclusion
industryHuman Resources - IT
Overall Design MaturityDeveloper-Centered User Experience. Learn more
Duration2 months
Teams InvolvedExecutives, Customer Success, Implementation, UX Design, Development, QA Testing
ROLE PLAYEDBenchmark Research, Service Blueprint creation, Workshop Facilitation
ProjectPerformance Management Enhancements


TalentGuard is an established startup that provides HR software solutions focused on talent retaining, succession planning and career development; their management suite has become one of the top 10 tech tools leading systems in the industry.

The original multi-product SaaS suite was built from a developer centric perspective without user experience in mind. In addition to the limited time and budget, the inefficient usability and confusing information architecture was the main UX challenge.

In preparation for the core module usability enhancements, we’ve conducted a series of research studies and workshops with 5 customer support specialists, 3 developers and 3 designers. Our goal was to understand the urgency and complexity of the features that needed to speed up and enrich the interaction.


As a starting point the Design team got a list of concerns provided by the Product Owner and the results from an analysis conducted by the Testing Automation team.

In the past, the organization used a scrummerfall type of structure where the Product Manager would capture the initial requirements to be passed over to the Design team in the shape of user stories, creating a filter between designers and user needs.

The sudden absence of a Product Manager (our collaborator resigned) opened the door for the Design team to intervene at an earlier stage, reframing the stakeholders requirements as hypothesis,  and conducting initial studies to understand, continue or re-formulate those premises. The deliverables included the documentation of flows, patterns, challenges and strategies users would take to navigate the module.

The product life cycle was an additional consideration, as the full module was on its way to be redesigned. Therefore, we considered these enhancements as part of a transitional phase, while the full re-architecture was complete.

In addition, this project took place during the COVID-19 stricken world and economy of 2020.

Even in the aggressive startup environment, our typical situation never stacked up a pandemic, a fully remote work model and a resignation of the Product Manager.
However, the complexity brought the opportunity to execute new practices guided by Design; emerging an inherently soft power promoted by the use of remote inclusive workshops that were elective in participation and turn the digitally-mediated voices equal.


Contextual Inquiry

To understand and define the current flow we conducted a series of interviews with users and representatives from Customer Success, Implementation and Development. They guided us through the process, exposing the interaction behaviors and workflows for the employee, manager and administrator.

Additional Research

In order to clarify the jobs-to-be-done, we also studied other systems processes (flow diagrams) to elucidate differences in the approach, steps, ownership and interactions.

This research also helped analyze and dismantle the solutions provided during the contextual inquiry phase.

Research Findings

We found that the current architecture was usable and satisfied the existing system library. However, the logic and functionality of the componentry did not display the afforded interaction in ways that represent opportunity and guidance to the user; therefore, the experience was compromised by multiple frictions, being the navigation between touchpoints one of main points of concern.

The front-end layer was tightly coupled with the back-end architecture; any change to the look and feel of affordances should be considered as a medium to high development and testing effort.

Given that this was the core module where the full suite relied, applying major changes on the flow should be considered as a complex and risky development designation, and probably an extensive testing assignment.

The administrator’s experience had a significant potential for improvement; however this flow was mainly unseen by the user since the Implementation team was in charge to set up the module for each company.

The findings helped identify the actionable areas.


Mapping the current process helped us to get a comprehensive understanding of the user’s experiences with the module across all touchpoints, and to highlight the underlying processes – seen and unseen by the user– to make this possible.

This map was our main collaborative tool to communicate and create a shared understanding of the current challenges, align our scope, define goals and prioritize areas for improvement.


Miro is the Design team’s main collaboration tool. We used it to run the remote workshops due to its great features, but also because some of our teammates are already familiarized to it.

As a regular practice, for sessions with non-designers we send in advance the how to use videos, and schedule 5 to 10 minutes at the beginning of the session for a short explanation of the main tools. We also use icebreakers for the participants to interact with the app in a safe and joyful environment.

To elucidate the approach we would take, while enabling an aligned progress, we shaped two intensive collaborative workshops focused on the employee flow and the overlapping experience for the manager.

1. Customer Success and Implementation: Prioritization of issues

Participants exposed the most severe customer issues to their knowledge.

2. Development: Build empathy for the user, evaluate risk/effort and broaden the perspective beyond the design team

With a shared understanding of the user needs, the participants ideated high-level solutions keeping in mind the timeframe, risks and complexity of the system.

Customer Success - Prioritization and Implementation: Prioritization of issues


Build consensus on the issues impacting the module users, according to Customer Success and Implementation teams. Use the results to inform and balance the project roadmap.


Severity/impact on users' ability to successfully complete a task and range/number of affected users.


1.5 hours in one session.

  • The materials used were the Service Blueprint, Kanban board and icebreakers (memes).
  • The Design team attended as facilitators.

Remote synchronous workshop using online resources.

  • Getting used to Miro + icebreaker (15 min).
  • Walkthrough of the Service Blueprint + timed voting per touchpoint (40 min).
  • Frustration prioritization on a Kanban board, framing selected themes as a semantic-differential question (25 min).
  • Wrap-up and follow-up (10 min).

Development: Build empathy for the user, evaluate risk/effort and broaden the perspective beyond the design team

  • Communicate the priorities demarcated by Customer Success.
  • Create consensus on the risks and effort required to tackle each theme.
  • Ideating high-level solutions, considering the complexity of the back-end architecture and underlying legacy systems.

Overall risk/effort on the issues prioritized by Customer Success, and high-level solutions to be framed later (not on this workshop) as a design challenge

  • The materials used were the Service Blueprint, Kanban board and brainstorm/affinity diagram boards from Customer Success workshop, icebreakers (memes).
  • The Design team attended as facilitators and active participants.

Remote synchronous workshop using online resources.

Session one:

Empathy (60 min).

  • Getting used to Miro + icebreaker (15 min).
  • Walkthrough of the Service Blueprint (30 min).
  • Explanation of the results from the frustration prioritization workshop using the Kanban board (10 min).
  • Wrap-up and follow-up (5 min).
Session two:

Ideation + Risk Discovery (90 min).

  • Recap on where we left off (10 min).
  • Ideation of abstract solutions framing the most important pain-point themes as "How Might We" questions. Individual activity for developers and designers (25 min).
  • Organization of solutions for each question, utilizing affinity diagramming. Prioritization by least amount of effort using a timed 3-dot voting process (20 min).
  • Break (10 min).
  • Initial assumptions of potential risks for each top voted idea. Individual activity for developers and designers. (20 min).
  • Wrap-up and follow-up (5 min).
Session three:

Next steps (60 min).

  • Recap on where we left off (10 min).
  • Effort/Impact mapping of top voted ideas from the previous session. Activity for developers only (20 min).
  • Description of three action steps for testing the solutions in less than 2 weeks, on a low-to-high effort hierarchy. Activity for developers and designers (20 min).
  • Wrap-up and follow-up (10 min).

Actionable items = hypothesis

Guided by the results of the workshops we visualized the actionable items and future PBIs in 4 groups, from high impact - low effort, to low impact - low effort.

The actions considered as low effort, in disregard of the impact, were straight forwarded for an evolving prototype test, since the solution was already set. While the tasks contemplated as high effort, both with a low or high impact, were considered as the next questions to be solved in a Design Sprint.


With a high level of confidence, the outcomes were used to populate the Roadmap as themes or subthemes, detailing the owners and timeframe with more precision than ever before.

This also allowed us to plan additional tasks not previously done by the Design team, as the PBI - use cases writing, internal training and product release planning.


The uncertainty of the entire design process is generally viewed with mistrust by executives not used to generative processes, where the result is formulated episodically and therefore, takes time. However, elucidating the final design not as the invention of a single creative head, or as the sole mandate of the stronger voice in the room, fueled trust in processes and protocols.

These scaffolded online modes-of-inquiry can be repeated and standardized (up to a certain point) and inevitably question the organization’s underlying power arrangements, fostering in exchange, a smooth transition towards collaborative generation of solutions.

Furthermore, confidence in the process itself allowed us to resolve prejudices against emerging methodologies and even negative attitudes towards the design team.

As a Design manager, I identified 4 fundamental practices:

Design decision frameworks accelerates the understanding of the impact, information required, complexity and reversibility of the challenge.
Team operation under a voted-based protocol is substantial to move forward with proposals that require quick unanimous consent.
Trust and support balances the capacity of the team, allowing the more experienced individual to take the reins at certain times (for example, facilitating a workshop or answering specific questions), while leaving room for intervention and learning from other team members.
Promoting confidence in the process rather than in our personal background, removes the emotional distress that is entailed by working with ambiguity; it also helps to overcome frustration, shame and guilt that can appear while pushing design practices in a low UX maturity organization.

The relevance of the project moved us to submit it as a case study for the ACM CHI Conference 2021.