How to Write UX Copy for a 0–1 Product
When I was growing up, my family took lots of road trips. There were no navigation apps back then, so my parents would figure out the route on-the-go. Building a 0–1 product is exactly like that.
You know your destination and you vaguely know how to get there. You’re probably going to make a few mistakes and ask for directions along the way. Sometimes you’re just going to have to trust your instincts and hope that you made the right call.
When you’re building a product from scratch, no one has all the answers. That’s what makes my work as a UX writer so fun. Writing for a new product gives you the opportunity to decide what features and objects will be called. You get to shape how users will interact with the product on day 1 and influence the mental model they form of the product.
The canvas is blank and that can feel challenging, but working through those challenges takes me to a state of flow. A few weeks ago, I forgot it was time for lunch because I was writing for a new product!
At Rubrik, Identity Resilience was my first experience writing for a 0–1 product. Looking back at that project, I found some strategies that helped me write more effectively.
Understand the landscape
Before I wrote a single word for the user experience, I wanted to understand more about Identity Resilience. I learnt that the product would help companies protect and monitor identities. But I had more questions — why was this important and why did an identity and access management (IAM) admin, our key persona, care about it?
I went through PRDs and research reports to understand our user and the need our product was addressing. The individuals in an organization are the first frontier for attackers. We were building this product to help companies protect the individuals (or in more technical terms, the “identities”) in their organization. This understanding shaped how I wrote for onboarding flows and guided tours.
The web app has an inventory of all identities in an organization. I’d learnt that an IAM admin would view this page first thing in the morning, every morning. I’d also learnt that they didn’t care about every individual in the organization. In the guided tour, I wanted to highlight that they could filter to view the identities they need to pay attention to. I described the value of the page this way:
Monitor identities from all identity providers in the Identities page. Filter by identity type, source, and identify highly sensitive identities.
Our research team’s reports and the competitive research done by the designer were great resources — I used them to understand what terms users are familiar with. For example, “alerts” was an industry standard term. I didn’t change it or over-explain it; I just used it as is in our flows.
If your organization has a research team, build on top of their work. If not, spending a few hours understanding the landscape is totally worth it.
Build a glossary
In March 2025, I attended a workshop on systems thinking where David Connis had emphasized the value of a glossary. I was in the thick of the Identity Resilience project and thought of trying it out. I wasn’t sure it would be useful, but still, I began to document and define all key terms in a glossary.
It proved to be tremendously valuable! The glossary gave me a framework to make copy decisions. The status of violations and alerts is a good example of this in action. I had defined five statuses for violations — Open, In progress, Remediated, Dismissed, and Closed.
When we built the Alerts feature, we adopted the same statuses to strengthen that mental model. We only differentiated the primary action — a violation was remediated and an alert was resolved.
If we hadn’t had a glossary, perhaps we would have used “Rejected” on the Alerts page instead of “Dismissed.” It would leave users wondering how rejecting an alert was different from dismissing a violation. This kind of confusion adds up. So why use two verbs for the same action? Glossaries help avoid this.
The reverse could also happen — using the same word for two different concepts. This almost happened with us. We were using “source” to refer to the domain or account of an identity. A few months later, someone proposed using “source” for a different concept in another part of the product. I immediately flagged that “source” had a different definition and two usages of the same term would confuse users. We picked a different term.
Educate, but don’t overwhelm users
Since the identity domain was new to the team, we’d often discuss where our users needed more education and where they could do without it. Many concepts were new to us, but we had to put ourselves in our user’s shoes.
Get Sidika Sehgal’s stories in your inbox
Join Medium for free to get updates from this writer.
If the feature was specific or unique to Rubrik, adding a tooltip to educate users was useful. For example, we created the concept of “insights” where we categorized identities as “at risk” or “highly sensitive” so that IAM admins could filter identities they needed to monitor more closely.
For some features, we added tooltips to explain how it worked. An identity’s overview was only updated once a day, even if multiple snapshots were taken in a day. Backend engineers pointed out that this was a minor, but important caveat.
Rubrik also had data on whether the identity had access to sensitive data. But during early testing, our research team found that IAM admins weren’t familiar with the concept of categorizing data by sensitivity. We added a tooltip to explain this to users.
Writing a good tooltip is easy — there’s plenty of guidance out there on writing good tooltips. But as a UX writer, I learnt to think more critically about when to add a tooltip. This is where understanding the user helped.
Every time we wanted to add a tooltip, we’d ask ourselves, “would this be obvious to users? Would they grasp the concept after using the product once?” If the answer was yes, we wouldn’t add a tooltip because it would only add more friction.
Reuse strings as much as you can
Building a product from scratch means working on Day 0, Day 1, and Day N flows. I found lots of opportunities to reuse text across different screens. A simple example is the tooltip to explain “insights.” I used the same text on the Identities page and on the dashboard. The repetition isn’t lazy; it helps reinforce a consistent message.
The onboarding flow was another instance of effectively reusing text. We had two licenses for the product and designed slightly different onboarding flows for them. I reused some value propositions for both and only changed one.
Remember, the goal is to write clear UX copy for every screen, not unique UX copy for every screen.
In hindsight
If I could work on Identity Resilience all over again, I would do all the things I mentioned above, but with some shifts in my attitude.
I’d tell myself to not get too attached to the first version of the copy or the design. A 0–1 product moves through lots of versions in early days. This is because we’re determining technical feasibility and coming up with a go-to-market strategy on the go. No one is to blame, this is part of the process of building something that doesn’t exist.
I’d remind myself that the need of the hour is to aim for goldilocks quality. We need to move fast and sometimes that doesn’t leave time to make things perfect. It’s okay to make it good, and then come back to make it perfect.
I’d also make sure that I document decisions. This is important because you may want to revisit a decision a few months down the line. If you don’t know why you decided to do it a certain way, revising the decision is like shooting in the dark.
A good team is a superpower
I wrote earlier that when you’re building a 0–1 product, no one has all the answers. But a good team can make all the difference. That doesn’t happen by accident. All designers, PMs, and engineers build that culture together.
Our backend engineers cared just as deeply about writing accurate UX copy and took the time to explain technical concepts to me. Our product managers always helped anchor the team to a shared goal. Sai Mohanty, one of the designers for Identity Resilience, was relentless in building a stellar user experience. He’s written about navigating the wild west of 0–1 products and I’d highly recommend reading his article.
Making sense of things and creating a product from scratch is special. It’s something every UX writer should experience at least once. So the next time you have an opportunity to work on a new product, grab it with both hands and remember these strategies!
