As an experiment and way to learn what AI is capable of, I decided I’d co-redesign this portfolio with AI tools by my side. The biggest barrier before was always getting started; this site was built with Bootstrap 3, Jekyll, and a pretty old-school build pipeline almost 10 years ago now. I could barely remember how it worked, let alone think about how to modernize it without starting from scratch.

Migrating any site, even a small one like this to a modern framework like Tailwind would’ve been a huge pain in the past—but AI (specifically, Cursor) helped me find momentum and get across that painful barrier in less than an hour. In the past, that migration barrier alone killed my creativity every time.

Then the question became: what do I actually want a refreshed version of my portfolio to look like? What was interesting is, if I’m honest, I struggled to come up with a direction. I probably would have stalled out here in the past—but AI has changed the way you can experiment, too.

I grabbed V0, and started iterating on ideas for the overall vibe and energy. I knew I wanted some sort of animated, gradient-esque energy, but I didn’t want just some generic thing. While I’m confident writing code myself, this type of animated, generative canvas experience is a bit further out of my grasp than I’d like. V0, however, is plenty confident playing in this space. So I experimented—a lot.

I played with weird ideas for weeks. Blobby gradients. Spinning 3D orbs. “Normal” gradient animations. Weird 3D stuff. It was incredible to be able to actually throw an idea out there and see how it would feel. Eventually, I found myself gravitating toward an idea that felt fairly unique, and a fit for my experience: an ASCII-art gradient wave tool.

Once I had a direction, V0 was really great at helping me actually iterate on the overall vibe. I asked it to create a control panel for all of the parameters in the wave so I could play. It could add themes. Entrance animations. Accessibility features. And, even a button to copy the configuration from that playground, ready for dropping into my actual site. V0 even happily helped me figure out how to adapt the React-based output to work in my decidedly not-React-based Jekyll site perfectly.

While I probably could have eventually come up with the ASCII-wave in Cursor eventually, V0 is notably better at rapid iteration on well-contained visual ideas like this. It seems to interpret open-ended creativity a lot better, and the iteration feedback loop was tighter. When it was ready to go, I just grabbed the code from there, and went back to the real work in Cursor.

For a personal project like this, iterating with Cursor and V0 was addictive. Coming up with an idea, and being able to play with it immediately is incredibly empowering. It’s also hard to know when to stop when your AI companion will happily oblige every possible weird idea you can come up with. I probably could have re-launched this site a while ago, but kept finding new ways to tweak it and play. I decided that what you see now is good enough, and I can always iterate on it in public later.

I won’t brag that I have the most creative or innovative portfolio ever, but for a design manager that doesn’t get to spend as much time as I want in the code anymore, co-designing this site with AI was incredibly liberating—I could do things I would have never pulled off on my own. Instead of toiling for weeks on a direction, I could pull weird ideas straight out of my head and onto the page to see if they worked.

It also helped cement my belief that AI prototyping of ideas is going to unlock a new wave of creativity in the tech industry, especially in my role. We just need to completely reset how we think about the design process, and move towards showing rather than telling through the use of prototypes.

Since writing this, I’ve taken the same experimental approach into my work with product teams. I built Protodash, an AI prototyping system that helps designers and product managers turn ideas into realistic, shareable product experiences.

If you’re interested in playing with the ASCII art gradient tool that powers the site, head to the gradient playground.

I’ve been living away from New Zealand for more than 5 years in 2020, with the majority of those in Amsterdam, but we recently moved to Canada in late 2019 for something new: jobs drew us here, but the allure of Canada drew us in. We arrived in Toronto in August, and it’s been almost too easy of a move so far.

But, when COVID19 struck Canada in February, and the lockdown began here, the New Zealand government began urging citizens to come home, regardless of where they were, as soon as possible–it seemed unlikely that commercial flights to the country would be viable for much longer, and authorities insisted it was time to act.

As someone living away from ‘home’ for so long, this presented a difficult crossroads: do we pack up and head back on a dime? Is that even home anymore, after almost 6 years away? Family insisted that perhaps coming now would be a good idea, before New Zealand went into lock-down, which was honestly incredibly tempting–and far away from any danger, with those we loved, even if the reality of that wasn’t really true.

