Overview

Segstream's design system, rebuilt so that every colour, size, radius and typeface lives in a variable. Version 2.0 ships 40 component sets at 485 variants, 416 variables across seven collections, 23 text styles and a local 54-glyph icon set, with two colour modes and three density modes throughout. The organising promise is simple: one token edit moves the entire product — every component, every screen, both modes — with no manual cleanup afterwards.

The Challenge

The original file had 19 component sets and 245 variables, and it had drifted. Colour was bound directly to primitives in places, so a brand change meant hunting through components rather than editing a ramp. Dark mode existed in name only. There was no icon set, and the documentation was built from raw hex values that quietly disagreed with the components they described. Rethemeing was manual work with no way to know when it was finished.

The Solution

A three-tier token architecture, held together by one rule: a component never binds to a primitive. Raw hex lives in a hidden primitives collection. A semantic layer — background, foreground, border, brand, status, shadow — carries both modes and aliases those primitives. Component tokens alias the semantic and layout tiers in turn. On top of that structure, an entire retheme collapses to five edits: the brand ramp, an optional neutral ramp, two font families, three radius values, and a single logo component.

Design Process

Inside the System

Templates are assembled only from instances, so every screen below inherits the same tokens — change the ramp and all of them move together.

Explore the Live File

The screenshots above are stills. The file itself is browsable — every page, component set, variant and token, in both colour modes.

Prefer a new tab? Open it in Figma.

Results & Impact

Key Learnings

• If something cannot be changed through a property, that is a gap in the component — not a reason to detach. Exposing every visible property is what keeps instances intact.
• Composition beats redrawing. A modal footer holds real Button instances; redrawing a component inside another quietly breaks the token chain that everything else depends on.
• An overridden font size survives happily until the scale changes, then silently disagrees with everything around it. Binding every text node to a style avoids a class of bug that is invisible until it is everywhere.
• Density and breakpoint belong on the page frame, not on individual components. Setting them per component is how a system starts to contradict itself.
• Documentation that renders from live tokens cannot drift. Documentation built from copied values always does.
• State the limits in the open. Success, warning and error keep their own colour scales because Figma variables cannot compute colour — recolouring them means editing 33 more stops. Writing that down is better than letting the next person discover it halfway through a rebrand.

Overview

Plenty of EastWest Bank customers also hold an EastWest Ageas life insurance policy — but the two lived apart. Checking a policy meant leaving the banking app, remembering a second set of credentials, and signing into an insurance site built for a different purpose. Most people simply never looked. This project brings those policies into the app customers already open daily, and designs the whole connection: who you say you are, what you agree to, and what happens when any part of it goes wrong.

The Challenge

Linking a bank account to an insurer is only partly a technical problem. It is mostly a trust problem. The flow has to prove identity convincingly enough to justify showing financial products, ask for consent in language a person can actually read, and never strand someone when a policy number is mistyped, a one-time code expires, or the insurer's system stops answering. The happy path is the short part of this work — the failures are where the experience is won or lost, and they are usually the part nobody draws.

The Solution

One clear journey — prompt, consent, policy number, one-time code, handoff — with every branch off it designed rather than left for the back end to explain. Friction is sized to consequence: linking moves quickly, unlinking stops to confirm. Failures are separated by cause, so a wrong code and an expired code say different things and offer different ways forward. Contact details are validated at the point of entry instead of failing silently later. And a customer who holds no policy meets a short introduction rather than a locked door.

Design Process

Inside the Cross-Sell

The cross-sell is where linking stops being plumbing and starts earning its place: a customer with no Ageas policy meets an offer on the dashboard, agrees to share their details, and becomes a warm lead for an advisor — without filling in an insurance application inside a banking app.

Explore the Live File

Every flow, state and annotation on one board — including the edge cases that rarely make it into a portfolio.

Prefer a new tab? Open it in Figma.

Results & Impact

What this changes for the person holding the policy.

Key Learnings

• Friction should be proportional to consequence. Linking a policy can be quick; unlinking one should not be, because the person who pays for a mistaken tap is the customer.
• Two different failures deserve two different messages. Collapsing "wrong code" and "expired code" into one generic error tells someone that something broke without telling them what to do about it.
• Validating contact details at the point of entry prevents the worst kind of failure — the silent one, where a confirmation is sent somewhere the customer will never see it.
• A refusal without a route out is a dead end. Naming the reason and offering the next step turns a stopped journey into a recoverable one.
• Replaying the whole journey against a failing back end is the fastest way to find the states nobody designed.
• Annotating a large flow in the file itself — numbered steps, lettered branches, lanes for phases — means engineering can read a path without a meeting to explain it.

