✅ User behaviours ✅ Production-grade prototypes ✅ Salesforce backend ✅ Elastic Search
Challenge
Rework a 30 year old legacy case management system that's riddled with unstructured data, no design or task flow inputs in a dense and complex business domain.
12
Rounds of iterative wireframes
Rounds of iterative wireframes
78%
User comprehension score
User comprehension score
Legacy systems
The products to be redesigned were backend-driven propositions with little or no intentionality in the UX. In the redesign best practices were deployed for better data integrity - that being a key business goal.
The products to be redesigned were backend-driven propositions with little or no intentionality in the UX. In the redesign best practices were deployed for better data integrity - that being a key business goal.
Previous single-org-centric customisations had led to an unscalable build with poor data hygiene, non-sensical flows and it was all expensive to govern.
We went from the users battling with this (the legacy app)
We went from the users battling with this (the legacy app)
Ouch.
To users gliding through this (redesigned app)
Clean, modern consumer-grade UI with motion and interaction feedback - yes, even for B2B
Planning
Jira is fine for when you are in the delivery/implementation phase, but prior to that it is not the best way to visualise a release plan and share it with a cross-functional delivery team.
Pre-implementation Jira challenges;
- Cross-functional teams are siloed across different workspaces/projects
- Licencing barriers and Admin restrictions
- Difficult to visualise dependency relationships
- Release scheduling is constricted by sprint structure
To resolve these issues we use a lightweight visual story-mapping tool that can bounce pre-stories across to Jira (as epics) - once alignment has been reached. It's critical to visually expose dependencies, which can get lost inside a Jira workspace view.
Creating a release schedule pre-Jira is one of the best ways to ensure shipping discipline and to make sure that any rescoping doesn't negate the delivery of a vertical slice of value. It also helps to define capability-driven roadmaps, integrate personas and create high-level user stories with first-pass acceptance criteria.
Jira is fine for when you are in the delivery/implementation phase, but prior to that it is not the best way to visualise a release plan and share it with a cross-functional delivery team.
Pre-implementation Jira challenges;
- Cross-functional teams are siloed across different workspaces/projects
- Licencing barriers and Admin restrictions
- Difficult to visualise dependency relationships
- Release scheduling is constricted by sprint structure
To resolve these issues we use a lightweight visual story-mapping tool that can bounce pre-stories across to Jira (as epics) - once alignment has been reached. It's critical to visually expose dependencies, which can get lost inside a Jira workspace view.
Creating a release schedule pre-Jira is one of the best ways to ensure shipping discipline and to make sure that any rescoping doesn't negate the delivery of a vertical slice of value. It also helps to define capability-driven roadmaps, integrate personas and create high-level user stories with first-pass acceptance criteria.
Story-mapping before we get into Jira, to expose dependencies and maintain release integrity
Integrating personas really helps to stay user-centred
Learnings
💠 UI affordances needed to be clear(er)
💠 Interaction state styles can't clash (ours did, at first)
💠 Basic accessibility is non-negotiable, even if it's a new thing
💠 Desktop-first is a strategic risk
💠 Sales being the gatekeepers to customers is problematic for research
💠 Business wants SaaS, but not fully committed to product-led growth
💠 Onboarding should be planned for without huge cost (e.g. 3rd party)
💠 UI affordances needed to be clear(er)
💠 Interaction state styles can't clash (ours did, at first)
💠 Basic accessibility is non-negotiable, even if it's a new thing
💠 Desktop-first is a strategic risk
💠 Sales being the gatekeepers to customers is problematic for research
💠 Business wants SaaS, but not fully committed to product-led growth
💠 Onboarding should be planned for without huge cost (e.g. 3rd party)
Long input forms require that main actions (Save) are sticky, to reduce repeated scrolling
Modern research
Supporting the UR team with Miro assets (post-it tagging, AI synthesis, UT capture templates, metrics) we prioritised understanding the users conceptual model of the current system.
I also supported the research team in demoing no-code AI resources to them (Speak AI) and training them on prompt engineering to get closer to the insights, much faster.
Modernising the research effort with AI for raw qualitative dataset analysis
We also decided to leverage existing user data-entry behaviours (such as keyboard navigation) but with more efficient workflows (smart defaults, prefilling data) and better visual feedback and signalling.
Letting users rename things offers them flexibility, but also encourages poor data hygiene
Our research Miro bards were getting messy, so I built a reusable template to capture feedback
Face it, head-on
We mapped the data and collaborated with the Solutions squad to co-assess Salesforce workflows, analysing the unstructured non-hierarchical data making sure we were showing users and stakeholders something that's actually feasible.
Data and flow mapping were critical. Salesforce was the backend which proved challenging.
I also provided input to the delivery programme by helping to define departmental activities in the delivery pipeline - which teams had been struggling to understand.
UX can be a new thing for a lot of organisations so you might need to adapt your approach to remove interpretation and define a systematic model that can be aligned on.
UX can be a new thing for a lot of organisations so you might need to adapt your approach to remove interpretation and define a systematic model that can be aligned on.
Gaps in the PMO meant we needed a defined delivery structure, for clarity.
I contributed to the project design system with a pattern advisor component that designers could choose from without needing to reference hundreds of flows/frames individually, thereby focusing more on flow and staying consistent.
Feedback from other designers (plus developers and PO's) was very positive and validated that there had been a gap in the understanding of what patterns to use, why and when.
These simple pattern wireframes each come with a side of metadata to indicate the volume of data the designer might be dealing with, and how that should be relative to the choice of pattern you might go for.
Feedback from other designers (plus developers and PO's) was very positive and validated that there had been a gap in the understanding of what patterns to use, why and when.
These simple pattern wireframes each come with a side of metadata to indicate the volume of data the designer might be dealing with, and how that should be relative to the choice of pattern you might go for.
Designers need a hand when picking patterns otherwise they just freestyle it, dev goes nuts
Finalised designs proved successful in terms of positive metrics across user comprehension, pattern consumption, interaction, feasibility and affordances.
Usability and product-market-fit evaluations were made via a low-cost user testing platform that enabled us to test in an unobtrusive manner.
Usability evaluations with unmoderated testing, via useberry app
Production-grade prototypes were produced and tested, backed by solid SaaS UX and UI design principles. In terms of component architecture I trained the team on how to allocate aliases for components, so that they were more easily discoverable for designers across a multi-brand design system.
The benefits of giving components in Figma alias names
We used Figma's dev mode, the (super cool) Eight Shapes AI plugin and Storybook to create an aligned understanding across the squads on the functionality and behaviour.
Breathing space in the UI is critical, and we learned that our input field stroke was initially too thin
Character counters on fields avoids frustration and gets users thinking about naming conventions
Micro-copy, motion and colour signalling can combine to make an interaction language that users learn quickly
Searching cases
Tasked with delivering search and filtering designs (for large-ish datasets) I researched and decided that the Airbnb search model would be smart to work from given they've already done a ton of user testing around it, no doubt!
💠 Prefiltering matches indicator (the UX juice)
💠 Sticky CTA's, designing for scale
💠 Touch-friendly vertical spacing
💠 Side-sheet interaction, a low friction/widespread consumer-known pattern
💠 Elastic Search powering the backend
Tasked with delivering search and filtering designs (for large-ish datasets) I researched and decided that the Airbnb search model would be smart to work from given they've already done a ton of user testing around it, no doubt!
💠 Prefiltering matches indicator (the UX juice)
💠 Sticky CTA's, designing for scale
💠 Touch-friendly vertical spacing
💠 Side-sheet interaction, a low friction/widespread consumer-known pattern
💠 Elastic Search powering the backend
Static facets pattern with potential matches shown - better than a lucky dip approach
With search, we co-analysed the existing schemas and worked within the data constraints. Under a tight timeline we made some trade-offs in order to deliver a functional search that could index and provide quality results in under 20 milliseconds - to users it felt instant.
To push the model hard the squad doubled the volume of training data it consumed and ensured that sample data payloads were properly representative of the actual data.
From research we had learned that supporting contextuality was needed for users to make an informed decision on whether to interact with a result, or not. We had shifted the effort from the user to the system, letting the tech do the hard work instead.
To push the model hard the squad doubled the volume of training data it consumed and ensured that sample data payloads were properly representative of the actual data.
From research we had learned that supporting contextuality was needed for users to make an informed decision on whether to interact with a result, or not. We had shifted the effort from the user to the system, letting the tech do the hard work instead.
Targeted, faster results beats volume
Instead of offering lots of facets to drill-down into (is the query a name? address? UID?) - and given we knew there would be partial matches - we decided to have rich sets of results that carried payload information including UID, status, address and date updated.
That wider contextual approach proved valuable to users. At three character input the search would go and fetch for matches, then return a limited set of results at lighting fast speed.
This UX technique brings the user straight into task-behaviour, avoids having hundreds of paginated results and returns a much tighter, targeted set of results.
That wider contextual approach proved valuable to users. At three character input the search would go and fetch for matches, then return a limited set of results at lighting fast speed.
This UX technique brings the user straight into task-behaviour, avoids having hundreds of paginated results and returns a much tighter, targeted set of results.
