2. A Systems-Thinking Approach to Understanding the Problem

• In a regulated environment, the details of a programme and its drivers may be kept on a need-to-know basis. Typically, this UX brief lacked specificity and was given verbally. In the beginning, there is a lot of ambiguity.

  Using the double diamond framework, I positioned the challenge at the left most point of the diagram where very little is known. During this discovery phase, I collected and catalogued everything the team needed to develop understanding of the problem or problems that will emerge.

  Given the scale and complexity of the organisation, which included legacy and integrated systems, I adapted a service design approach with research and systems thinking to establish comprehensive understanding of the current state.

  Steps included mapping the end-to-end user journey, associated business processes, and the supporting technology landscape to identify touchpoints, hand-offs, duplication, pain points, and system dependencies. To do this, I used a digital whiteboard (FIGMA Jamboard) to communicate and share the findings, as well as to encourage engagement.

  This approach quickly revealed scope extending well beyond a single team or business unit, with critical knowledge dispersed across individuals, protected archives, and embedded system logic.

3. Building the Project's Most Referenced Source of Truth

• Proper research is the backbone of all good UX. Research outputs inform next steps, help with difficult decisions, and can result in changed direction or priority, while still in the design definition phase.

  A comprehensive map of the current end-to-end user journey, gives the project team a tangible starting point from which to define the problems and envision a future state with clarity. With this in mind, I captured every screen, every interaction (including conditional views), errors, hidden content, dropdowns, associated business processes, and the supporting technology landscape. I achieved this by using a combination of techniques including targeted stakeholder and SME interviews, business-unit-specific workshops, and collaborative whiteboarding to learn from expertise, progressively validate current-state artefacts and compare them in context with our competition while gaining access to specific wikis and knowledge not normally shared across business units. As the work evolved, I expanded the engagement model to include playback sessions, demonstrations, and cross-functional co-design activities to ensure the emerging experience design reflected operational realities as well as user and business needs.

  Because of its currency and completeness, this journey research became the project's most referenced source of truth. It was not vulnerable to system outages and delays, and viewed in its entirety it enabled a shared and full understanding of context mismatches, design inconsistencies, and content discrepancies. By placing these journeys in secure but high visibility areas I encouraged impromptu conversation between stakeholders and interested or involved parties, debunked theories and cleared up misunderstandings early. I created a platform for developing empathy while improving stakeholder alignment around an evolving experience strategy.

  In addition to mapping, I observed and met with frontline staff and new customers to understand and document their experiences. I queried employee sentiment using polls on Yammer, and I formally interviewed internal office users and stakeholders in Risk, Financial Crime and Compliance, Business Banking, and IB&M to learn about the purpose and downstream requirements of data collected in context of their needs (both met and unmet). End customer research which had been commissioned prior to my start, was embedded at every step.

  Research outputs can be voluminous. Extracting themes, understanding sentiment, and identifying genuinely relevant patterns is laborious and requires attention to detail with a high level of critical thinking maturity. Analysis and synthesis of research notes is well suited to assistance from ai provided the research has been well structured from the outset, with specific purpose, meaningful inquiry and oversight. Common UX tools are increasingly equipped with ai capability.

  In an earlier case study (scroll down to read) Human Centred Design Strategy (2021) I wrote about my UXD process generally. Often, as experience practitioners we have to adapt to the particular working environment or role, the brief and constraints you are given, the timeframe and the appetite for exploration, experimentation and change. Stakeholders don’t always believe there is sufficient time, budget or requirement for UX research. Adapting is to be inventive and creative; meet people where they are and bring them with us.

4. Facilitating Alignment Through Workshops

• For this project, stakeholder alignment was critical. The onboarding experience needed to balance needs of staff users, external customers, operational realities, regulatory obligations and the technical constraints of an active CRM transformation program. While many stakeholders were working remotely and engagement levels varied across teams, project momentum depended on creating a shared understanding of both the problem and the opportunity.

  To move the initiative forward, I facilitated a series of workshops with business, operations, compliance, design and technology stakeholders. Drawing on current-state research, customer insights and workflow analysis, these sessions helped teams collectively examine existing processes, challenge assumptions and discuss areas of friction.

  The workshops created space for participants to step outside organisational silos and focus on the end-to-end experience. Together, we identified unnecessary process complexity, removed duplication, consolidated steps and standardised decision points. Emerging concepts and workflow proposals were then played back through follow-up sessions and demonstrations to validate assumptions and ensure the design reflected operational realities as well as customer and business needs.

  Although engineering participation was limited during some of the early workshops, ongoing playback sessions, sprint ceremonies and design reviews helped bring delivery teams into the conversation, ensuring design intent remained connected to implementation considerations.

  Having aligned business, operational and compliance stakeholders around a simplified future-state workflow, the proposed experience was approved to progress into detailed UX design and adopted as the agreed direction for future delivery.

  Using workshops I transformed an initially ambiguous problem into a shared vision, and gave stakeholders confidence in both the proposed solution and the path to delivery.