Overview

Entrego is a Philippine logistics company, and myEntrego is how its customers actually reach it — booking a delivery, paying for it, and tracking where the parcel has got to. This was mine from the first interview to the last screen: research and personas, a journey map, the information architecture, the booking flow, and 113 designed screens. It shipped to both app stores and settled at around 4.8 stars, with parcel tracking pulling the most repeat traffic.

The Challenge

Sending a parcel through a logistics provider meant phone calls, guesswork about cost, and no way to know where anything was once it left your hands. The research made the friction specific rather than general: booking took too many steps, addresses were hard to pin down, and the bill could not be read in full. The app also had to make sense to two very different people — a seller running a small business from her phone, and a courier who had spent ten years on a motorcycle and described himself as afraid of technology.

The Solution

Every significant decision traces back to something a real user said. Booking became a guided flow with saved addresses, so the second delivery is far quicker than the first. A shipping fee calculator puts the cost up front, before anyone commits. And tracking was made available without logging in at all — the thing people do most often became the thing that asks least of them, which is what turned it into the app's most returned-to screen.

Design Process

Inside the Work

The research artefacts and the screens they produced, in the order they happened.

Explore the Live File

Research, flows and all 113 screens on one canvas.

Prefer a new tab? Open it in Figma.

Results & Impact

What shipped, and what it changed for the person sending a parcel.

Key Learnings

• Personas built from gathered data change what gets built; invented ones just decorate a deck. Rica's three frustrations became three features — saved addresses, a fee calculator, and readable billing.
• Running a feelings lane beside the actions turns a journey map into a brief. The dips are the work; everything else is context.
• Designing for the person who calls himself afraid of technology is the most useful constraint available. If the flow holds for Roger, it holds for everyone above him.
• Putting tracking behind a login would have protected a sign-up metric and lost the habit. The thing people do most often should ask the least of them.
• Showing cost before commitment removes the most common reason a booking is abandoned halfway.
• Owning the work from research through to launch means nothing is lost in translation between what a user said and what finally shipped.

Overview

KwikCare is health cover sold as a monthly subscription, underwritten by PhilCare and bought inside GCash — the wallet a large share of the Philippines already has open. The work covers the whole commercial path: comparing five plan tiers, understanding what each actually covers, completing a health declaration and document upload, paying from a wallet balance, and then living with the policy afterwards.

The Challenge

Insurance is difficult to sell on a phone for two reasons. The product is hard to compare — benefit limits, exclusions and waiting periods do not fit on a card — and the purchase asks for exactly the things people abandon forms over: identity documents, proof of income, and a declaration about their own health. Doing this inside someone else's app raises the bar again: the flow has to feel like a native part of GCash, or the trust that made the wallet worth using does not carry across to the insurance sitting inside it.

The Solution

Tiers are presented as a comparison rather than a brochure: each plan leads with its price and its maximum benefit limit, then lists what it actually includes. Every tier carries its own covered-and-excluded breakdown instead of one generic table, because the differences between plans are the entire decision. The purchase is cut into four named steps so the length is visible from the start, and the health declaration is kept short and in-flow rather than deferred to a form nobody finishes.

Design Process

Inside the Work

From the wireframes that set the structure through to the specs that shipped it.

Explore the Live File

Wireframes, four design versions, the prototype and the specs, all on one canvas.

Prefer a new tab? Open it in Figma.

Results & Impact

What it changes for someone deciding whether they can afford health cover.

Key Learnings

• Insurance is bought on comparison, not description. Leading each card with price and benefit limit does more for the decision than a page of benefit copy underneath it.
• One shared benefits table hides exactly the thing a buyer is trying to work out. Writing covered and excluded per tier costs more effort and answers the actual question.
• Naming and numbering the steps is the cheapest way to stop a long form feeling endless — people abandon uncertainty more than they abandon length.
• The health declaration is the most fragile moment in the purchase. Short, in-flow, with detail behind a tap, beats a legally complete wall of text nobody reads.
• Document upload deserves real state design — formats, size limits, in-progress, attached. It is where purchases quietly die, and it is usually specified last.
• Selling inside someone else's app means inheriting their trust. The flow has to feel continuous with the wallet, or the credibility does not transfer to the product sitting in it.

