Wolfram, like many software companies, is moving its desktop products to the cloud. We needed new billing and account systems to support these products.
Voice and Tone
For interface copy in particular, there's always a question of how it should sound. Apps range from straight-laced to downright whimsical. The bigger concern is that an app's voice and tone is rarely intentional or well-defined. It grows organically based on each writer's perception of the company, along with scattershot stakeholder feedback.
At the time, we didn't have support from senior leadership to create voice and tone guidelines for the entire company, but we wanted the account and billing systems to feel like Wolfram, so I worked with project stakeholders and other members of the UX team to create lightweight voice and tone guidelines for this project.
For years, Wolfram referred to the email addresses customers use when signing in as "Wolfram IDs." This defined the Wolfram ID as an email address, but names and passwords were also connected to each customer's account. We also had to think about the future. What if we wanted customers to be able to upload profile photos or even write their own bios? We needed to expand the concept of the Wolfram ID.
I created a diagram to show what a Wolfram ID is and does:
Writing and Design
As we got into the design process, we broke the project down into smaller components. If a particular piece was mostly interaction, I worked alongside one of our UX Designers. However, I designed many text-heavy interfaces myself.
Besides all the interface content, a slew of automated emails needed to be written and designed.
We had never used HTML and CSS for automated emails at Wolfram, so I worked with our developers to create the specifications. We wanted the emails to work for multiple products so they'd be easier to implement and maintain. For billing emails, this often meant we needed to unify product policies.
We also needed a way to keep track of all our emails and reference them quickly. A copy of each one was stored in our database after implementation, but we also needed quick access to the UX specs. Content strategists typically solve this problem with a spreadsheet, but I wanted to create something interactive and visual.
I laid out an inventory showing each of our emails and classifying them by format and use:
UI Content Guidelines
Over the course of this work, I received a lot of style questions related to interface copy. Our company style guide didn't do much to address these cases, so I collaborated with our other UX Writer to create a pattern library for UI copy.
This allowed our whole UX team to answer these questions quickly, while also providing rationale for our decisions.