Categories
Content Design terminology

Designing with the right terminology

Using the right words is a crucial part of any customer journey. Whilst this shouldn’t be the total responsibility of content designers, we’re well placed to help nudge the rest of the design team toward the best choices. At Sage, I work within a close knit team of designers who are quite happy for me to explore word choice in the design process.

Licence versus subscription

A large part of our business is now in software as a service and this means a shift away from one-off purchases for software towards a pay-monthly option. As part of redesigns in this area, I was asked to review some screens from a content design perspective.

The screen I was asked to review contained the words ‘licence’ and ‘subscription’ in the same sentence which struck me as odd. I’d seen these words used interchangeably in our designs before and I wanted to ensure we weren’t being lazy with word choice.

The UX designer had included both words at the behest of the solution designer, who had included them because they existed in a previous iteration of the software.

Digged deeper, I asked both the UX designer and the solution designer to explain the difference between a licence and a subscription in the context of the screen I was reviewing. Neither had a compelling answer. One admitted to using both terms interchangeably depending on whom she was speaking with.

There was a can of worms here and I’ll admit to thinking twice before opening it.

Confirming the problem

My initial reaction was that if we weren’t sure of the difference between the words, then we were at risk of confusing customers. Many of these customers were transitioning from our desktop software, where licences were indeed bought for perpetual use, and moving to a subscription service. I wanted us to get this right to avoid any confusion as to what they were paying for. My gut instinct was we should be using the word subscription and could probably drop licence from our vernacular altogether.

But, maybe we were in too much of a bubble in Experience Design. Perhaps outside our department there really wasn’t an issue at all.

I spoke to a long time colleague in the Sales team.

‘I only ever use the word licence,’ she told me.

‘Never subscription?’ I pushed.

“Nope. Only licence. It’s what we’re used to.’

Oh.

Researching options

I turned to online definitions:

Subscription – An arrangement by which access is granted to an online service.

Licence – A permit from an authority to own or use something, do a particular thing.

This led me to the example sentence:

When a client subscribes to product X, they have a licence to use that software.

So, we could still use both words but I didn’t think we needed to. In the context of many popular software as a service providers, they go out of their way to avoid even the word subscription.

  • Netflix talks about signing up for an account and cancelling that account rather than subscribing and cancelling the subscription.
  • Spotify mentions subscriptions in their help files, but not at the front end.
  • On the Microsoft Office 365 product page, the word subscription is only included as a footnote.

Do our customers care about this?

What do our customers think of our licence / subscription terminology? Was there any evidence that customers struggled with the terms?

I’ll admit to not following up this aspect of research at this stage. My advice to you would be to contact your Support and Sales teams and ask them this question directly.

Also look to any feedback mechanisms you have within the product to see whether customers have demonstrated any confusion.

My approach was to handle this in the testing phase once I’d firmed up my thinking and we had something to show customers.

Terminology expands

It wasn’t just a choice between the words licence and subscription. Within our product, we have a feature where one customer can purchase product units for their clients. Where a customer has bought multiple product units (aka subscriptions) for their clients, what should we call the ‘thing’ where these units are stored prior to being assigned to a client?

I dumped a lot of initial thoughts on a Miro board along with examples of how each word might be used in the type of sentences we were likely to need in help topics and the user interface. This gave my thoughts some shape and helped me understand what might be feasible.

Narrowing down the options

Language and emotion play a huge part in the customer journey. I needed to decide on a word to use for this collection of subscriptions. When a customer buys a unit for one of their clients but doesn’t assign it to them straight away, it gets ‘stored’ for them, ready to be assigned.

But, what to call it? Pot? Store? Pool? Bench? Archive?

I quickly dismissed Pot. It seemed too homely for the business scenario. Store was next to go because of its obvious commerce connotations. I seriously considered ‘bucket’, but I associate buckets with soil, and ‘building’, and dirt. Yeah, I didn’t like the dirt association. ‘Bench’ could have worked. I was thinking of the American phrase around benching players, but thought the phrase wouldn’t be obvious to most. That left me with ‘pool’. It’s not perfect, but subscription pool had a certain ring to it.

(I also invited others to suggest words, but no one came up with anything that wasn’t already on my list.)

Bringing stakeholders on board

As I was about to propose dropping one commonly used word from our development team’s vocabulary, it was necessary to start building up support. I work in a fairly small team of content designers in a much larger department of developers, solution designers, and product managers. Whilst I feel my work is respected, it can sometimes feel like shouting in the wind. I needed to amplify my message by finding supporters.

I’ve found visuals and examples the best way to bring people over so I created some before and after screenshots of designs impacted by the change. I use PowerPoint to create these fairly crude designs. I deliberately haven’t asked for access to more designery tools as I don’t want it to ever look like I’m trying to do the UX designers job for them. Instead, I want people to be able to focus on the word differences I’d introduced.

I met with the key stakeholders and outlined what I saw as the problem with my proposed solutions. It was rewarding to hear that stakeholders had recognised there was a problem but hadn’t been able to make moves to addressing it. I was given the blessing to carry on down my preferred route of simplifying by dropping licence from our designs.

With stakeholders on board, it was simple to work with the UX designers and arrange for my changes to make it into the latest round of designs. The UX designers were happy that the stakeholders weren’t going to be surprised at the next design review.

What do customers think?

