Designing native content tools
Legitimate
Context
Legitimate uses NFC technology to connect physical products to digital experiences. When consumers tap an NFC-enabled product with their smartphone, they unlock exclusive content, verify authenticity, and engage directly with the brand.
When I joined full-time at the end of 2024, Legitimate had completed major client activations with global sports and music brands like Transparent Arts, Adidas, and Collina Strada.
At the start of 2025, Legitimate was shifting toward enterprise contracts in music and sports—larger deals, longer sales cycles, and higher expectations for reliability.
To grow, we needed to earn trust not just with executives signing contracts, but with the marketing teams who would use the product daily.
Problem
Marketing teams couldn't do their jobs independently. Creating a digital experience required leaving our platform, learning a third-party tool (Builder.io), and often waiting for Legitimate engineers to step in to provide technical support. This friction eroded user’s confidence in the product’s capabilities.
If we could give marketing teams native tools to create experiences themselves, we'd remove a major barrier to adoption and demonstrate the platform maturity that enterprise buyers expected.
Research
Before exploring solutions, I reviewed dozens of sales calls, post-mortem notes, and direct client feedback to better understand how marketers currently managed their digital content. I found consistent patterns in feedback:
Context switching - Moving between Dashboard and third-party CMS meant losing track of what clients were editing and how content connected to products.
Steep learning curve - Builder.io is powerful, but it's a general-purpose tool. Marketing managers didn't need that flexibility—they needed to upload assets, add copy, and preview the experience.
No autonomy - When clients couldn't figure out Builder, they sent assets to Legitimate and waited for technical support.
How might we enable marketing teams to create digital experiences on their own without having to learn a brand new tool?
Approach
I mapped the problem against three lenses to frame what we should build: what customers needed, what we could realistically deliver, and what aligned with our business direction.
From these constraints, I established three guiding principles:
Draw a hard line on customization - Descope styling options. No custom fonts, limited color controls, fixed type hierarchy. Opinionated, not open-ended.
Support visual assets and media - Music and sports activations center on audio, images, and video. Clear constraints on file size, length, and supported types.
Design for non-technical users - Controls should be immediately identifiable, simple, and easy for anyone to understand.
Explorations
Using shadcn as the foundational component library, I took a look at a few potential avenues that we could take, including our current implementation. The first was to integrate with an existing content management system, which would mean that we would not need to build the tool in-house. The second was to allow for clients to add elements in a linear fashion, the same way in which a simple website builder like Universe or Wix operates. I called this “Blocks”. The third was to create pre-defined page sections that represent a distinct content type. I named this “Tabs”.
Scope
The first approach of integrating with a CMS was already proving to be unsustainable due to operational overhead and friction, therefore I narrowed in on “Blocks” and “Tabs”. Through these design explorations, I worked with our engineers to determine which solution would work best within our constraints.
“Blocks” offered users the most flexibility in creating their webpages, allowing them to add and reorder any combination of elements. As powerful as this model was, it increased the surface area for errors and introduced more complexities of layout like spacing and alignment.
“Tabs” on the other hand were pre-defined content sections, each with a distinct type and structure that was predictable. This provided built-in constraints that although was less flexible, made the experience dramatically simpler for the user. It covered the majority of use cases with a fraction of the complexity.
Solution
The native content editor shipped with:
Five tab types: product, gallery, playlist, and integration with CMS to cover core patterns
Real-time preview showing exactly how the experience renders on mobile
One-click tab creation with visual previews of each type
Reordering for adjusting content sequence
Built-in constraints preventing layout errors and broken experiences
Impact
Enabled non-technical users (artist managers, brand marketers, agency partners) to manage content directly
Increased ACV by 900%, contributed to the company's largest contract
Enabled more demonstrative product demos with major entertainment and media companies: HYBE, Pickers Vodka, One Music Fest, and Big Machine
Platform users expanded from ~10 internal team members to 30+ external users globally across brands, agencies, and regional partners