Of course, such a move is not trivial when you’re invested in a country and deeply bought into staying there. I have a house full of things I like, a job + team at Shopify I love, and a cat–jumping on a plane isn’t that easy, let alone wise. Even if we were to consider it, such a move would be difficult to undo, given the circumstances, especially in Canada: as visaholders, if we leave the country right now, we aren’t eligble to come back in until the border re-opens, a process that may take months.

But, most confronting of all was a question I’d never needed to actually grapple with: where is home after so long abroad? What would it even mean to return, and try to slip back into life there, all of a sudden? New Zealand will always be toku kainga (my home) in spirit, but actually deciding to return was never something we had on any meaningful time horizon to do. Choosing to stay in Canada felt similarly fraught: what if someone close to us were to get sick? The choice felt impossible.

In the end, the decision was fairly clear: the right thing to do for everyone, to prevent any spread, was to stay put in Canada, no matter the temptation of a far away land that feels safe for weathering a storm like this. And in the meantime, it meant making a decision that I’d never really conciously come to in the first few years away: that here, Canada, is where we’ve made home, at least for now.

I know that many other kiwis around the world must have been in similar positions, and have been forced to make the same difficult choice as well. The hard truth is that it’s painful to make this decision, especially when all you want is to be with family and friends on the other side of the planet.

No matter what you decided, Kia kaha, we’ll make it through this.

UX writing is the practice of designing the words people encounter inside a digital product—from navigation and button labels to onboarding, error messages, and help. Unlike marketing copy, its primary job isn’t to attract attention or persuade someone to buy. It helps people understand what’s happening, decide what to do next, and complete a task without unnecessary friction.

In this conversation, Femke and I discuss why writers should be involved from the beginning of the design process rather than brought in to polish an interface at the end. Strong UX writing comes from understanding the language an audience already uses, testing words alongside the interaction, and keeping terminology consistent across the product. Working this way often exposes design problems early, before they become expensive to fix.

There’s an important distinction between traditional copy-writing roles and where a UX writer sits on a team, as well as what they actually do in their role. I saw a thread kicking around about this being commonly misunderstood, which can lead to painful misunderstandings in the space without clarity.

Your first job, always, is to write user-centered content. If it's not helping someone understand something, use something, learn something–if its sole function is to "express the brand", you have likely erred. Doesn't mean you can't have fun, or add delight, but it's secondary.

— Scott Kubie (@scottkubie) February 28, 2019

As an external UX writer, I get a peek into this at all stages of companies, which helps understand where the need truly lies. Here’s a breakdown of where UX writers sit in an organization, and how they’re different:

It’s all about the user

Lots of writing is guesswork. UX Writing shouldn’t be. Your job as a UX writer is to understand the user personas that an app needs to hit on, then write copy that best serves that audience.

That usually means doing research into what types of users a product has, what their literacy level might be, their age, and all sorts of variables along these lines. This is absolutely necessary to understand what they want and what’s causing the most friction right now, and helps us get to the right solution much faster.

You can’t write great copy without data (even if it’s just a little). But, most writers do! I’ll often work with a new client and ask for access to their analytics or user demographics, and they’re surprised: why would I need that? Well, otherwise I don’t understand the user.

If there’s no data, we can go one further: talking to your users. This could be direct, in the form of user research interviews if there’s time, or a simple survey asking questions about their intent, whether they find anything confusing about the product today, and what their background is.

As the UX Writer, my job is to think only from the perspective of the user. How will they experience this? What do we want them to take away from this screen? What is the user trying to get done, and what are we trying to push them to do? Are those in harmony? It’s our job to balance these priorities effectively.

It isn’t about your ego

One of the common misnomers about UX writing as a process is that the copy at the end should have more ‘sparkle’ or ‘polish.’ We aren’t here to make your copy funny, or have more personality.

UX Writing is here to get out of the way and make the experience clearer. It’s an incredibly focused, specific role because we’re working to helping the user get to where they want to be, so it drops all pretenses, unnecessary charm and fancy marketing copy.

