Through understanding how people actually make decisions, I design the products, processes and tools that help enterprise teams act on data, reducing the gap between what organisations know, and what they do about it. I lead client work end-to-end, from defining the problem through research-led, co-designed delivery, and I grow design capability in the teams around me.
Product
Dashboards for a consumer goods company, used in monthly meetings in place of the slide deck. People moved from arguing about the number to talking about the business, and became more comfortable working with data directly. The client estimated it saved around 100 hours a month, and reported £14M in additional net sales value within six months.
View case study
Product
A system for a UK regulated utility’s compliance, operations and regulatory teams, tracking self-assessments, actions and external assessments in one place. I mapped how compliance works in practice, and where the needs of central compliance and the teams on the ground pull apart, so one product can help everyone do their job. The map also shows where automation can pull in data from other systems and alert people when compliance is at risk.
View case study
System
A Figma design system for building dashboard wireframes that translate directly into Power BI. It combines a style guide and a component library in one file, with rules for colour, chart alignment and spacing, and guidance on which charts suit which situations.
View case study
Method
To design for decision-making, you have to understand how individuals and organisations make decisions. Curiosity mapping is a visualisation method for learning how functional specialists think, and for getting everyone aligned on it.
View case study
Personal product
A personal tool I designed and built with Claude: an activity log that records what I worked on, who with, and what to follow up.
View case studyMethod
To design for decision-making, you have to understand how individuals and organisations make decisions. Curiosity mapping is a visualisation method for learning how functional specialists think, and for getting everyone aligned on it.
Curiosity mapping evolved from a two-day user research workshop. What started as post-its stuck on a wall became a more polished set of questions that externalise how functional specialists think, to help product teams build the right products.
A curiosity map traces:
Each question is then checked against what already exists: is there a product that answers it well today, or would it need a new one? The map also notes the level of data aggregation each question needs, and the metrics that would answer it. That lets us analyse how available those metrics and KPIs are, and start designing the dashboard screens that answer each question.
Each diamond is a question, categorised by the level of information needed and whether it is in scope. The questions are arranged into broad themes, which sets their position, and the links between them show how those themes interact. A theme might be a screen, a set of screens or even a whole product, and a single question could be a product in itself.
This is a simple entry point to a dashboard, asking what the market looks like across products at different price points. It moves from a highly aggregated, executive-level overview of the market today, to more detail on products, brands and categories and how they change over time, and then down to pack size, branding and promotions and their influence. That last level is where specialists spend much of their time on more complex analysis.
The pink diamonds are the screens in scope for an early iteration of the product.
Product
Dashboards for a consumer goods company, used in monthly meetings in place of the slide deck. People moved from arguing about the number to talking about the business, and became more comfortable working with data directly. The client estimated it saved around 100 hours a month, and reported £14M in additional net sales value within six months.
The executive-level monthly performance meetings ran off slide decks built by the functional areas, with no single version of the truth. The conversations weren’t as valuable as they could have been, because people were discussing whether the numbers on screen were correct. The decks also took time to build, so by the meeting they were often a couple of weeks out of date.
The functional areas saw the hierarchies slightly differently. Brand and marketing, for example, might categorise brands differently from the commercial teams, who looked at them more from a promotional perspective. Numbers were aggregated inconsistently, and not always in a self-explanatory way, and high volumes of manual data cleansing and reconciliation went into producing them.
Existing analytics tools had been designed to support individual use cases, without being considered across functions, and adoption of existing tools had been low.
The programme’s baseline found people were twice as likely to feel frustrated, impatient and confused when working with data as to feel focused and enthusiastic.
We followed a double diamond approach, working with the functional teams throughout so the dashboards reflected how they actually make decisions. I used curiosity mapping to record some of the research outputs.
A team of over a hundred people worked on this product, mostly in data engineering. I was information design lead, working closely with the user experience design lead and the client’s head of user experience design, and with a team of UI designers to design the dashboards.
I owned the structure of the product and came up with ideas for how to represent data to answer business questions. My role was largely conceptualisation: thinking through which charts were needed, where they went and how content was displayed on screen, and the information hierarchy, such as how colour is used.
Beyond having a nice tool that’s easy to navigate, it’s making us ask important questions.Market Director
System
A Figma design system for building dashboard wireframes that translate directly into Power BI. It combines a style guide and a component library in one file, with rules for colour, chart alignment and spacing, and guidance on which charts suit which situations.
Within a client context, many teams were building dashboards that did not adhere to the style guide or follow a consistent structure. There was a design system available for them to use, but it didn’t fully reflect what Power BI dashboards needed. The style guide was kept in a separate place, so anyone designing a wireframe had to look at several documents to understand how to use it.
Most project teams also didn’t have a designer, and the existing design system assumed its users already knew Figma. It needed to be something non-designers could pick up without having to learn much about Figma first.
Anyone creating wireframes for Power BI dashboards in the client context. That could be a designer, but also a developer, a business analyst or a product owner, depending on who was in the team.
I took the existing design system and style guide and created a structure for the design system. It brings in all the relevant information to support product teams in making wireframes that are consistent in how they use colour and layout. That equips them with knowledge of design principles, and an explanation of how to apply the style and use the components and variables set up in the system.
I did some research with business analysts and product owners in the client teams to understand what they would need and periodically shared the system with them for feedback, to support iterations.
I created a library of components and a file that explains how to use them in context, with the following structure.
The charts are built from atomic parts and are fully responsive: if one needs to fit a different space, the whole chart scales in the right way. A bubble chart, for example, scales so the bubbles stay circular.
I created a generic version of the design system that could be used across different client contexts, and to support internal and sales materials, to quickly create high-fidelity prototypes. Using variables in the Figma file has made this very straightforward: only a few things need to be updated, such as colour and font, to change the look and feel of the wireframes made with the design system.
Product
A system for a UK regulated utility’s compliance, operations and regulatory teams, tracking self-assessments, actions and external assessments in one place. I mapped how compliance works in practice, and where the needs of central compliance and the teams on the ground pull apart, so one product can help everyone do their job. The map also shows where automation can pull in data from other systems and alert people when compliance is at risk.
The company tracked its compliance in a tool it had built in Power Apps. That raised a few problems. It couldn’t scale to capture the amount of information the company needed to hold, or to support its duty to report its compliance position over a long period. It wouldn’t integrate easily with the other systems the company relied on. And it was complex to use: people needed training before they felt comfortable with it. It tracked more than self-assessments, too, including actions and external assessments.
The aim was a more flexible system that follows how users think and work. The team had already built versions of it from the data available, which proved it was technically feasible. But operational users said it didn’t reflect their processes well enough. I joined in the fourth phase to rework it and make it easier to use.
Central compliance sponsored the system and had been closely involved in building it. Both teams care about getting the information right, but they need it shaped differently. Compliance needs it structured in a particular way for analysis. Operational teams need it structured so they can act on it. Sometimes those are the same, and sometimes they aren’t.
The compliance team is very wary of unknowns in their data, so they wanted quite a rigid structure. Operational teams felt that didn’t give them enough context to know what to do. The design was a balancing act: capture information the way compliance needs it for analysis, with enough flexibility that it still means something to the people working on the ground.
I joined in the fourth phase, so my first research was with the people who had been on the ground from the start. A new decision-making structure was being rolled out at the same time. I worked with them to understand the system at a high level, then played it back to compliance and operational users to check I had it right. I covered:
I worked mainly with business analysts and engineers in our own team, and with the strategic, client-facing team members who worked directly with the client.
My biggest contribution was a step-by-step user flow that guides operational teams through a self-assessment. They know what is required of them and how to answer, with all the information they need and a way to ask questions, so access to information is never what stops them. It is also designed not to overwhelm.
The updated product has made the documentation of self-assessment far more straightforward, and work continues. The next steps add more automation: a permit reader that updates the system when a permit changes, with people only needing to check it; automated readings for chemicals at different points in the water system and at outflows; and a link to the capital maintenance project system, so an action such as refitting a building or a tank can be followed through. The aim is to keep strengthening the links between systems so the right people have the information they need before anything goes wrong.
Personal product
A personal tool I designed and built with Claude: an activity log that records what I worked on, who with, and what to follow up.
It is often difficult to officially log time spent between projects. I wanted to learn to build with generative AI, and I learn best by using the tools, so a log of my own time was a real problem to build against.
The aim was an accurate record of what I was doing, who I was talking to, the leads I was following up, my side-of-desk work, coaching conversations and business development support, so I can answer when I’m asked what I was doing.
Me. A private record I could add to daily, building a habit while I still remembered what I’d done, and easily extract from later.
I started by asking Claude Chat how to build an activity log, and the first version lived inside the chat itself. It wasn’t comprehensive enough and had no visual front end, so I moved to building a proper app with Claude. It went through these stages:
After starting to build, I thought through what I needed to log, the different categories, and how I would need to log that information, because the fields needed to be different for different types of information. I mapped a flow and a structure of information for how an activity would be added.
After a few iterations I moved from Netlify to running it locally, which changed my workflow substantially. On Netlify I was iterating without seeing the output. Locally I could make small changes and see them on screen straight away, which taught me to give Claude better instructions.
I made a dashboard showing a log of activities, with the time breakdown visualised as a stacked chart and a to-do panel of relevant follow-ups. I could add new activities, and filter and search anything already in the system. Entries were organised into categories, with a status and a priority. I could search on a particular client or colleague, and add relevant information such as charge codes, if they existed, and whether an activity aligned to one of my work priorities, so I could log it as something that moved those priorities forward.
It was only for me, so I prioritised function over visual polish: seeing and filtering what I had logged at a glance, so I could tell someone what I had been up to over a period.
Building this made it clear to me that design discipline matters more, not less, when AI makes building quick. It is easy to end up with something comprehensive and complex that was never properly thought through.