5. Navigating constraints and dependancies

• Every project operates within a set of constraints, and this initiative was particularly complex. The onboarding experience sat within three concurrent transformation programmes, each with its own objectives, roadmap, delivery schedule and governance requirements. While deeply interconnected, the programmes operated at different speeds and had dependencies on one another, creating challenges for planning, prioritisation and design decision-making.

  Alongside these programme dependencies, the experience also needed to balance customer needs, regulatory obligations, operational processes, and technical limitations with the introduction of a new CRM architecture and design system. A design decision that appeared straightforward in one area could have unintended consequences elsewhere, requiring careful consideration of the broader ecosystem.

  One of the most significant challenges was translating newly drafted legislation into an experience that felt straightforward, supportive and unambiguous for customers while remaining compliant. Regulatory language is often complex and open to interpretation, yet customers should never have to bear that complexity. My role was to understand the intent behind the requirements and work collaboratively with compliance, operations, product and technology stakeholders to identify solutions that balanced customer experience with risk and business obligations.

  As the project evolved, priorities, requirements and delivery considerations continued to shift. Maintaining alignment required ongoing stakeholder engagement, iterative prototypes and regular playback sessions to test assumptions and build confidence in proposed solutions. By making complex requirements tangible through visual workflows and prototypes, discussions became more constructive and decisions could be made more quickly.

  The resulting UX design successfully balanced customer, business, operational and compliance needs while accommodating the realities of three interconnected transformation programmes. More importantly, the process established a shared understanding of priorities, dependencies and future-state workflows, allowing stakeholders to move forward with confidence and a clear path to delivery.

6. The Future State

• With aggreement on the future-state vision, engineering could focus on solution design, while I worked with change managers in bringing it to the broader business.

  I had developed future-state workflows with fewer steps, simplified decision-making, and consistent execution of compliance obligations across different use-cases. Interactive prototypes, service design artefacts and workflow visualisations were used to explore options, evaluate trade-offs and progressively refine the experience.

  Throughout the project, I worked closely with business, compliance, operations and technology stakeholders to ensure proposed solutions were desirable for customers, feasible within technical constraints and viable for the organisation. Iterative playback sessions helped validate assumptions and maintain alignment as the design evolved.

  The resulting experience established a leading future-state vision for every customer journey in the new CRM, while combining effort and reducing duplication across both individual and entity customer onboarding. This work provided an improved customer experience and a practical pathway to implementation within the broader transformation programme.

7. Outcomes and Reflections

• This project reinforced the importance of systems thinking when designing within large organisations.

  The challenge was never limited to individual screens or interactions; it involved understanding how customers, staff, processes, technology and regulatory obligations influenced one another across a complex ecosystem in transformation.

  As the first of many key customer journeys to be reimagined in CommSee 2.0, this project set the standard for simplified, efficient, and empathetic new workflows. While connected transformation initiatives are still running, artefacts produced throughout discovery and design are helping other teams progress with greater confidence, clarity and alignment.

2. Determining the best approach

• My User Experience toolbox is full of useful templates. Some are on high rotation, in a constant cycle of customisation and refinement. Others might be highly contextual and not used as often. The important thing, is to know what they are for, and how to get the best from them. At the beginning of a project, in conditions of extreme ambiguity, it can be difficult to see a way forward and to find the best approach. At times like this I keep my focus on the customer - the person and the purpose. We are human-centred designers and we start by gathering information, asking questions, finding empathy, and observing.

3. Research planning

• Articulate the purpose, focus, and definition of done. The screenshot shows an Agile task that has been catalogued in Jira. While Agile may share principle similarities with UX, (such as simplification, iteration, componentising larger tasks) it is nevertheless, not always a comfortable fit in our workflow. Research takes time, and as indicated on the first slide, accounts for most of the time we spend before arriving at a wireframe. Like any other plan, a research plan has a known beginning and a desired end, with decision activities in the middle. In Jira, I have described the issue to initiate the task. I have identified the topic, and the definition of done (DoD). In doing this, I pursue a shared understanding of the process, the rigour, and the method which provides the baseline for my decisions and sets expectations. At this stage, the shared understanding is as important as findings and recommendations delivered later on.

4. Sticking to the plan

• Sprint timeframes and incorrectly sizing tasks for ambiguous pursuits can impact the process. At this mid-point it is important to back myself, back the plan and the planning, and be constantly referencing the purpose, topic, project goals, and context for all the twists and turns that present. With good, transparent planning the process will hold up and can accommodate changes in knowledge that may affect the purpose or goal. HCD is not linear. A research plan is not a blueprint. The details of the plan may change or the findings might reveal something not yet seen. The most effective plan will scale and keep the process moving.

5. Follow up and synthesize the data