If you’re looking for a voice or quirky marketing copy shoehorned into your product, you’re going to be disappointed. Your users don’t want that either—it’s probably just going to piss them off because they just want to get shit done.

It’s totally fine to be friendly and try to have a personality. Just don’t over do it, and end up using humor as a crutch for good copy.

We’re not here to convert

If we are, you missed the UX part of the role, and are confusing the job for a copywriter. A UX Writer may possess some of the skills required to do marketing copywriting, but that isn’t why we’re here, and that’s a whole job on its own.

Don’t confuse the two or try and fill a role for a ‘unicorn’ UX Writer who does both on the same project, because you’ll quickly discover that when the lines end up too blurry, it’s just selling all the time, even in your app. If you’re hiring for a UX Writer, keep it simple, and focused: they might have both sets of skills, but muddying the water makes it difficult to do an effective job.

The disciplines are separate for a reason: once your users have signed up, they don’t want to be sold to anymore! They’ve already cleared the hurdle of signing up — you’ve got their attention — so selling even harder can come across as desperate.

Copywriters are practicing the ‘Always Be Converting’ discipline, but we’re here to ‘Always Be Clear’ (or, perhaps, Always Be Concise). We want to keep users and have them understand how to use your product, not push them away.

This is about more than just words

UX Writing often goes beyond just the words and microcopy in your app that you see. It can easily encompass complex tasks like direct feedback on the layout of the signup flow, placement of buttons or even a redesign of a page.

That’s why it’s useful to include UX Writers at the start of a design sprint, and why we’re sitting at the table with the designers rather than the marketing team. UX Writing is about using copy as a design material that adds to the user’s experience, adding the words as a consideration to the design process. Adding UX Writing in at the very start helps make it easier, just like you wouldn’t write the ending for a book before the first chapter.

Working on UX copy early makes life easier simply because the process of solving UX writing problems often reveals design problems as a side effect, which can be addressed at the same time.

This doesn’t mean you can’t do a UX Writing project at a later phase, and shouldn’t scare you off doing so. I’ve personally enjoyed jumping into existing products and performing retrospective UX Writing work, but it’s harder: the design is already in place, the flow is much more rigid.

Often, I’ll be making suggestions about the UX surrounding the words that could be improved or ways the flow might work better, but at later phases, this is much harder to implement.

Building better products requires caring about the words you use. UX Writing isn’t just another fluffy job title that’ll disappear with time, because the words you use tell your own story.

Invest in your product’s words, and you’ll find your users love you for it: you’ll show that you’ve taken the time to smooth out the rough edges and build something with them in mind.

Go forth, and be concise.

UX Copy is a hyper-focused discipline within the world of writing: it’s about crafting the voice your product projects into the world, and understanding how others interpret that. The UX writer distills that knowledge into a voice, and creates a repeatable system for the way your product speaks to users.

As a result, UX writing often sits somewhere within the design organization of your business, as a part of the design process before a product is built. That’s intentional, ensuring your product is able to speak to users effectively.

There’s a lot of ways UX writing is great for business, so I thought I’d share what it’s like to work with a UX writer from my own perspective, and how UX writing can help your business.

Seeing through your user’s eyes

You’re probably accustomed to working with copywriters, but there’s a big difference when it comes to the world of UX writers: it’s less about flashy copy, catchy sentences and cute wording.

UX Writing is about considering the overall flow and implementation of a design, and how it guides a user through it. It isn’t about giving the user cute error messages like “oh no, something went wrong,” but is focused on providing them with a clear path forward through the use of copy.

A good example of this from my previous work is a client that wanted help with the onboarding flow, as users were falling off along the way, without completing it. After taking stock of all the strings in the flow, it became apparent that the action button designed to push the user forward was changing on every step: sometimes it might say “Get my API key” and other times it said “Next.”

For users, this was confusing. Not because they were stupid, or unable to understand how to move forward, but that they actually didn’t want to complete the task the button implied much of the time. Putting a blocking step that says “Get my API key” when a non-technical user signed up meant they figured it was the wrong place, and started trying to exit the flow.

