Tokopedia NEST Design Principles

It started as a throwaway question in a one-on-one with my boss. I asked it half as small talk, not expecting it to go anywhere.

“

What do you think Tokopedia's design is actually like?

Neither of us had a clean answer, and that was the interesting part. What was meant as small talk turned into a conversation that ran past an hour, because the honest answer depended entirely on who you asked. Every tribe had its own implicit sense of what good design meant for its domain. That wasn't a failure, it was what you'd expect from teams solving different problems for different users. But it meant that whenever two tribes had to collaborate, which was constantly, we were negotiating from scratch. There was no shared floor to stand on, no common terminology to agree or disagree within. A lot got lost in translation, not because anyone was wrong, but because we didn't have a shared language to be wrong in.

Tokopedia already had an answer to this problem at the company level. Three DNAs, Focus on Consumer, Growth Mindset, and Make It Happen, Make It Better, sat underneath how the whole company behaved and made decisions. They worked. Not because they were exhaustive, but because they were specific enough to actually change a decision, and shared widely enough that citing them meant something in any room. If that worked for the company, I believed the same shape of thing could work for design specifically, a small set of principles that let One Tokopedia mean something concrete when it came to how we designed, not just what we shipped.

By the end of that hour, my boss handed the question back to me with a flick of fire I didn't see coming.

“

Why don't you find out, and help the whole organization be on the same page, so anyone could easily answer that if it's ever thrown at them?

That landed somewhere competitive in me. I was a few months into being a manager, still learning the job with my own small team, and here was my boss handing me a reason to lead something that reached the entire design org, well past anything I actually owned. I said yes anyway. It turned into one of the most promising things I worked on that year, not because anyone told me to take it seriously, but because I decided to, and because taking on a whole-org project that early into managing people was exactly the kind of stretch I wanted.

The mandate I set for myself, separate from the team I managed day to day: give the design org a shared language for quality, built by the org rather than handed down to it, and durable enough that any tribe could pick it up and make it their own without me in the room.

Before writing a single principle, we wrote down what success would look like:

1. 01Every Tokopedia product looks and feels like one product.
2. 02A daily framework across tribes.
3. 03A filter for the quality of design we ship.

I ran workshops across all 28 tribes with a small group of principal and senior designers pulled in from outside my own team, specifically so the result wouldn't just reflect my own domain. Tribes with similar domains shared a session, so that came to fewer than 20 workshops. In each one, we pulled in the tribe's product, engineering, and business leads, and their teams as well, not just designers, and asked what they believed made a decision good in their domain, what they'd defend, what they'd never compromise on. Every answer became a crucial data point, not a principle yet, just a signal of what a tribe already held to be true whether or not it had ever been written down.

Collected across all tribes, those data points added up to dozens of candidate principles, plenty of overlap, plenty of contradiction, plenty of language that meant something in one domain and nothing in another. The synthesis work was finding the pattern underneath all of it: which handful of ideas showed up, in some form, across nearly every tribe, without contradicting what any of them already believed.

What survived that filter were a set of ideas specific enough to disagree with, but general enough that anyone could recognize themselves in them. That was the target the whole time. A principle nobody would argue against isn't doing any work.

Relevant, Reliable, Engaging, and Empowering. Each one started as a plain, customer-level statement, deliberately not written in Tokopedia's voice or any single tribe's vocabulary, so that translating it into a tribe's own context later wouldn't mean fighting the original wording. Each also came with a way to reason about it in a product, a signal to measure it by, and question cards to bring into a critique.

On their own, these four sentences don't look like much, which was the point. They're a floor, not a finished design language. The actual work was building the system that let any tribe stand on that floor and build their own version on top of it.

Four sentences don't survive contact with a real product review. The framework was the part that made them usable: a repeatable way for a tribe to take the generic pillar and rewrite it in their own users' voice, then carry that translation through actual design work instead of leaving it as a poster on a wall.

The translation step mattered most. A tribe would empathize first, mapping their users' mental models before touching the principles at all. Only then would they synthesize: rewrite each of the four pillars as a first-person statement in their own users' words. Sometimes that meant splitting a principle by role: a content tribe needs a version for people consuming content and a separate version for people creating it. Sometimes it meant splitting by side of a marketplace: an affiliate program needs a version for the affiliate and a version for the seller they're promoting. And sometimes a tribe had one user, one context, and needed no split at all. Recognizing which shape a domain actually needed was as much the work as writing the words.

