top of page
Website Chart

UX writing samples

As a manager, my value is not always evident across an entire project in the same way an IC's is. Here is a collection of key points in projects where I improved the design or content during a design review. 

I have focused on examples that highlight content and design at the component level to best showcase my content design skills.


Simplifying instructions
and the interface


When reviewing this project I immediately spotted a number of problems:

1. This is the first time the user would set this up this feature, so the title really should be "Set up..." not "Edit...".

2. "Balance threshold" is not a common phrase, and while possibly understandable, is not user-friendly. It's also unclear if the recharge happens when the balance is at or below this threshold.


3. The way the two text field titles are written has resulted in the need for an overly long explanation underneath.

4. Mismatched wording. Is it "recharge" or "top up"?

In the improved version, you can see how I rectified these problems, resulting in both a clearer user flow and a simpler, cleaner interface.


Improving unclear design

While this kind of problem is caused by design and not content, it's one I come across quite often; that of, I can't write anything here that makes this clear. I've included this here not to show bad design, but the value of having a UX writer included in the design phase.

A lot of simple logic issues get missed during design. Also, bear in mind that this project had already gone through a design review before I saw it. It was only when I reviewed it that the problem became evident.

The problem in this case was that the designer had used a stacked bar chart, rather than groups. 

If we look at a single bar in the first design, say Oct 2, it shows  "Claims submitted" plus "Claims paid" combined equal 5000. But this is not really the case. The two can't be combined into a larger group. If 5000 claims are submitted, and 2000 are paid, you don't suddenly have 7000 claims in total. You still only have 5000 submitted. These two should be two different bars, as seen in the second design.

I also adjusted the wording on these charts. I'm not 100% happy with "Claims submitted over time," but since that is what the number directly underneath represents, it's the best solution for this chart.



inconsistent design


Inconsistent design is one of the biggest problems I have to deal with at AfterShip. Although the company follows Shopify's Polaris design system at the component level, each designer uses components differently.

Here you can see how the designer using a radio button for this option has resulted in awkward content in the first image.

This setting is to decide whether the field should be mandatory. But this does not pair well with a "Disabled/Enabled" option. This sounds almost as if you're deciding whether to display the field or not. In actual fact, the field will always show; you can only decide to make it mandatory or not.

The reason I avoided a radio button is because in AfterShip's products, radio buttons have been reserved for turning a feature on/off. To avoid confusion, I suggested a checkbox.


Guide don't just explain

This is a project I reviewed for a junior writer on my team. UX writing is not just about explaining features. Sometimes a user needs guiding through an interface, rather than being told simply what a feature does.

In the example here, the first version tells users what an A/B test does. Firstly, this is the wrong place to introduce the concept of an A/B test. This popup only appears after clicking "Create A/B test". The user should already know what an A/B test is before clicking that. If they don't know, they're unlikely to click it. If the concept does need explaining, do it on the UI before they click. This is far too late in the user flow to be explaining.

Secondly, by explaining what an A/B test is, the writer failed to guide the user in actually setting one up. The body text and the radio buttons seem disjointed. The options have not been explained clearly and require some mental acrobatics to understand.

You can see in the improved version that the body text is used to guide the user through the flow and explain what the two options mean. Normally I would use "Create" for the button, but this was a multi-step flow.



Teaching UX designers to design content


Content design is a part of product design. Quite often the problems I encounter are a result of the original design. As a leader, it's also my job to help coach and train UX designers to consider and solve content design problems for themselves. 

I can't fix every problem every time. A better approach is to improve the content design skills of the entire UX team.

In this example, we have a notification banner (in blue) on a modal. The designer made three different notifications for three different scenarios. My question to her was, "Can all three scenarios happen together?"

She hadn't considered this. And the answer was yes, they could happen together.

But we can't add three banners to a modal. I had a solution. However, I wanted her to come up with one herself. First, she decided we should create seven different banners, each with a different combination of information points. 

Again, I knew a better solution, but I need the design team to also think about content during their design phase. I asked if there was a better way. Seven different banners is a lot to manage. Could we combine the messages at all? Would any information always be shown to users?

She agreed that one of the notifications would always be shown to the user. So after discussing it with her, we decided that this was not a notification. We should add that information to the body text on the modal so that it's always shown.

We worked together to combine the other two notifications into one banner with two bullet points. This way, the engineers can develop one banner and simply combine one or two bullet points depending on the situation.

This approach was designed to stop me from having to solve design problems all the time. It's a way to involve the designer in the content design process and make them feel like part of the solution. It also means that moving forward, this designer will hopefully look at content design differently.

bottom of page