CLIENT:
MAJOR INSURANCE COMPANY
ROLE:
EXPERIENCE DESIGN MANAGER
DURATION:
1.5 YEARS
TEAM SIZE:
7 PEOPLE
Rebuilding insurance for 300+ offices
about.
300+ offices. 12 areas. One portal no one liked.
A major insurance company with 300+ partner offices across Greece. Tied partners, independent partners, brokerage firms, each with hierarchical company structures from unit managers down to secretaries. Twelve functional areas in one portal. Hundreds of daily users. A waterfall culture that had never experienced service design or agile methodology. And a previous portal everyone relied on but no one liked; legacy, fragmented, and held together by paper workflows and spreadsheets.
the project problems.
Most projects solve one problem. This one had to solve two simultaneously — and the harder one wasn't the product
The visible problem: redesign the product.
A portal covering 12 functional areas — from onboarding and new sales to claims and commissions — where core processes were incomplete or missing, forcing partners into paper workflows, spreadsheets, and manual tracking.
The real problem: redesign the organisation.
A waterfall-native company that had never seen agile, service design, or user-centred methodology. They didn't distrust our designs — they didn't have a frame for evaluating them. If we shipped the right product into the wrong process, the design would die on delivery.
The budget was extremely limited. Organisational politics ran deep — on both the client and consultancy side. And the team was small. Every decision had to serve both problems at once.
redesigning the research.
Fifty stakeholders wanted a voice. The budget said no.
STRATEGIC DECISION 01
Redesigning the research to fit the politics
Standard playbook would have been one unified research stream across all stakeholders. The politics didn't allow it — partners were the under-served majority, but internal stakeholders held budget and product power. So I split the research into two parallel tracks calibrated to each group's stakes. Partners got deep qualitative — twenty in-context interviews across tied partners, independents, and brokerages, with job-shadowing where they would let us. Internal got lean quantitative — a 47-response survey instrumented to surface volume and severity, fast.
We then unified both into a single journey map that showed where the two groups' pain overlapped, where they diverged, and which fixes served both at once. The map was the artefact that finally made the trade-offs visible to leadership. We closed the research phase with a co-design workshop — partners, internal stakeholders, our team in one room. The clients didn't realise it at the time, but the workshop was also a stealth introduction to user-centred methodology. They left believing they had helped run it.
20
INTERNAL SURVEY RESPONSES
47
210+
7
CO-DESIGN GROUPS
12
We went to the partner offices.
Not a survey. Not a remote call. We sat with the people who used the portal eight hours a day and watched them work.
VIVID RESEARCH MOMENT
I watched an agent try to check the status of a single claim. He had the claim open in one browser tab, the policy in another, a chain of emails with the claims adjudicator and insurance surveyor in a third, a folder of the client's supporting documents on his desktop, and his own handwritten discussion notes beside the keyboard. To keep track of where each claim stood, he was using a personal spreadsheet in a tool outside the portal entirely, because the existing system only tracked tasks for policies, not claims.
partner testimonial.
I don't need a smarter system. I just need one that doesn't make me look incompetent in front of my client.
Marianna
Tied Agent, Insurance Company
building the bridge.
Solving the visible problem (the product) was now a matter of execution. Solving the real problem (the organisation) required two more interventions before a single screen could be designed.
STRATEGIC DECISION 02
Changing the deliverable to build client trust
The contract specified sitemap-level information architecture. I argued — and won — for upgrading the deliverable to wireframe-level IA with embedded user-flow logic for every primary task across the twelve functional areas. The cost was real: more design hours up front, against a tight budget. The trade was a deliverable the client could actually evaluate. A sitemap is a list of nouns. A wireframe with flow shows the verbs — what the agent does, in what order, with what consequence.
That trade paid back twice. First, in trust: stakeholders who had never reviewed UX work before suddenly had something concrete to react to, and their feedback became sharper and more specific. Second, in sprint velocity: when the build phase started, every sprint inherited a wireframe that had already been pressure-tested with users and signed off by the business. The "what should this screen do" debates that usually consume the first half of every sprint were already resolved. We shipped faster because we'd front-loaded the conflict.
STRATEGIC DECISION 03
Building a bridge from waterfall to agile
The client had never run an agile project. The consultancy expected a waterfall delivery. Forcing either pure model would have failed — pure agile would have spooked the client, pure waterfall would have killed iteration. I coached the business analyst on lightweight agile rituals, then designed a hybrid: waterfall-shaped phase gates that the client recognised, with two-week sprints living inside each gate. Sprint reviews were reframed as "stakeholder readouts" — same content, language the client already trusted.
Every presentation became a training moment. Before walking into a sprint review, I'd brief stakeholders on what we were going to show, why we were testing it before building, and what their decision in the room would unlock. I never used the word "agile" once. By month four, the same product owner who had opened our engagement asking to be shown final screens was asking — unprompted — to test prototypes with agents before we built anything. The methodology had embedded itself. They didn't think they were doing agile. They were just running their projects better.
The moment it landed.
It was the seventh sprint review. We'd brought a clickable prototype of the claims file with the multi-stakeholder timeline. The product owner was there, two senior managers from the operations side, and the claims department head — the same person who had spent our first kickoff meeting telling me that "design is what you do at the end."
Before I could open the demo, she stopped me…
Wait. Before you walk us through it — can we get this in front of two or three of the agents in Athens first? I'd rather see them try it than have you tell us it works.
Ioanna
Head of Claims, Insurance company
I didn't say anything for a moment. The whole team caught it. We rescheduled the review for the following week and ran the test in Athens on the Wednesday.
Three months earlier, the same stakeholder had said:
"Just tell us what the screens look like — we'll figure out the rest in build."
the portal shell.
The structural decision I personally owned.
How do 300+ partners — with three different business models and five levels of hierarchy — navigate twelve functional areas without drowning?
The manager
Needs breadth. Reporting across the entire team. Sales progress per person. Accurate data to award the best agent prize. Oversight of every functional area. The instinct: show everything.
The agent
Needs focus. A clear view of their own tasks, their own policies, their own claims. The autonomy to change a policy, follow a claim's progress, and handle the whole process without leaving the portal. The instinct: show only what's mine.
The client's instinct was to show everything to everyone. We fought for a task-driven, role-based architecture instead — one that surfaces what matters to your role, your tasks, and your day. The manager gets breadth. The agent gets focus. Neither gets overwhelmed.
Moreover, AI set the starting line at research phase, not the conclusions. It flattened a distinction that turned out to be the whole project: it wanted to merge "claims tracking" with "policy tracking" — when the entire diagnosis hinged on claims having no task management at all. The time AI saved went straight back into deeper fieldwork.
the claims workflow.
Design response.
Rather than showing all twelve functional areas at thumbnail size, here's the one that mattered most: the workflow that was held together by email, paper, and memory. Remember the agent in Athens (the one with five browser tabs, the email chains, and the personal spreadsheet)? That was a claims agent. Claims involved four to five stakeholders (partner agent, claims adjudicator, insurance surveyor, insured client, sometimes legal). Every exchange happened via email and phone. The portal tracked tasks only for policies . Claims had no task management at all. The agent's workaround was the clearest signal: the platform had a hole where claims management should have been. Three new capabilities, designed to replace the entire email-and-paper workflow:
components.
Accessible design system
A component library built to WCAG 2.1 AA standards, covering twelve functional areas with consistent patterns — from dense data tables to mobile touch targets. Designed so that a partner navigating claims at 9am uses the same visual language as one processing payments at 4pm. Consistency across 300+ offices meant less training, fewer support tickets, and a handoff package the client's internal dev team could implement without ambiguity.
COMPONENT 01
Buttons system
Three tiers — filled, outlined, minimal — designed for a portal where users make consequential decisions dozens of times a day: approving claims, submitting policies, processing payments. In an interface this dense, we couldn't rely on colour alone to communicate hierarchy. The filled button says "do this." The outlined says "or this." The minimal says "and here's more if you need it." Four sizes scale from compact table rows to full-width mobile touch targets. Focus states meet WCAG 2.1 AA — critical for power users who navigate the portal entirely by keyboard. One primary per view, always. If everything is important, nothing is.
COMPONENT 02
Form fields
Text inputs, dropdowns, search-and-select, multi-select, date pickers — a full form library designed for speed under pressure. Every field carries five unambiguous states so an agent filling out their tenth claim form of the day never wonders whether an input registered. Search is built into select fields by default — because insurance dropdowns can contain hundreds of entries and no one should scroll through all of them. Multi-select uses a clean "+2" counter to stay readable at any width. Built for people with a client on the phone and no time to second-click.
COMPONENT 03
Data tables
The portal's workhorse — policies, claims, quotations, payments all live in tables. Rows adapt to any number of columns with horizontal scroll for overflow, so dense data stays in one scannable line instead of wrapping into unreadable blocks. Bulk selection with checkbox support. Inline actions via contextual menus. Status badges colour- coded by urgency — "requires action" stands out at a glance across a list of fifty. Five row states (default, hover, selected, inactive, inactive hover) so the agent always knows what they're looking at and what they can act on. Built for the person who opens this table thirty times a day and needs to find the one row that matters in under two seconds.
COMPONENT 04
Status badges
Four states. Four colours. No legend needed. Green means "this needs you now." Yellow means "the insurer is working on it." Orange means "waiting on the client." Grey means "done." In a portal where an agent scans thirty claims before their first coffee, the status system had to communicate priority at the speed of peripheral vision — not after reading a label. Colour-blind accessible pairings ensure the hierarchy holds without relying on hue alone. Every list, every table, every task view uses the same four badges — so the language of urgency is identical whether you're in claims, policies, or payments.
COMPONENT 05
Claims timeline
The component that replaced three browser tabs, six e-mail threads and fifteen phone calls. Every touchpoint in a claim's life — from the agent's initial filing to surveyor assignment to adjudicator review to payment — tracked in a single vertical thread. Each entry shows who acted, when, how long it took, what documents were attached, and what's still pending. Contact details inline so the agent can call or email a stakeholder directly from the timeline without looking them up. Status badges and time-on-task make bottlenecks visible — if a surveyor assignment has been sitting for ten days, the timeline shows it, not a colleague mentioning it in passing. Designed so that when a client calls asking "where is my claim," the answer takes five seconds, not five tabs.
the outcome.
Beyond the numbers, the true transformation was in the organizational mindset. We shifted the product team from "What can we build?" to "What should we solve?". Today, research is a mandatory step in their quarterly planning, and the partner offices have a direct line to the design team.
hours saved / year
82% task completion across 300+ partner offices — ~22 min saved per partner-facing task × 2 tasks/day × 220 days. [est.]
/year support cost deflected
SUS at 80th percentile → ~38% fewer inbound support tickets from the partner network. [est.]
/year legacy tools retired
Replaced 4 separate legacy tools with one unified portal — saving license and integration costs. [est.]
validation.
I used to keep a notebook just for claim status. I haven't opened it since we got the timeline. The portal finally remembers what I'm doing.
Anonymus
Usability Test Participant, Partner agent
future thinking.
What I'd build next
If I were the sole decision-maker today, I'd rebuild the partner portal around an intent-based layer.
Partners describe what they're trying to do — renew a policy, resolve a claim, onboard a client — and the system composes the task from the existing functional areas, rather than asking the user to navigate twelve silos.
Power users still get direct access to the underlying functional areas. But the default experience becomes a conversation with the portal, not a navigation exercise.
my role & team.
A team of 7. A client of 300. Both needed building.
Experience Design Manager — leading a team of 7 and hands-on across research, design, and delivery. I grew the team from 3 to 7 on a business case I built myself, then reshaped how it worked: from siloed handoffs to cross-disciplinary co-creation between design, business analysis, and project management. Every deliverable was a training moment — for my team learning to collaborate, and for a client learning to think in evidence.
I led
_Team resourcing & growth (3 → 7, business case built)
_Sprint planning & project timelines
_Cost estimation & budget management
_Managing & mentoring team members
_Team training programme (agile methods, co-design, presenting)
_Strategic decisions (with Director)
_Client relationship management
_Methodology adaptation for client maturity
_Cross-functional process design (design + BA + PM + dev)
_C-level stakeholder management
I did
_Mixed-methods research programme (20+ partner interviews, on-site)
_Analysis & synthesis (210+ pain points mapped)
_Co-design workshop facilitation
_Feature prioritisation
_Market research & competitor analysis (7 competitors, 150+ UI captures)
_Information architecture
_User flows
_Design concept
_Accessible design system (WCAG 2.1 AA)
_Usability testing (qual)
_Reporting & presenting to C-level
reflection.
If I were running this engagement again from day one, the single change I'd make is formalising the organisational-change work as a separate, named workstream — not something I delivered in the margins of design. I treated waterfall-to-agile transition as a side-effect of good UX practice. It worked, but it was fragile, undocumented, and dependent on me. Naming it would have unlocked a budget line, a co-owner from the client side, and a handover that survived past my last day on the project.