This is called ‘moving the cheese’ which alludes to a mouse trying to get to where it wants to be, but the final destination seemingly not on the horizon. We made a number of changes to the flow, including the use of titles and descriptions to help the user understand if they needed to do something, and most importantly, a consistent way to move forward.

If you’re building an onboarding flow, or helping your users for the first time, copy is one of the most important tools you have to help people with difficult to understand concepts. Looking at it from their perspective (and in many cases, identifying what type of users are the audience), then guiding them forward so that it’s always clear what’s next is key.

Understanding the technical details

UX Writing can do a lot of heavy lifting for you, if your writers understand what’s going on and are able to help translate that for the user. As a writer with a technical background, I’m allergic to jargon like ‘authentication error’ or ‘gateway unavailable,’ because it means nothing to your users!

The job of a UX writer is making it incredibly clear to the user what’s happening both when something in your app goes right and when it goes wrong. A good UX writer should understand the technical details of what’s happening, and translate this into something coherent, simple and actionable for the user so that they always have a way out of a dead end.

Here’s a practical, fabricated example I often see around the web:

Authentication error: [523] Unable to access this system.

I hate these errors, because they’re written by developers, and I can’t even understand what’s wrong here. Did I do something wrong when trying to log in? Is the system down? Do I not have adequate rights to log in?

In projects I’ve worked on previously, I try to understand all of the error states we might end up with and work them into specific, cruft-free messages that lead the user to understand what to do next. We could take the above error and transform it into different error states, depending on what went wrong:

In the case of the user typing a wrong email or password:

Sorry, your account details were incorrect. Reset password here if you're stuck.

In the case of the server having unknown technical problems:

Our services are unavailable right now, so we can't log you in. Try again soon.

And, one last unique message, in case a user’s account isn’t actually allowed to do that:

Your account needs permission to access this area. Click here to message the team owner for help.

All of these messages tell the user precisely what went wrong, why, and don’t leave them hanging wondering what’s next.

Concise text always wins

When developers are left to fill in text in an application, they tend to do so by being overly verbose, or adding way too much text that adds little value to the message.

In the fantastic book On Writing Well by William Knowlton Zinsser, he says that “the secret of good writing is to strip every sentence to its cleanest components.” You should seek to do the same across your product, because it offers a refreshing change of pace: getting directly to the point.

One of my favorite error messages of all time comes from iTunes, the software that will never truly die. If you plug in an iPhone with music synchronized to it, this error appears:

The very long string for this is:

The iPhone (Name) is synced with another iTunes Library on (Computer). Do you want to erase this iPhone and sync with this iTunes Library? An iPhone can be synced with only one iTunes library at a time. Erasing and syncing replaces the contents of this iPhone with the contents of this iTunes library.

The first line of text was enough to make me panic, and not bother reading the rest; You’re going to wipe my iPhone? Please don’t! The second line actually clarifies a little bit that this is about music, but it doesn’t offer up any reassurances it won’t just wipe the entire phone. Worse still, the button says Erase & Sync which is not reassuring.

I’m stumped by this error message every time I’ve encountered it, but it could be vastly simplified:

*Do you want to replace the iTunes library on this phone?* You can only sync an iPhone with one library. Continuing will remove iTunes so you can sync with this computer.

Much clearer, right? But it still feels a bit long. We could push this further, given it’s implied the device can only handle a single library:

Replace iTunes library? Continuing will remove iTunes content from your iPhone so you can sync music from this computer.

As for the buttons: OK and Cancel would suffice with the text re-written, given we aren’t planning anything destructive.

Rachel Mullins has a fantastic article about how to apply these practices to your own app if you’re not able to hire a UX writer. Simple steps and a set of rules about how you talk to users goes a long way!

Bring writers in early

The best thing you can do for your business is bring UX writers in early, as you’re first imaging what your product might look like, to help craft copy that forms a tight knit with your design. The way your products speak to users are what they’ll remember, and getting it right the first time can grow your business in the long haul.

If you ever need help or advice, I’ve worked with lots of products, big and small, and love hearing about the challenges teams face talking to their users. Say hello!