Understanding products & services from the user's side.
Helping teams understand why products and services are not working and what needs to change.
Focused on complex public services and enterprise systems where user problems point to deeper structural issues.
Was the problem primarily a training gap, or was the platform structure itself creating friction that no amount of training would fix?
Operational teams across the department used a newly migrated Oracle Fusion Cloud ERP platform serving over 35,000 users across HR, payroll, finance and procurement. Processes were slow, errors were frequent, and support demand was high. The prevailing assumption, including among senior stakeholders, was that staff simply needed better training on the new system. Working collaboratively with the product and delivery team, I assessed what kind of research would actually answer the question and whether training was genuinely the right lever.
The platform's navigation was organised around internal system categories, not the tasks people were actually trying to complete.
People had no reliable way to build a mental model of how the system was structured. Every time they sat down to work, they had to translate what they needed to do into the platform's own logic. That is not a training problem. More training would have made people better at navigating a structure that did not fit how they worked. It would not have removed the effort of doing that translation every single time.
The team shifted focus from additional training to structural IA improvements and task-aligned navigation within the platform.
Findings aligned product, design and operational leadership around restructuring the platform rather than expanding training programmes across 35,000 users.
Task flows and IA were restructured around how operational staff think about their work, not how the system's internal categories were arranged.
Was there enough of a shared need to justify building one platform for everyone, or were teams actually solving different enough problems that a single solution would not work?
Several teams across different government departments were independently building tools to manage information sharing with external stakeholders. A proposal was on the table to consolidate everything into a single shared platform. Rather than going straight into fieldwork, I worked collaboratively with the programme team first to establish what the research actually needed to answer, and whether the question being asked was even the right one. That meant slowing down before speeding up, which is not always a comfortable conversation. But it shaped the entire approach and meant the research addressed the real decision, not the assumed one.
Teams shared some pain points, but when you looked closely at the detail, the governance requirements and trust constraints were too different to support one standardised solution.
The assumption of similarity came from the high-level problem description, not from how the work actually ran day to day. What counted as a valid sharing decision, who needed to sign it off, and what risk looked like were all quite different across teams. Building to one team's model would have meant the others had to bend their processes to fit a platform that was never designed for them.
The programme narrowed the scope of the shared platform to a well-evidenced set of common needs rather than standardising across all workflows.
Research surfaced the governance and trust differences early enough to reshape the scope before build began, which saved the programme from some expensive assumptions further down the line.
Teams with divergent needs had a clear basis for separate tooling decisions, reducing ambiguity about what the shared platform was expected to do.
Was low completion and high caseworker demand a usability problem, a content problem, or something more fundamental about how the service was making people feel?
Application completion rates were lower than expected and caseworker demand remained stubbornly high. Rather than going straight into user sessions, I started by reviewing complaints data from AtW agents, the frontline staff absorbing the frustration every day, alongside social media posts where users were openly and publicly describing their experience of the service. Both sources told a consistent story before a single research session had been run. They also helped me identify who most needed to be heard and shaped how I approached participant recruitment. That groundwork meant the formal research phase was sharper, faster, and harder to argue with.
The service was communicating, through its language, its design and its processes, that disabled people were a problem to be managed, not citizens entitled to support.
The form used language users described as abrupt and negative: words like "problem", "condition", "who can speak for you". Deaf users could not complete it without a BSL interpreter. There was no save-and-resume, no progress indicator, no accessible alternative formats clearly signposted. Case managers were perceived as inconsistent and lacking empathy. People did not feel included. They wanted what everyone else wants: clarity, dignity, and a service that meets them where they are.
The team prioritised a full content review, replacing deficit-framing language with inclusive, empowering alternatives throughout the application journey.
Accessibility needs were treated as a design priority from the start, not retrofitted. Recommendations included BSL-accessible routes, alternative formats, and accessible UI patterns throughout.
Findings spanned the digital form, the offline process and case manager interactions, giving the programme a joined-up picture of where the service was falling short of its users' actual needs.
The kinds of problems I am brought in to untangle, the decisions I help teams make, and where I add the most value.
A recurring part of my role is helping teams move past performative user-centredness and make decisions that actually reflect user evidence. I translate research into language that works for product owners, policy leads and senior stakeholders, not just designers and researchers.
I mentor researchers on judgement as much as method: what to study, what matters in the findings, and how to make sure the work changes something. That applies to junior researchers finding their feet and to mid-level researchers trying to increase their influence.
I regularly facilitate workshops with multidisciplinary teams, from research synthesis sessions to stakeholder alignment workshops. I am comfortable holding the room across seniority levels and keeping things moving toward a decision.
I have served on GDS Service Standard assessment panels reviewing government services across discovery, alpha, beta and live stages, both as a civil servant and throughout my contracting work. Assessment is a quality function: it is about making sure teams have genuinely understood their users and built the right thing, and I take that seriously.
I have worked mainly across government platforms and complex operational systems, with earlier experience in financial services. Most of my roles have required research to feed directly into product and programme decisions.
“Adeola and I worked together doing product discovery on a knowledge sharing hub for the Welsh public sector. She managed the research expertly. Her adaptability and willingness to collaborate meant the research uncovered some really useful insights in a short timeframe. The work genuinely shaped the direction of the project.”
“Deola is a highly experienced researcher. I was impressed not only with her competency and experience in UR and UX but also with how she communicates her work across the business and with external stakeholders. I highly recommend Deola.”
“While at GDS, Deola brought her commercial and strategic expertise to projects while helping teams to be user centric. She can help teams to grasp the problems they face and to consider the bigger picture.”
“I worked with Adeola for a number of years. She was a calm and professional user researcher who provided real value to the work we did on strategic government projects, delivering outcomes that had a direct impact on the direction we took.”
I specialise in complex public services and enterprise systems, working out where services are failing users and making sure that evidence gets to the people who can act on it.
I do not use a standard research template. I assess each situation and work with the team to make sure we are doing the right research, with the right people, at the right time. That often means going beyond conventional methods. Complaints data, social media, chat logs and customer engagement data can reveal the emotional reality of a service long before you run a single session. I use these sources to sharpen research questions and identify who most needs to be heard.
Prototype testing is central to how I work. I push teams to test early and iterate, because it is the most practical way to avoid building the wrong thing. Accessibility and inclusion work the same way: built in from the start, not retrofitted when it is expensive to change.
I have participated in GDS Service Standard assessment panels across discovery, alpha, beta and live. I received formal assessor training as a civil servant and have continued to take part throughout my contracting work.
I like to work with people who are curious about what is really happening in their services, and open to changing direction when the evidence points somewhere unexpected.
Alongside my research work, I founded Pink Dynasty, a registered UK charity working to open up leadership, entrepreneurship and meaningful careers to young women from underrepresented backgrounds.
The work focuses on widening access to opportunity through practical support, community and pathways into leadership and meaningful careers. It started from a belief that access to opportunity should not depend on who you already know. That same belief shapes how I approach research: looking for the structural barriers that shape people's experiences, not just their surface-level behaviour.