From Silos to Collaboration: My First 30 Days as a Writer on a Design Team
Published via Medium
Leaving Legacy Tech Writing Behind
In my experience, the position of a tech writer is one that sits as an afterthought of the product release workflow. The writer is informed of changes coming to the product and updates the documentation accordingly. Whether you realize it or not, that workflow limits not only the documentation, but the product itself.
Technical writers have a lot to offer, yet we are too often an untapped resource for UI optimization. We share a comprehensive perspective on the product with teams that are often siloed and provide the customer’s point of view in complicated (and sometimes chaotic) product experiences.
Yet that hasn’t always been the reality of my career journey. So, it was a truly pleasant surprise to realize just how integrated the writers are when I started as a tech and UI writer on Emplifi’s design team. Around here, there is a different way of doing things. Being part of a forward-thinking, design-led team has pushed me to dive deeper into UI principles and fundamentally change my perspective on what a writer’s process can be.
Breaking the Last-Minute Cycle
The traditional tech writing workflow I’ve experienced goes something like this:
Product design changes are created and implemented.
A release is announced a few days or weeks out.
Tech writers are informed during the “last wave” of information.
The scramble begins: writers rush to figure out the documentation impact and implement changes within a tight deadline.
While documentation still gets updated, an accelerated timeframe doesn’t allow for content quality assurance or optimization. Synchronization with the product becomes impossible; as a result, the doc center functions as a standalone afterthought.
In contrast, an integrated system brings writers into the conversation at step one, shifting our purpose from simple writing to content strategy. Instead of scrambling, there’s time to optimize. We are given the space to take a bird’s-eye view and ensure information is presented in the best possible way.
Incorrect information, gaps, and structural inaccuracies are weeded out when writers are involved from the get-go. While some might ask, “Why should I care about documentation?” the answer is simple: this is about customer experience.
By the time a user reaches the documentation center, their experience is already “tainted.” They aren’t there for a fun read; they’re there because they’re stuck. If they are then met with inaccurate or confusing content, it could be the final straw. A broken link or a vague instruction in the docs isn’t just a typo — it’s a failure of the safety net we promised the user when they signed up.
The Feedback Loop: Where Writing Meets Strategy
When a writer is embedded within a design team, the benefits flow both ways. It isn’t just about the writer getting a “head start” on documentation updates; it’s about the writer being an indicator for UI complexity. It’s about creating a feedback loop that strengthens the product before it ever reaches the user.
If it’s hard to document, it’s hard to use
In the legacy siloed model, the writer is often the first person to realize a workflow is unnecessarily complex. However, by the time they realize it, the feature is already built. By sitting with the design team, I‘m enabled to speak up during the prototyping phase. If I’m struggling to find a logical way to explain a feature in the documentation, it’s usually a signal that the UI itself needs more clarity. This opens doors to having discussions about simplifying the design, rather than trying to explain a “clunky” experience later.
Aligning the mental model
Designers and developers often use internal jargon to describe new features. If those terms make it into the UI and then into the docs, the user is forced to learn a new language just to use the product. Being involved from day one allows me to help align the mental model of the user with the vision of the designer. We can ensure that the labels in the interface match the titles in the documentation center, creating a seamless narrative across the entire platform.
Reducing the cost of knowledge
Every time a user has to leave the product to search the documentation center, they are taken out of their workflow and forced to enter another. By collaborating with designers, we can identify which information is critical enough to live inside the UI (via tooltips or microcopy) and what belongs in a long-form article. This partnership ensures the documentation center isn’t a graveyard for things the UI failed to explain, but a library for deeper learning.
Looking Ahead
My first 30 days at Emplifi have been a masterclass in integration. It has been a shift in understanding what it means to be part of the product, rather than the afterthought.
I’ve come to realize that when we stop treating documentation as the last step and start treating it as a foundational design layer, the benefits are limitless. From UI optimization to reduced ad hoc code fixes and better information architecture — everyone wins. But most importantly, the customer wins.
As I move into my next 30 days, I’m excited to leave the scramble behind. I’m not just writing about the product anymore; I’m helping design a better way to experience it.
