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.

I co-ran workshops across tribes, working independently 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. In each workshop, we pulled in each 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. That constraint mattered more than it sounds. A principle that fit content and gamification but broke for a two-sided marketplace like affiliate wasn't a principle, it was a preference wearing a bigger word.

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.

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. That's the part worth exploring properly rather than just reading, so I've kept this section interactive: tap into each card to see the questions we asked to pressure-test 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, depending on where they were in a project:

1. 01Starting from a user story.
2. 02Working top-down from the principles directly.
3. 03Running a How Might We session.
4. 04Walking a thoughtful execution tree.
5. 05Holding a structured design critique.
6. 06Presenting to stakeholders.
7. 07Embedding the outcome into a business requirement doc, so it didn't evaporate after the meeting.

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 last piece was making the pillars measurable, not just felt. Each one mapped to real product signals a tribe could actually track: Relevant to session count and click-through rate, Reliable to conversion rate and completed orders, Engaging to impressions and click-through, Empowering to user count and retention. 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.

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 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.

We tracked adoption across tribes and business units. A minority had taken it further than we'd hoped, running their own workshops, holding stakeholders to the same language, using it as their default thinking process. Most had adopted the core four pillars but hadn't gone further. A handful hadn't picked it up at all. Alongside that broad tracking, we also ran a tighter pilot: an assessment of 12 projects across 4 teams, each from a different tribe, using the framework for at least a quarter. It scored 3.8 out of 5 on usefulness and 1.8 out of 5 on hindrance, a more precise version of what "mixed" actually meant.

Here's what we heard, in both directions. The recurring complaints were consistent across tribes: the principles weren't yet top of mind by default, they weren't visible enough in day-to-day design documentation, and there wasn't enough guidance on how to reach for them beyond the obvious cases. The recurring praise was just as consistent: teams that used it said it made cross-functional collaboration genuinely easier, gave them a repeatable way to reason about problems rather than just critique screens, and helped them argue for a product vision with more than just taste.

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.