Around that translation step sat seven concrete tools tribes could reach for. Each one belongs to a stage of the design process, from understanding the problem to assuring its quality, so a team only reaches for the one that fits where they are. The last stage, learning and improving, is where the evaluation a year later came in. Pick a tool to see what it does and how it looked in practice.

The last piece was making the pillars measurable, not just felt, which is what the Key Result tool is for. If a tribe couldn't point to a number that moved when they applied a principle, that was a signal the translation hadn't landed yet, not that the principle was wrong.

None of it required me to be present. That was deliberate. A framework that only works when its author is in the room isn't a framework, it's a service.

The framework had to prove itself twice. First, in the tribes I led directly, Content and Affiliate, where I could apply it myself and see where it held up under real product pressure. Second, and more importantly, in NOW! and Gamification, tribes I had no authority over at all, where a framework only survives if it's genuinely self-service.

Content went deepest. Its ecosystem splits cleanly into two roles, people consuming content and people creating it, so the pillars split the same way. "Relevant" for a viewer became discovering personalized content based on interest and shopping behavior; for a creator, it became clear guidance before, during, and after making content so it actually helps their sales. That split carried all the way into How Might We questions for real features, a pinned-product mechanic during livestreams got its own set of questions per pillar per role before a single screen got designed.

Affiliate needed a different shape. It's a two-sided marketplace, so instead of splitting each pillar into separate cards, we kept affiliate and seller together on one, each principle stated once for both sides at once. "Reliable" for an affiliate is navigating the whole journey and building credibility; for the seller on the other side, it's trusting the collaboration generates dependable data and stays secure. Same pillar, same card, two audiences who both need to believe it.

NOW! and Gamification are the proof that mattered most to me, because their teams adopted the framework on their own, led by their own managers, without me running the workshop. NOW!, a single-persona quick-commerce experience with no second role to split against, kept each pillar as one direct statement: "NOW! always offers me something that fits my daily needs, any time I access the ecosystem." What stood out was the rollout the team built around it on their own initiative: two phases, design the right thing, then design the thing right, holding every proposal to the principles through critique and stakeholder review before it shipped.

Gamification went through the same translation, then further. Every card cites its parent pillar directly before the localized version, a small choice that keeps the lineage traceable back to the source instead of drifting into the team's own language. And they didn't stop at a workshop exercise: they mapped the pillars onto real shipped features, Panen Telur, Tap-Tap, Referral, and more, each one broken down by exactly which pillar it answered and how.

We evaluated the framework in June 2023, roughly a year after it shipped, as part of a wider push across the design org to check whether One Tokopedia was actually happening or just being said. The honest answer was mixed, and I'd rather show that than round it up.

First, who was actually using it. We tracked it down tribe by tribe. 8 of 28 tribes had made it their own: personalized principles, workshops with their stakeholders, a framework they reached for often. 2 used only the core four. 18 hadn't picked it up yet.

The tribes that went furthest told us where it earned its place: collaboration with stakeholders got easier, it became a way to define problems rather than just critique screens, and it helped them argue for a product vision with more than taste. Everyone else named the same gaps: the principles weren't top of mind, they rarely showed up in design documentation, there was little guidance on daily use, and no clear way to bring stakeholders along.

We listed every idea that could close those gaps, from a physical toolkit and critique rituals to scoring usability against the principles with the research team, and doubled down on the one that answered most of them: the framework's seven tools, used inside steps designers already take. We piloted them on 12 projects with 4 teams, each from a different tribe, for at least a quarter, and asked designers to score each tool for impact and for hindrance. Overall it landed at 3.8 out of 5 on usefulness and 1.8 out of 5 on hindrance.

The spread says more than the average. Key Result, the tool that turns each pillar into metrics, scored highest on impact and among the lowest on effort. Design Critique cost the most for what it gave back, because a silent, written critique was slower than simply talking it through. And in their own words:

Out of that came a clear punch list rather than a victory lap: make the principles a routine, not an extra step; show the reasoning inside design documentation instead of leaving it implicit; give teams more concrete guidance on daily use; and get better at proving, with the metrics the framework already defined, that applying the principles actually moved something.

What happened next is only partly on record. Several more tribes and projects picked the framework up on their own after the evaluation, but we stopped tracking adoption at the end of H1 2023. In H1 2024 Tokopedia was acquired by ByteDance, and as the two organizations streamlined their processes, NEST wasn't carried forward.