Thoughtful design for products that matter.feel right.people love.drive impact.help others.matter.

Four steps, no manual input

Six modules, one plugin

The logic that makes the output trustworthy

Anyone can write a plugin that "kind of works." Making one designers will actually trust at handoff is the harder problem. The six modules above ship eight distinct features, and here's the logic running under each one.

Small touches that make it trustworthy

The work nobody notices is what stops a plugin from feeling broken. Hidden layers are skipped so they don't show up in the output. Missing fonts fall back gracefully instead of crashing. Backgrounds are pulled from the right parent, never from a grandparent that happens to have a fill. These are the details that take a plugin from "demo" to "the team uses it every day."

What success looked like

The plugin moved from prototype to daily-use tool quickly because it earned designers' trust on real handoffs. The numbers below are what success looked like for the rollout.

Designers should be sparking ideas, not auditing pixels

As a principal, I started seeing what individual designers couldn't see from inside their own sprint: the same handful of accuracy checks were happening on every single handoff, by every designer, every week. Each one only took 20 to 40 minutes, small enough to feel like "just part of the job." But scaled across the team, the math was brutal. A senior designer's entire week, every week, was being spent on work that wasn't designing. That wasn't a tooling annoyance. That was a leadership signal.

The most expensive workflows in any team aren't the obviously broken ones; they're the ones that have been around long enough to become invisible. "We always stress-test max characters by hand." "We always re-export specs manually." These weren't bad habits. They used to be best practices. But routines that ossify into standards quietly become the ceiling that keeps designers small. A principal's job isn't to do the routine faster; it's to question whether the routine should exist at all.

Building Design Deliverables wasn't really about saving 3 to 5 hours a week per designer, though it does. It was about reclaiming that headspace for the work that actually makes products great: strategizing user flows, sparking new feature directions, pressure-testing the system, asking the questions only designers can ask. When a designer's calendar is full of mechanical handoff work, they don't have the bandwidth to be the strategic partner the business needs them to be. Automation is how design earns the right to think bigger.

This plugin is one small instance of a thesis I now apply to every design routine I see: if it can be specified, it can be automated; if it can be automated, it shouldn't be a designer's job. A principal's real role isn't to ship more pixels. It's to clear the runway, so the team can take off. The future of senior design isn't doing the spec faster. It's making the spec disappear entirely, so designers can finally do the work that grows them, the work that grows the product, and the work that grows the business.

The trust gap, and the segment that mattered most

Five phases, from research to ship

Turning five reports into one direction

Four HiLTI personas, four very different decision styles

Three pillars of HiLTI decision-making

How the design team led the initiative

A Mall design baseline, unified for SEA

Mall rebrand applied across 8 surfaces

How HiLTI influenced other projects

Symptoms of a missing shared framework

Questions the principle needed to answer

Six phases, from gathering use cases to shipping the framework

From January to October 2021, Nest evolved through six deliberate phases: gathering use cases across teams, defining principles with tangible actions, piloting them on real projects, refining the concept with stakeholders, launching the framework company-wide, and continuously measuring and evolving it as a living system. Each phase had clear gate criteria, ensuring Nest was grounded in evidence rather than opinions presented as principles.

What Nest decides, guides, and aligns

Nest is the decision-maker for design and experience choices, the guide for Product Designers when they're designing and Product Managers when they're managing, and the aligner that keeps Tokopedia's look and feel consistent across teams. It doesn't replace local context. It gives every team a shared filter to test their context against.

Four principles, expressed as customer truths

Each principle is written as a sentence the customer would say — not as a designer's instruction. This wording forces the team to defend their work from the customer's seat, not from the org chart.

From Soul to Deliverables: one collaboration system

Nest acts as a master documentation linking the Soul (why we design things), the Experience Scope (general → specific), and the Deliverables (component behavior patterns, UI library, code storybook, copywriting, research, design ops, career framework). It's the connective tissue that ensures decisions stay anchored to principles all the way down to handoff.

Three questions to interrogate any design

Every colleague uses Nest the same way: pick a principle the work is supposed to embody, then run the design through three honest questions about context, motivation, and impact. If the design can't answer them clearly, it isn't ready to ship.

Four lenses for principle-driven quality

Each principle has its own measurability lens, so teams can defend decisions with evidence, not taste. Relevant measures how well data is reserved for the right user at the right moment. Reliable measures performance and predictability across the journey. Engaging measures the trigger-action-reward-investment loop and return rate. Empowering measures psychological capital lift: optimism, hope, self-efficacy, and resilience after using the product.