We’re lucky that we have two dedicated user researchers who will put designs and questions in front of real customers. I’ve arranged for the latest designs to be shown along with some guidance that the researchers should ascertain whether the customers are clear on the subscription terminology.

This has been scheduled into the next round of testing (due after this article’s submission date).

We get good feedback through the user research programme and I’m optimistic that my recommendations will stand.

What I’ve learnt from this process

  • As a word ‘expert’ it’s always worth scratching those itches to see if word choice can be improved.
  • It’s difficult for people to object to evidence so user research is important.
  • A good relationship with stakeholders, especially UX designers, oils the wheels, making the content designer’s job easier.
  • Acting as early as possible in the design process will reduce friction.
  • Opinions matter but if you can provide evidence and demonstrate the value your recommendation will make, you’ll find supporters.

Why is this good content design?

I didn’t set out for this change because it irritated me. I did it because I was focusing on the user journey and how this particular word choice shaped many aspects of it. The most important of these relating to how much the customer would have to pay each month.

Working with other experience design professionals, particularly UX designers and researchers demonstrates how content design is a collaborative process and can’t work in isolation. As word ‘experts’ our teams are looking to us to solve these word problems for them, and expect us to help improve the customer journey.

Never be afraid to open the can of worms

Categories
Content Design

The rise of the content designer

Content Designers weren’t around when I started in the computer industry, and whilst they’re not exactly ubiquitous in software teams yet, there are definitely more of us than ever. How did that happen?

Title card for The Rise of the Content Designer and an image of a person on the top of a ravine

How I became a content designer

I left university with a mediocre degree in computer science and accounting and sought out a job as a computer programmer. To put that in perspective, one of my first projects was working on the conversion of a successful MS-DOS programme onto that new-fangled Windows 95. It still hurts me a little that I’m now working with people younger than that operating system. Let’s not talk about that again.

Fast-forward twenty-two years and gloss over promotions into management, then sideways into Technical Writing, promotions into management again, before arriving at the land of the Content Designer.

I’ve had this job title for eighteen months and am still getting to grips with what it means to be a Content Designer.

Luckily everyone else on the team is still coming to grips with it as well.

But isn’t a content designer just a new name for a technical writer?

If only it were that simple.

I’ve been in the technical writing space for over a decade and worked on dozens of software projects. Toolsets have come and gone, organisation changes have sometimes decimated our workforce, whole departments vanish in the time of a conference call, but the tech authors remained. Our small team (always too small) endured, always floating just low enough under the radar to be left alone come reorganisation, but high enough that we had a certain mystique (ha, who am I kidding, outside R&D, people didn’t care).

At our most recent reorganisation, a new Experience Design department birthed itself with a pretty hefty thud. Rest assured, there was plenty of splashback and bodily fluids. An enigmatic leader proclaimed how we were to adapt to our new roles and put a focus on the customer (because we would never think to do that on our own), and many of us were faced with new titles.

The first Content Designers in our organisation came into being.

Six months later, someone smart thought to write a job description.

You still haven’t said what you do

Good point.

But the job description didn’t answer as many questions as we’d hoped.

“Content Designers provide locally-relevant micro-copy, learning content, and product self-help and documentation on a global scale. Content is right for the user and context, and right for the business.”

We already did all of this apart from writing micro-copy. What even was micro-copy? Was that another word for UX copy? Wasn’t that something the Business Analysts did?

Hmm. I didn’t feel like we’d made much progress but at least it was something to focus on.

We don’t work in isolation

Another change with the business reorganisation, was that we were part of an Experience Design team with other specialists including UX Designers, Researchers, and Solution Designers.

Our historical way of working was very much waterfall based. We were once assigned to individual project teams but as our team shrunk we ended up with multiple projects each. And we had no say in the design of anything. We might be invited to review meetings (equally, we might be forgotten) but our work wouldn’t kick in until the software was written and we had working code to play with. And then the focus was on writing help topics.

As content designers, that’s not what’s expected of us. We’re at the opposite end of the process, in the thick of it with the other designers. Did you hear me just say that? “With the other designers.”

How many content designers are there?

In our organisation of 15,000 people, anyone globally that worked within software development with a Technical Author title became a Content Designer. We do have some technical writers in isolated support teams that avoided the transition but their remit hasn’t expanded to include micro-copy.

We’re close to 30 content designers.

Not that many.

In a recent ISTC survey, with 154 respondents, 110 said they still had the job title of Technical Writer or similar. Content Designer wasn’t listed as an option, the closest being Content Strategist (4 people), and Other (45). The ISTC is perhaps rather self-selecting with many established professionals as members. What it does indicate is that there hasn’t been a mass rebranding of job titles across the industry.

Are we any better for having more content designers?

That’s too big a question to answer in one blog post.

What I can say is that from my experience, it’s a positive rejuvenation of my career. I’m still doing what I love, playing with words, but there is a much greater emphasis in our team on the words we’re putting in front of customers.

Collaboration with our UX designers is also becoming the norm (also a post for another day), and that has helped us get a better understanding of the customer journey far earlier in the process.

Time will tell whether this niche is here to stay, and as I feel like some kind of pioneer, there’s a certain responsibility to prove our worth to the organisation.

It’s going to take a lot of work for those transitioning into these roles to make a difference. There’s a mindset shift as well as some new skills to learn, change is uncomfortable for many, and this is the biggest change I’ve seen in my technical writing career.