How we moved from content docs to Abstract at Wix

My product team has found a better way to ensure that our UX Writers are truly writing content in design, making us better writers and helping us create better products faster.

For us, a tool called Abstract was our savior, but you could use whatever tools work best for your team. All that matters is getting your team to see the benefits of actually writing in design.

The old way of doing things

On one of my first days, I watched a colleague make a content doc. She went screen by screen in a product flow, taking a screenshot of each one, and pasting them into a Google Slides presentation. Then, she added text boxes and changed the font type, size and color to simulate the design.

This content doc would eventually get passed to the designer, who would go screen by screen in Sketch and update the text. If the writer changed a comma in a page subtitle after handoff, the designer would have to go back to each and every screen yet again.

Despite all our efforts with textboxes, chat bubbles and font sizes, we didn’t actually know how our text would look in design. If something didn’t fit, we’d have to go back to the drawing board and rewrite potentially half the screen.

There also always seemed to be a disconnect between when text got updated in the Zeplin file (our source of truth for product, UX, and dev) and when the developers created keys. That meant keys were created with incorrect text, making the quality assurance (QA) process that much longer.

There wasn’t another way of doing things, so I resigned myself to this process.

A few months after I started, our UX Designer Team Lead announced that he wanted his team of 4 designers to start using Abstract, a file and version management system for Sketch files.

I, the sole UX Writer, could also use Abstract to add my text directly to the designers’ Sketch files.

Abstract: “Design collaboration without the chaos”

Abstract is a tool that makes it easy for UX Designers and Writers to version and manage their Sketch (or Adobe XD) files. If your developers use GitHub, it can help to think of it this way: Abstract is like GitHub for designers and writers.

It allows for version management through a system of “Branches”. A Branch is a copy of the main file, so you can work without affecting it. A Branch eventually gets merged back into the main file and the old version is updated. Branches also chronicle all changes and make it possible to restore saves when needed.

For designers, it’s great because it means not saving a new version of a Sketch file after every edit. For writers, it’s great because we can work on text directly in Sketch while the designer works on the design.

It sounded interesting to me, but also a bit daunting. To the designers, I think it was downright terrifying. Even though they understood the idea of version management, they still had an overwhelming fear that I would mess up their designs.

We decided to give it a try. Like all new concepts–and this was a brand new concept for Wix–it was anything but smooth sailing. What followed were months of trials and errors.

Project #1: Who Benefits?

We made the switch halfway through a big project, so I already had a content doc made. Once content was final, I went screen by screen in Sketch, updating every piece of text the way the designer used to do. It seemed like this was a one-sided victory: the designers got work taken off their plate and I got work added.

Project #2: Fear of Conflicts

On the next project, nothing seemed to be working. The designs on my Branch didn’t match the designer’s. When I merged my Branch back into the main file, there were so many conflicts that I often had to go back and redo my work. I still had to update things manually if I made a change, except now it was even harder because I wasn’t as familiar with Sketch.

The designer and I were constantly frustrated, both with each other and with Abstract.

Project #3: Whose Branch Is It Anyway?

The 3rd project came around, and we approached with trepidation. Somehow, we discovered Child Branches. It was revolutionary. Now, we were truly version managing.

Every time the designer committed a change, my Branch got updated, so I always had the most recent design. It also gave the designer more control, because there was no way for me to potentially mess up the main file.

But we were still having lots of conflicts. If the designer and I both worked on the same screen, even if it was on 2 totally different areas, there would be a conflict and one of us had to redo our work. Wasn’t that the whole point of Abstract, that we could work on the same file together?

Project #4: When It All Changed

I started working on another project, this time with a different designer who used Sketch symbols in an interesting way. Most designers created 1 symbol for a pop-up and then detached it to show separate states.

Any updates to the symbol wouldn’t apply to the detached screens, so I still had to update text screen by screen. (If you’re not familiar with symbols–and I certainly wasn’t before this transition–a designer can help explain this more.)

This designer used symbols like building blocks. Every part of the pop-up was its own symbol and they were put together to make a different symbol. He could build any screen while keeping symbols attached to the masters (see the image below).

If Child Branches were revolutionary, this new symbol system was life-changing.

It saved me time, as I only had to update the symbol once and it would update on every screen. It also significantly decreased the number of conflicts. We were actually able to work on things at the same time.

Project #5: No Safety Net Needed

On the next project, I didn’t make a content doc. I worked completely in Abstract and Sketch, feeling confident that I wouldn’t lose work. We developed additional systems to help things run smoothly:

• • Adding a content draft page to every file, so I had my own sandbox

• • Using “stickers” to communicate if there was a new screen added or if I accidentally broke the UI

• • Giving our commits detailed names

• • Committing and merging Child Branches often, as a backup against conflicts

• • Staying in constant communication about changes to the file and Branches

The tips and tricks were great, but as more people joined our team, we realized we needed to write a full-fledged process.

We ended up with a 7 page document that breaks it up into 3 parts: the Product/UX design stage, the content stage, and the handoff stage. It felt good to have come so far and have something to show for it.

Was it worth it?

It took about a year to go from our first trial to a definitive process.

During that time, I wasn’t always sure it was worth our time and effort.

Besides the problems we faced, Abstract has some flaws of its own.

It’s slow to do things like opening a file, committing, and merging.

There are sometimes syncing issues that force us to revert files because commits didn’t save properly.

We have had to figure out several workarounds for these issues and are in close contact with Abstract’s customer support.

Despite all this, my answer is unequivocal: Being able to write directly in design has been worth the Abstract learning curve.

Working in Abstract has truly changed me as a UX Writer. I can make sure I’m telling the whole story from the very beginning, because I can immediately see if what I’m writing works within the design. My content is always complete when it gets sent to the developers; there are no open questions about how something will look in production. 

It’s also enhanced the way I collaborate with my team’s UX Designers. We speak the same language now and use the same tools, furthering the idea that content is design, and design is content.

Of course, it’s also significantly sped up the whole process itself!

We’re adopting this process across Wix now, and I couldn’t be more thrilled. I truly think that working this way is the future of UX writing. If we want to be taken seriously as part of the design process and ensure our text looks good on each and every screen, we have to be working within the design itself. It takes our profession to a new level, and elevates the quality of our text.

 Jenni Nadler is currently a UX Writer & Team Lead at Wix. Connect with them on LinkedIn.

Did you enjoy this blog post?
Level up your skills and knowledge in one of our courses. Your career is depending on you!