A storefront built for one job, asked to do ten

Six phases, from reading the page to shipping the system

I deliberately spent the first half of this project not designing. The page had been iterated on plenty of times; what it had never had was an agreed diagnosis. Each phase below had to produce something the next phase could actually build on.

Reading the current Shoptab, zone by zone

Before proposing anything, I mapped click-through and conversion onto every region of the page so the team could argue about evidence instead of taste. The headline numbers were healthy; the distribution underneath them was not.

What the rest of the SEA market had already learned

Our own numbers told us the page was underperforming, but not whether that was a TikTok Shop problem or simply how e-commerce homepages behave. Answering that needed a second data set from a comparable market, so I turned to Tokopedia, which runs at similar scale in the same region and shares much of the same audience.

I plotted every Tokopedia homepage module on two axes, banner ↔ product and push & ads ↔ personalised, labelling each with its sessions, CTR and CVR so volume and engagement could be read against each other rather than in isolation. Then I tore down Shopee, Lazada, Blibli and Qoo10 module by module, numbering each homepage in the order its modules appear, to see what every competitor puts first, what they defer, and where they let product take over the page.

Asking why the numbers looked like that

Quantitative data tells you where people stop; it never tells you why. I ran guerilla interviews on-site with colleagues alongside PMs for fast observation, then went into the field to interview real shoppers and check the insight held outside the building.

Two sets of problems, one page to solve them on

Three zones, ordered by how much intent the user arrives with

The page now runs top to bottom from highest intent to lowest: people who know exactly what they want are served first, people who came to see what's on offer next, and people just browsing get the largest surface. Every future module has to declare which zone it belongs to, which is what turned placement from an argument into a rule.

Three decisions the structure made possible

Aligning the product team on how it should feel

We ran a workshop with the product team to agree the visual direction for SEA Shoptab: which layout best accommodates the business needs, and which treatment stays true to TikTok's brand identity. We benchmarked existing visuals, competitor screens, and festivity levels, then committed to four directions.

Space optimised, GMV up across the board

Every zone we restructured moved

Six modules, fifteen businesses, one page

The most durable outcome isn't in the GMV line. The six Shoptab modules now support a scalable design for up to 15 business features and can carry content beyond products, and they became the mechanism used to launch Buy X Get Y, Return More, Live Channel and Flash Sale, the core business focuses for the following two quarters. The page stopped being the constraint.

Background and context

Four phases, from reading the game to shipping a campaign

Because the mechanic was already validated, the work was diagnosis before invention. Each phase had to hand the next one something it could build on, and the last one had a fixed launch date that nothing could move.

What the numbers already proved, and what they exposed

The quantitative picture was mostly good news, which set the constraint for everything that followed: whatever changed could not put a working mechanic at risk. The useful part was not the headline, it was the shape underneath it. Participation was high and completion was not, and reach was far smaller than the performance implied.

Asking users what they thought they were doing

Numbers show where people stop, never why. We ran three days of moderated sessions in Vietnam covering the whole Shoptab gameplay portfolio, with Crack the Egg tested against the other mechanics so preferences could be compared rather than assumed. The good news came first: comprehension of the basic game was near universal. Participants knew what it was, how to play it, where to find it, and several said they would delay an order to the next day rather than buy without cracking first. The problems were not about appeal.

How the rest of the market builds a campaign game

Two teardowns did most of the work. Neither was competing on novelty of mechanic; they were competing on how many small, repeatable tasks they could wrap around a single reward moment.

What we committed to fix

The goal was deliberately short enough to argue against: higher user conversion and simpler user understanding. Two problems, in that order, with everything else treated as a means to one of them. Stating it that tightly gave the team a way to reject good ideas that served neither, which turned out to matter more than any idea we kept.

Success metrics, in three tiers

Netting out cannibalisation in the Tier 1 definition mattered more than it looks. It meant the game could not win by moving existing orders from the homepage feed into the venue; it had to generate demand that was not already there. The third tier is the one that changed how the team worked day to day, because success rate, CTR and CVR each map to a specific screen decision, so a proposal could be judged before it shipped rather than only after the GMV read came back.

Making the main page earn its screen

The old key visual was atmosphere, not function: a static illustration that sat above the actual game while the crack, the reward and the next mission each cut to their own screen. Ranked honestly, the KV mattered less than the loop it was decorating, yet it was taking the most valuable screen real estate on the page.

