The problem with the UI text strings we write
At a summer Bug Bash, a team at QuickBooks got together to uncover bugs. 64% of what they logged were language errors like typos, spellos, special character fails, poor translations and ancient content buried in the code — messages from who and what our product used to be. Indecipherable at worst, embarrassing at best.
How does this happen? I ran off with my team to ask about the technology for managing UI content or text strings. Text strings are the small bits of content in your product’s buttons, labels, headings, alerts, instruction and such.
Little text strings are big
Consisting of short phrases and sentences, writers and designers toil over text strings to solve for business requirements, technical constraints, user needs, task completion, brand voice, feedback from critique and testing.
There’s more going on in a string than the naked eye can see. Through language, we build a relationship with customers. Strings are the biggest tiniest things in your product.
Strings are P1 to the UX team, but as we learned, they’re P3 to developers.
Once released, it was hard to fix or update them. A bug got captured in a JIRA ticket where it would languish for months, involving comments from a dozen watchers along with half dozen screen shots. The effort is outsized to say the least.
Human hand-offs and system handshakes
After some poking around, we learned that the issue was as much about workflow as technology. Poor quality content was a reflection of broken processes, organizational boundaries, psychological sense of control, and lack of definition about roles and responsibilities. The weight on a string!
Too many tools cause delays, extra work and confusion
“Sometimes I do mock ups in SnagIt, and give it to the writer. Then I would build in Sketch, and we go straight into Zeppelin as InVision is an extra step. It’s a pain trying to keep up with what’s the latest copy and where to find it.”
— QuickBooks designer
No matter what role, everyone experiences last-minute surprises
“Every screen in QA has errors. The developers swap my words out. They often don’t understand what I’m trying to say so we spend a lot of time going back and forth.”
— QuickBooks content designer
The process is not defined, aligned or visible
“It’s a cringe fest and a lot of hoping someone didn’t screw it up or supersede you.”
— QuickBooks developer
How could we introduce a wider view?
Busy with daily work, teams couldn’t always see past their desk. Each had goals, demands, preferences and a narrow, maybe unchallenged, assumption that they can optimize workflow solely for their own interests. Honestly in the day-to-day, it felt like a bit of a luxury for teams to think about how their deliverable affected the next person to work with it. We needed a better model.
A workflow analogy
What if we were to view content as the sun — a source of energy — how does it pass through the food chain, or workflow, from content writing, to design, to globalization, to development, to finally get displayed in your product where it delights customers? What are the interactions between teams and with an environment?
Am I a dreamer? If you want powerful, effective workflow, you have to give a little to get a little and make adjustments to balance throughout. As a result, your team may end up with more to do or less responsibility. It will never be perfect or everything everyone wants it to be. Work is a community effort even if you don’t know your partners downstream or up, which is often the case in larger companies.
In a corporate environment there are few incentives for teams to change habits, solve flexibly and make compromises. Usually the team that moves quickest to its own target is rewarded. Going alone is the easiest.
With everyone aimed at business KPIs, it made sense to push off string capabilities. To engineering and product, the string things worked fine. Our work on strings has been slower than we’d liked. It didn’t exactly inspire the excitement of creative work that goes into a product demo. And while there seemed to be great demand for and benefits to a UX writing solution, getting strings prioritized was a challenge.
Do it for your customers
Forrester reports, words in a software application have the most impact on user engagement with 4 times the conversion differential on text.¹
What seemed like trivial housekeeping by teams greatly effected the quality of content in the experience. Workflow and tooling had as much impact as the quality of craft and talent in our teams. In our experience, the content we wrote sometimes never ended up in product. This was our issue to advocate, content folks.
As content strategists, we tend to publishing processes in other channels, but in product? It seems to be overlooked or labeled “development” that’s not in our yard.
Finding a team to drive, implement and support it wasn’t simple. We came to realize that if we wanted to manage strings in UX, we’d be the ones to make it happen. We formed a team of our own, within content. We had to learn about the product development and release process. It also meant we had to be more influential in discussions of capabilities to get our concerns in the mix with others.
Of all the design and development tools in play, why did we have so few in content design? How could we do our jobs and deliver quality content using a Google Doc or Sketch? JIRA? Here we added to our story, talking about the efficiency of a string platform for content design and its potential for innovation as a capability.
Here’s how we got it going at Intuit:
Make introductions
Talk to all your content consumers, not just your end customer. Include representatives from writer, designer, developer, globalization and architecture teams. Find common ground. Equally important, find out about the systems they use to consume content in their work. You may also want to include stakeholders of that content like PMs. Find things on their roadmap that would be positively impacted by a solution.
Start talking
What’s the current state? We found teams were at first reluctant to talk honestly about their processes and tools. Or found it difficult to imagine doing things another way. So many people are forced to accept crummy enterprise software without complaints. Engaging with teams openly shows someone cares about the gaps. Volunteers emerge as the first group of users.
Audit your content
Accounting for text strings can be tricky. We couldn’t pull out a web crawler to gather up URLs. Some of the strings are hard-coded to screens, so we ran grep commands, emptied out databases and GitHub repos. Then we checked typical qualities like clarity and voice, as well as the naming of key value pairs, the number of strings and words, their distribution, language and localized versions. You want a decent idea of the scope and characteristics of your strings as a whole. Auditing also helps target where to start.
Redefine “final content”
Content people know content is never final, but make sure everyone is generally aware of its lifecycle to help dilute emphasis on new content. How do you keep things moving through the workflow when you update content or delete it? How can you promote re-use? What if a developer writes an error message on the fly to release code? Should it get flagged for a writer’s review? This is a change in thinking to actively manage strings. You can start socializing a new definition even before you have a solution in place.
Take an experience design approach
The great thing about sitting in a design team is that we could be both users and makers of our solution. Identify opportunities, use cases and requirements as the content journeys from team to team and machine to machine. What’s the ideal state?
Test with users
In addition to proving technology concepts, we observed, interviewed and shared prototypes. Through user testing, we identified issues we’ll need to communicate, or configure during implementation and cover during training.
Offer a bonus
If you can, find a pain point for each constituent group that your solution can trade with. Make that connection clear. For example, developers shouldn’t be writing content, neither should they be forced to engage with every content change made by someone else.
Draw a line
In a world of “choose your own adventure,” it’s tough to get people using a single system. Harder to benefit from any standardization. Don’t go down the path of trying to accommodate all. It might result in an overly complicated, unusable workflow. Everyone will look for workarounds, relying on heroics. And it’s back to square one.
Let’s start thinking of our text strings as a whole. It’s a body of content just like support articles, marketing emails or landing pages. Technology can help us manage strings.
Product content design is ready. I’m excited about the technology as much as style and voice. If you want a future of personalized content, and voice experiences, driven by data and machine learning, we’ve got to take on the effort.
At Intuit, we were fortunate to find Writer, formerly Qordoba. After discovery and discussion, we found their strings platform is the solution we need. And my team is going to drive its implementation.
¹ “Making experience your business is good for your business.” (Forrester) March, 2018.