Overview

KwikCare sells subscription health plans online. The plan listing is the page where the decision actually happens — it is where someone works out which plan they can afford and what it covers, and it is the last page before the product detail and the enrolment flow. This is a redesign of that page at both breakpoints, including the states it enters when there is nothing to show and nothing yet loaded.

The Challenge

The live page listed plans without letting anyone compare them. Every card carried the same block of coverage copy — identical eligibility wording repeated five times — so the differences between plans, which are the entire decision, were buried in text that read the same on every row. Price sat small and right-aligned, competing with a button rather than leading the card. The filters were a column of radio buttons and checkboxes behind an Apply button, so narrowing the list cost a round trip. Nothing marked which plan most people take.

The Solution

Price leads now, at the size of a headline, because affordability is the first question and there is no reason to make anyone hunt for it. Each card carries three benefits written for that plan rather than one block of shared boilerplate, so scanning down the row surfaces difference instead of sameness. The popular plan is labelled. Filters apply live against a running count, and the budget range — six radio buttons on the old page — became a single slider. The empty and loading states are designed rather than inherited.

Design Process

Before & After

The same page, same plans, same catalogue. What changed is what the page makes easy.

Inside the Work

Three states at each breakpoint, because a listing page is only in its default state some of the time.

Results & Impact

What the page does differently, stated as what changed rather than what was made.

Key Learnings

• Copy repeated identically on every card is worse than no copy at all. It costs vertical space, slows the scan, and actively hides the differences a buyer is trying to find.
• An Apply button turns filtering into a commitment. Live results against a running count let someone feel their way to an answer instead of guessing and submitting.
• The right filter pattern is not the same on both breakpoints. Live on desktop where the list and the controls are visible together; batched on mobile, where the sheet covers the results it would be updating.
• Marking the popular plan is not a nudge so much as a kindness — most people would rather be told what is reasonable than become an expert in benefit limits.
• Empty states should name the cause. "No results" is a dead end; "your budget is too narrow, here is how to widen it" is a route back into the catalogue.
• Skeletons shaped like the real card stop the layout jumping on arrival. A spinner tells you to wait; a skeleton tells you what is coming.

Overview

The Timemore Dot is a coffee scale about the size of a coaster. It has no screen of its own — it sends the weight and the time to your phone instead. The hardware is genuinely nice. The app that comes with it is where it falls down: it shows you plenty of numbers, but it never helps you use them. This is the app I built to replace it.

The Challenge

Making pour-over coffee is a timed routine. You pour water up to 90 grams by 40 seconds, stop, wait, then pour up to 135 grams by 1:20. The app knows the weight. It knows the time. It never puts the two together.

So you end up keeping track yourself, while both hands are busy holding a kettle. Is it time yet? Am I there yet? Do I stop now?

It trips up two kinds of people for the same reason. If you are new, you do not know the routine, and the app cannot help because it has no idea what you are making. If you have done this for years, you know the routine but you are still doing sums mid-pour — the recipe says stop at 90, the screen says 62, so you are subtracting in your head, over and over, with wet hands.

The app tells you what is happening. What you actually need is what to do next.

The App It Replaces

This is what comes in the box, and it is worth looking at closely, because most of what is wrong with it is wrong in a quiet way.

Four things are missing, and together they are the whole reason I built something else.

• A picture where the information should be. The biggest thing on screen is a drawing of a brewer. It looks exactly the same when the cup is empty as when it is full, so it tells you nothing — and it is sitting in the spot your eyes go to first.
• Numbers, but no advice. Around it you get the weight, the flow rate and a timer. All of them are true. Not one of them tells you what to do.
• No recipe anywhere in it. The app has no idea you are aiming for 90 grams at 40 seconds, so it cannot tell you that you are getting close, and it cannot tell you to stop. Nobody ever told it where you were going.
• A timer you have to press. You start it yourself, with a full kettle in your hand, which costs you a few seconds at the exact moment you can least spare them.

The Solution

The biggest number on my screen changes depending on what you are doing.

While you are pouring, it shows how many grams you have left, counting down to zero. While you are waiting, it shows how many seconds until the next pour. The weight is still there, just smaller, for when you want to check it.

That is really the whole idea: the app does the sums so you do not have to.