A 32-day campaign with three clocks running

What the campaign returned

Against a target of a 1% to 3% GMV uplift across the cycle, the campaign delivered +1.46% TTS GMV and +3.72% TTS ROAS. The more durable result is structural. The engine underneath stayed generic while the campaign layer became swappable, and the same three-layer model carried two entirely different cultural mechanics across two markets without a rebuild. The next peak can be dressed rather than built.

Background and context

How we executed

Each step handed the next one something concrete: a list of inefficiencies, a set of principles, a platform, and finally a real collaboration to test it all against.

Defining the problems

We opened with a workshop to collect ideas on how AI could help designers reach the objective at each stage of the design process. The challenge at this stage was that designers were already used to the flow; nothing in it registered as a major pain point. But when we broke the process down one step at a time, the inefficiency became clearly visible. So that is what we did: we listed every inefficiency in our design workflow, stage by stage, including the collaboration steps in between.

Ideation

With the problems named, we split up individually to explore how AI could solve each one and make the process more efficient. After a week of exploration we had the foundation to redefine the AI-assisted design process, and we aligned it around four principles.

Execution: the objectives I own

I own the third and fourth objectives: reducing collaboration confusion, by letting a designer quickly show explorations to collaborate with product managers, and higher-accuracy communication, by having AI produce the specific code for an interaction once the idea is locked, so engineering can build it more accurately. To solve that I defined the flows below, from a designer's first prompt to the code that reaches the tech team.

Evaluate: testing the workflow on real work

To evaluate the new workflow we tried it on real, complex collaboration with the product managers, and aligned with the lead PM to define the future AI direction for TikTok's independent e-commerce app. Once the PMs were aligned on the workflow, we decided to implement it and explore the core journey experience, starting from the touchpoints that carry the key problems on the platform today. The implementation is organised in four parts: the objective we aligned on, the problems we set out to solve, the design principles that filter every idea, and the explorations themselves.

The objective

Working with the lead PM, we aligned on one direction for AI in the independent app before designing anything. The strategy is short enough to fit on one line, and everything below is filtered through it.

The problems we set out to solve

Traditional e-commerce already gives users an overwhelming amount of information. Reading the journey against the strategy surfaced four problems that AI is well placed to fix, and one list of what a shopper is actually being asked to process on the way to a purchase.

The design principles

Three principles turn the strategy into something a designer can check an idea against. Each one comes with what to do and what to avoid, so the explorations that follow can be judged the same way by everyone on the team.

The explorations

We mapped the journey twice, once for a new user and once for a returning user, and marked where Embedded AI could enter at each touchpoint: home and feeds, search, cart, and repurchase from the order list. From that map I took the shopping cart as my own exploration. It is the one surface where a shopper's intent is already explicit, and where the gap between "I want this" and "I bought this" costs the most effort today.

Why the shopping cart

Shoppers use the cart for more than checkout. They store products they like to buy when they need them, park products they need while waiting for a promotion, stage the items they are about to stock up on, and hold candidates side by side to compare before buying. And once they have decided, they want the purchase itself to be as efficient as possible, usually by finding and using the best promotion. Reading the cart that way surfaced four problems.

User scenarios to purchase

Each scenario on the board is written the same way: the situation the user is in, the action the AI takes inside that moment, and the result it produces. Three jobs cover the journey from a full cart to a completed purchase: help the user get organised, help them decide which product to buy right now, and help them complete the purchase.

AI scenarios

The purchase scenarios only work if the AI knows enough about the user to be relevant, and gives the user a way to correct it when it is not. The board also covers how the AI learns the user, how it talks, how it recommends across the user's life cycle, and an extra journey for cleaning up the cart. The demo below shows the whole exploration running as one experience. Every screen and interaction in it was created entirely with the platform I built: instead of static mockups, the AI helped me design a prototype that behaves like the real app, with live data, working states and real transitions, so the team and the PMs could experience the journey rather than imagine it.

Where this landed, and what's next

Walking the PMs through the cart exploration as a working prototype, rather than a deck, is what got them to buy into the new workflow. Both sides came away feeling this way of collaborating meaningfully raised how efficiently design and product work together, since the discussion could happen on the experience itself instead of on what the words were trying to describe. The AI experience direction is still being shaped, not locked, and the next step is scaling this same exploration process to the rest of the core journey.