Simplifying Domain Configuration
Sometimes UX writing has to bridge the gap between deeply complex processes and the people asked to use them. Domain configuration was one of those cases.
Methodology Note
- Company: Anonymized for confidentiality reasons
- Data: Cross-functional stakeholder interviews and system requirements
- Purpose: Demonstrate complex UX writing and flow simplification
- Tools: Figma, stakeholder interviews
- Target users: Low-code platform customers setting custom domains
Context
As one of the UX writers at a fast-moving low-code software company, I was asked to design the experience for customers setting custom domains to the web apps they built. On the surface, this sounded straightforward. In practice, it turned out to be far more complex.
Constraints
The Product Designer and Product Manager assigned to the feature were both unavailable. I was left with vague directions and no blueprint for how the flow should work. I had no background in DNS records, CNAMEs, or SSL validation. The system imposed a hard 72-hour window for SSL certificate validation. If users missed it, they had to delete the domain and start over. Any copy I wrote had to guide users through CNAME records and certificate expiration without overwhelming them with jargon.
From Uncertainty to Clarity
Without a plan to fall back on, I took the lead. I read up on the basics, then sat down with a Cloud Architect and a few backend developers to understand the system requirements. Their explanations gave me the grounding I needed to write with confidence.
With that foundation in place, I partnered with another Designer who happened to be available. Together we shaped the experience into a step-by-step flow that would feel effortless for users, even if the underlying process was highly complex.
The Approach
The key was to reduce cognitive load. I divided the flow into three distinct steps: adding a domain, validating ownership, and pointing the domain to the apps. This ensured that users only had to focus on one action at a time. Each step was framed in plain language and anchored by a clear goal.
Usability testing on low-fidelity mockups revealed that some users were unfamiliar with SSL certificates but reacted well to the word security. That insight informed a critical shift. Instead of "SSL certificate," we told users: "A security certificate was issued for this domain. This certificate will expire in 72 hours. Follow the next steps to complete the setup before expiration."
This wording simplified the concept, highlighted the time constraint, and focused attention on the next action.
The Flow
To clarify the purpose of custom domains, I added an empty state for users first discovering the feature. When no domain had been added yet, the interface clearly explained why the section was blank and how to get started.
When users initiated the domain setup process, they were guided through a clear modal that explained what information was needed and why. I also added inline validation to verify the domain format in real-time, preventing errors before users could proceed.
Once a domain was added, users saw the configuration screen where I gradually introduced the concept of security certificates. Rather than overwhelming users with technical jargon upfront, I explained what the certificate does, what actions they needed to take, and why completing the setup within 72 hours was critical to avoid starting over.
I also added confirmation modals for users attempting to leave the configuration before completion. This prevented certificate expiration and gave users a chance to reconsider.
If, for whatever reason, users weren't able to complete setup and one of the certificates assigned to a domain expired, users would see an empty state explaining what happened and how to fix it. This avoided blame, stated the issue in clear terms, and gave users a direct recovery path.
Outcome
The copy and structure made the domain configuration process easy to complete and less intimidating than it would seem at first glance.
Customers didn't feel blocked by complex jargon or hidden deadlines. The product also gained a consistent voice in error states and flows, aligning with our conversational tone.
Results
In usability tests, participants reported that the flow felt approachable and easy to follow. Users were able to complete the configuration with minimal guidance.
Support data backed this up. I contacted the support team to learn that few to no tickets related to SSL and DNS setup were being filed in the weeks following the rollout, giving the support team space to focus on more complex product issues.
By restructuring the flow into simple steps we turned a fragile, failure-prone process into a guided experience. It was a reminder that even in highly complex features, words carry the weight of the experience.