• So. Much. Data.
  During COVID-19 we have relied on digital collaboration tools more than ever before. The image shows a collage of virtual sticky notes on multiple Miro boards. At first, the data is collected as notes taken quickly, during an interview. This initial step is verbose and haphazard. What follows is a repeating process of sorting and clustering these observations and notes into topics, ideas, and relationships; while taking care to preserve the intent and context of the research activity. Little by little the insights that we were seeking, and that will authenticate the vision, emerge from the volume of outputs - sometimes looming large as themes, sometimes as outliers of varying significance.

6. Report and document findings

• Review the planning from step 3. Share findings from step 5 and deliver what was promised. As we move into the design phase, insights will guide the next steps. In this example I have mapped an old user flow to the proposed new one, keeping the relevant user stories, notes from the previous step, and links to supporting documents close by. I don't prescribe the tools or the presentation method. The best tools are the ones that our audience (stakeholders and extended team) are already using. UX is not limited to the needs of the end state audience, and meeting our audience wherever they are, is foundational to good design. At this opportunity we can validate a brief or a user story, we can get buy-in where there wasn't any before. We might even decide against a planned activity. Powered by research and a broad understanding of the problem, this is HCD.

7. Recommend next steps - wireframe

• The wireframe is used to visualise the design intent, rationalise the research outcomes, and provide a platform for the earliest user validation. Depending on the size and complexity of the issue, the resources, and the design maturity of the client, the presentation may differ while its value is unchanged. With minimal decoration, the wire is quick to produce. It focuses on the job to be done, and the ease of movement between minute stages of that task. But, like everything else in the UX / HCD process, the purpose, focus, and goal of this artefact must be understood before its value can be realised. For some people, the low fidelity of a hand-drawn wire is in itself distracting and too abstract to be useful. The preamble needs to acknowledge this, provide a definition of the scope, and screen for meandering points of view. Sometimes, when the client has an established and comprehensive design system, a clickable (medium fidelity) prototype may be just as quick to draw, and easier to onboard.

8. Test, review and measure

The long-sighted backlog

• Planning: UX activities inform UI and content design, which impacts navigation and IA, which comes before development and engineering. This is why UX activities need to coordinate with developers and engineers at the planning stage. In Agile product development, best practice is to share early and often, validate and revise - across each of the team functions. Unproven assumptions may waste hours of design or engineering time if work begins too soon.

  Though its widely accepted that UX research will substantiate theories into validated stories, the right time to integrate UX into project management is not well understood. Starting with the product vision or end-state which was likely captured in a workshop with stakeholders, the product backlog records outputs as requirements on a roadmap, but outputs by themselves won't get us to the vision.

  Outputs or deliverables are not the same as outcomes. Like user stories, outputs are simply "done" or "delivered" while outcomes show the value of UX as an impact, a change, or an improvement. Starting with the product backlog we need to be better at reconciling effort to measurable outcome. Including research spikes for UX to evaluate and determine the approach (such as steps 1 & 2 from the HCD process outlined in the study above) will result in more efficient, democratic and productive sprint planning that delivers measurable customer benefit.

  Estimates and sizing: UX tasks - which almost always fall into some kind of journey - are not well served by the punctuation of user stories or issues in Agile scrum which often lack sufficient context. Agile User Stories were invented for the production of code in software development so that each minute step would be explained for the benefit of an unthinking robot. By comparison, good human "Experiences" feel like seamless transitions; For this I prefer a "Job Story".

Addressing the problems, and evaluating choices

• In a typical user story each of the inputs has a precise value, and the result of UAT is pass or fail:
  As a [persona name], I want [feature name], so that [defined value].
  Human centred design is not code. Without context, HCD is not Human Centred.

  By comparison, a job story examines context as the driver of need for any user. With this simple shift in focus we acknowledge the multi-dimensional human user, responding to enviromental triggers. A job story creates empathy by allowing space for their different scenarios. When [situation], I want to [motivation], so I can [expected outcome].

  Empathy is preparing for a users' next move, or in bringing forward the context that has gotten them this far. It helps when estimating the scope of the task, and in defining a better success metric.

  Another approach for mitigating sizing issues is to incorporate research spikes within the product backlog as mentioned on the previous slide. A research spike provides visibility of the type and extent of research tasks to be done, while removing uncertainty about when to incorpoate UX within the project workflow; doubling the benefits to the team.

Agile HCD: "While there is value in the item on the right, we value the left more."

• 1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

  A project kicks off. The process (for delivering the thing we agreed to) has begun - except - before it exists, we can't know for sure if the market will like it.

  UX (HCD) is precisely the methodology to alleviate this risk and to accurately refine and condense opportunities before engineering them.

  Embedded from the outset UX activities compliment Agile project management. Nothing Ambiguous about that.

  References:
  Content Design by Sarah Winters (formerly Sarah Richards)
  Designing content for customer mindsets
  Atlassian - Agile Manifesto
  Lean UX by Jeff Gothelf and Josh Seiden