Everything else follows from it. A pour finishes when the scale says you got there, not when a timer guesses. The card changes colour so you can read it from across the kitchen. Four different sounds cover the moments your eyes are on the coffee and not the phone. And the timer starts itself the moment water hits the scale, so there is nothing to press.

How I Got There

Inside the Work

Here it is running. Watch the big number: while you pour it counts grams down to zero, and the moment you are done it flips to counting the seconds until the next one.

A recording of the live app, running at double speed. No scale connected here, so it works off the clock — watch the big number switch between grams left while you pour and seconds left while you wait.

Building It With AI

I would rather be straight about this than pretend I hand-wrote three thousand lines of Bluetooth code. I decided what it should do and how it should behave. The model wrote most of the code, and when I asked it to go looking for problems, it found a few I would otherwise have shipped.

The part that still takes judgement is the same as it has always been: working out which problem is worth solving, what to leave out, and when something is quietly not doing what it claims. It got faster. It did not get easier.

Results & Impact

It is live, it replaced the Timemore app on my phone, and I use it every morning.

What I still cannot claim is proof that it makes better coffee. Two other people using it once is encouraging, not evidence. So I built in the measurement that would settle it: every brew records how far each pour landed from its target, which is the number that should get smaller if the design is doing its job.

The next step is twenty brews, ten on each app, comparing how far off the pours are. If it does not improve, then the prompts are decoration and I will say so right here.

Taking It Out Of My Kitchen

Everything above was me, in my own kitchen, with my own recipe. So I took it to a friend who runs a cafe and handed it to two people who had never seen it before.

Falling Beaker — a small place, and two people who make coffee for other people all day. A harder test than my own kitchen at seven in the morning.

What he took from it was something I had not framed for myself. I had been thinking about it as a tool for one person making one careful cup. He saw it as a way to get the same cup out of different people — the trainees learning the routine by following it, and the experienced staff hitting the same targets they would otherwise be eyeballing. Consistency across a team, rather than help for a beginner.

That is a different product from the one I set out to build, and a bigger one. It also changes what is worth measuring: not just whether my pours get closer to target, but whether two different people pouring the same recipe end up closer to each other.

What the Cafe Sent Back

Five things came out of that visit. The first one overturns the decision this whole case study is built on, which is the best argument I have for showing a thing to people instead of admiring it on your own bench.

• The number should count up, not down. I had the big number showing grams remaining, falling to zero, because that takes the subtraction off you. Every barista there read it the other way round. They have spent thousands of pours watching a scale climb towards a target, and asking them to flip that habit costs more than the arithmetic it was saving. The app still does the sums — it should just show the half they already know how to read.
• A cue before the stop, not only at it. Arriving at the target at full flow means going past it. A signal as you come into the last few grams makes you ease off, so the pour lands rather than slams. Sound does part of this today; doing it properly wants a buzz in your hand, which is one of the things a browser cannot reach on an iPhone.
• Record a brew as you make it. Not everyone works from a recipe. Some pour by feel and only afterwards want to keep what they just did. That runs the whole flow backwards — the app watching instead of instructing — and it is how a signature brew actually gets written down rather than half-remembered.
• The Hario Switch needs its own kind of step. A switch dripper steeps and then releases, so the hold is not a gap between pours — it is the brew. My recipe model assumes pour, wait, pour. It needs a step that means closed, and a pour that resumes when you open it again.
• A log that can explain itself. Grind size, bean, dripper, grinder, filter, water temperature. Without them a logged brew can tell you a pour missed by four grams but never why, which makes it a receipt rather than something you can learn from.

The last one matters most for the test I still owe. Overshoot on its own is a thin number; overshoot next to the grind and the dripper is the start of knowing what actually moves it.

Try It

Overview

Manulife's Customer Website is where policy owners in Singapore manage what they already have. The referral module adds something different: a way for a happy customer to introduce a friend, with a reward on both sides once that friend actually becomes a customer. I designed the module end to end — where it gets offered, what the referrer sees, what the friend lands on, and the rules that hold the whole thing together.

The Challenge

A referral is a favour you ask of someone. Ask at the wrong moment and it reads as a sales pitch dressed up as a thank-you; ask badly and the person on the receiving end feels sold to by their own friend. Both are easy to do and hard to undo.

There were three places the business wanted to offer it, and they are not the same situation at all:

• After a tNPS survey. Someone has just told us they would recommend us. That is the warmest moment there is — and also the one where a reward offer can cheapen what they just said.
• Inside the website. No trigger, no warm moment. Just an entry point that has to explain itself from cold to someone who came to pay a premium.
• Around a Financial Needs Analysis. A consultant is already involved, so the referral is half a conversation and half a product — and the two must not contradict each other.

Underneath all three sits the harder half. A referral only works if the friend shows up, and in insurance that means handing a stranger's phone number to someone who sells for a living. Get the consent wrong and it is not just rude, it is a regulatory problem.

The Solution

One flow, three doors into it. The entry points differ in tone and timing; the machinery behind them — eligibility, consent, link generation, consultant assignment, reward — is the same in every case.

The referral is to a person, not a company. The referrer picks which financial consultant they are vouching for, and that choice carries all the way through to what their friend sees. And the friend's page leads with who sent them and what will actually happen next, before it asks for anything.

Three Ways In

I mapped each entry point as a service blueprint before designing a screen — referrer on one lane, the friend on another, and the system work underneath. It is the only way to see that three different front doors can share one set of rules, and the only way to spot where a reward is promised before anyone has checked it can be paid.

The blueprints did something else useful: they gave the business a thing to argue with. Stakeholders who will not read a spec will happily tell you a lane is wrong.

The Storyboard

A blueprint tells you what happens. It does not tell you what it feels like to be asked for a favour by your insurer, which is the part of this that could go wrong without a single lane being incorrect. So the same flow got told a second way — a cast of three, and the journey as scenes, each one tagged with whose turn it is. Each story runs left to right; drag it, or use the arrows.

Design Process

Inside the Work

The referrer's side, the moment it changes state, and what the friend actually lands on.

Results & Impact

Shipped on the Customer Website, with the same rules behind every entry point.

What I Took From It

• Consent is a structural decision. Treated as small print it is a checkbox under a button. Treated as structure it decides what the page can do and when — and the version that gates the action is both the compliant one and the clearer one.
• A referral has two users and only one of them is your customer. The friend never agreed to anything, never heard of the programme, and owes you nothing. Designing their page first would have been the better order.
• The warmest moment is the most fragile one. Immediately after someone says they would recommend you is when they are most likely to refer and most likely to feel used. The offer has to read as a way to act on what they just said, not as a reward for saying it.
• Blueprints and storyboards are not the same tool. One answers what happens and where it can break; the other answers what this feels like and whose turn it is. Bringing the wrong one into a room costs you the meeting.
• Sharing belongs outside the product. People refer friends in the places they already talk to them. Our job stopped at producing a link worth sending.

Overview

When I joined AIA, they had grown from 5 to 50 designers in 18 months. Their product had evolved organically, resulting in inconsistent UI patterns, duplicated components, and a development process that was slowing down with each new feature. I was tasked with creating a comprehensive design system that would scale with the company's rapid growth.

The Challenge

The main challenge was creating a system that could adapt to different regions while being flexible enough to accommodate rapid feature development. We needed to establish design principles, create a token system, build the component library, and migrate existing products without disrupting ongoing development.

The Solution

I led the creation of a comprehensive design system built on atomic design principles. We established a robust token system, created extensive component documentation, and implemented a phased migration strategy that allowed teams to adopt the system gradually.

Design Process

Inside the System

Every component ships as documentation rather than just a symbol — what it is for, how it behaves, and which platforms have it ready. Each page carries its own version and a resource row covering the Figma kit, React, Vue, AEM and React Native, so a designer and an engineer can check the same page and get the same answer.

Explore the Live File

The crops above are stills. The system itself is 59 pages — principles, foundations, and a documented page for every component, each carrying its build status across Figma, React, Vue, AEM and React Native.

Prefer a new tab? Open it in Figma.

Results & Impact

Key Learnings

• Early collaboration with engineering teams is crucial for creating components that are both design-forward and developer-friendly.
• Incremental adoption works better than big-bang migrations — teams can adopt the system at their own pace while seeing immediate benefits.
• Documentation is just as important as the components themselves — clear guidelines prevent misuse and ensure consistency.
• Building a governance process early helps maintain system quality as it scales and more contributors join.
• Regular audit cycles help identify gaps and opportunities for improvement as the product evolves.
• Token systems provide flexibility for theming and ensure visual consistency across all components and products.