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.

These voice and tone guidelines live in an internal wiki and we referenced them regularly during stakeholder reviews.

Concept Definition

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:

About 20 designers, developers, and other stakeholders worked on the project, so lightweight visual artifacts like these were very helpful.

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.

I created wireframes and flows in Axure for many communication-driven components.

Email Inventory

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.

I worked with our developers to make sure any product-specific content was variable and could be pulled from our database as-needed.

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:

Each box in the visual inventory of automated emails is linked to the UX spec. From there, an implementation link is also available.

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.

These content guidelines were published to our internal wiki so anyone could access them. Want to see more? Download a screenshot of the whole page

These content guidelines were published to our internal wiki so anyone could access them. Want to see more? Download a screenshot of the whole page