It’s been one year since I took the leap into freelancing. Or rather, since I stumbled into it apprehensively.

I always knew I’d prefer to be my own boss, but the cozy stability of permanent employment kept me from making the switch. Knowing where my next paycheck was coming from was an enormous comfort in the early stages of my career. So it wasn’t until I faced a shock redundancy that I was able to reevaluate my priorities. Having some time off from work helped me understand that permanent roles don’t offer real stability—especially in the age of mass layoffs. And they often come with messy strings attached.

Everything that I enjoyed less about work, like lengthy performance reviews and stressful team politics, came from being a permanent member of staff. And everything I loved about it, like learning quickly on the job and doing work that aligns with my values, felt more achievable by going freelance.

A year into my freelance career, I feel a sense of work satisfaction deep in my bones. I’m a lot less stressed, I’ve taken more time off than ever before, and I’ve worked on projects that are already live and having impact — like the Generation Study and Juniver’s clinical trial.

So here are some reflections on life as a freelancer, one year in.

Biggest differences between freelance and perm

My relationship to work has changed

The stakes have changed now that I choose my own priorities and projects. Everything feels a lot lighter. I feel more comfortable, more effective, and less tempted to people-please. I know that each contract is temporary, so I try to make the most of each one.

I’m focused on deliverables

In past roles, I led teams and had reports to look after. I took my responsibilities really seriously, and often tried to fix everything for everyone. This left me feeling burnt out, and I neglected my own goals. Now, I’m only responsible for delivering good work. So when issues crop up, I’m happy to help — but I always prioritise the work I’m contracted to do.

I’m in charge of my own goal-setting

Rather than chasing content design leadership roles that are so rare in our industry — and often paid less than product design counterparts — I set my own goals now.

For example, in 2024 I want to share writing on Medium, work on another accessibility project, and take more time off. I’ll take these goals over another career progression chart or SMART goal template any day.

Things that aren’t so great about freelancing

I feel isolated sometimes

I miss the buzz of an office, I miss impromptu brainstorming sessions and coffee meetings, and I miss having built-in mentor figures. Working mostly on Zoom and Teams can be hard on the brain and the eyes — and the sense of collaboration isn’t the same.

I feel uncertainty about future work

This summer, it took me one month to find a new contract after my last one ended. This naturally left me feeling anxious. I tried to enjoy the time off rather than grasping for contracts that weren’t quite right — but it wasn’t easy!

I have to keep my portfolio up-to-date

Since I’m pitching for new clients often, I need to have fresh work ready to share. I have a Figma file where I’m constantly adding bits of work and metrics. It’s time-consuming but well worth it in the long run.

Tips for new and wanna-be freelancers

Get an accountant

Don’t try to navigate the choppy waters of IR35 alone. An accountant can help you set up shop and keep everything tidy in the background.

Find your network

Connect with other freelancers in your sector. They can tip you off to new contracts, offer advice about day rates, and even collaborate on projects with you.

Choose your clients wisely

Work with clients that align with your values and will make great portfolio pieces. And don’t say yes to an ‘impressive’ client if they seem like a hot mess or charge under your rate.

Make holiday time non-negotiable

Bake time off into your schedule in advance, and don’t change it. Clients are usually flexible about time off, and if they’re not, do you want to work with them?

What’s stopping you from going freelance? Or if you’re already freelancing, what’s different for you?

Diary of a (relatively new) Freelancer was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve spent my fair share of time reading Medium articles about design. This place is chock-full of pieces about the importance of partnerships in product teams. Writers and designers. Designers and engineers. Engineers, designers, and PMs. And it’s true — collaboration is paramount when building great products.

But there’s one duo that hasn’t yet had its time in the sun.

Traditionally, copywriters and engineers haven’t had much in common. Us writers deal in Word docs, our work in campaigns. Engineers speak a different language altogether (or many). But as the discipline of product writing becomes vital to building user-centred products, our worlds are colliding.

At TransferWise, the partnership between writer and engineer has become critical to our success. We work together end-to-end, from design sprints and usability testing to launch plans and QA. We make decisions together — and we understand each others’ stake in team plans.

But it’s not always easy to get the creative and the technical in sync. Especially when your team’s growing so fast you rarely have time to take stock. So here are some tips to build effective partnerships between copy and engineering in your organisation.

Run user tests together

We know that user research helps build empathy and curiosity for those who use our products. That’s why it’s important to test everything that ships. But sometimes, user research is considered part of design process, rather than an integral step for the whole team.

At TransferWise, we’re lucky to have a user research team who pave the way. They specialise in testing and analysis, and also help make sure everyone who works on a project comes to testing and takes notes.

Why get copy and tech involved? Because seeing is believing. When a team watches a user interact with a prototype, we all build a more emotional understanding of the product. Writers tend to be laser-focused on the words in the mock-ups. And engineers often imagine the human interaction with their code. But when we see users interact with it all, together, we arrive at a shared understanding of where to go next. There’s no need to explain findings later, or debate our reasoning. And it helps engineers make decisions on-the-go, with a more holistic understanding of the user experience.

So make it a priority to have writers and engineers figure prominently in your testing. I guarantee it’ll help build empathy for the user, as well as each others’ disciplines.

The job’s not done till it renders properly. On every device. In every language.

Writing product copy isn’t a quick process. There’s a lot of research and analysis that takes place before we put pen to paper (or text to a Sketch file). But things get more complicated when the product you write for is used around the world, like TransferWise.

Our copy is translated into 11 languages. And it spans across a whole host of devices, from desktop to mobile web browser and mobile apps. So after we deliver our source language copy, we pass the baton to our translation team and engineers. And sometimes, it doesn’t work out the way we planned.

Here’s an example. This is a bit of UI copy in the TransferWise Help Centre. It suggests three top-searched English keywords, encouraging the user to type into the search box. It looks beaut in its most-visited medium, the English desktop.

But when our engineers built it out across languages and devices, the copy didn’t have legs. Have a look for yourself.

Cut off in the middle of a word? Yikes. And it got even worse on mobile.

With a global product like ours, we need to write and build for every experience. That means having the foresight to think about character limits, punctuation, accessibility, and tone across different languages and devices from the start. And working with translators and engineers to plan and course-correct.

This is where the copy-tech partnership shines. When we push each other to account for different users at all stages of project, we’ve got a better shot at providing an accessible experience for all.

Streamline copy work with automation — and tech work with automated copy.

Ever do a large-scale content audit? Or try to wrap your head around all the translated or legacy versions of landing pages, articles, or blog posts? That usually means a lot of copy-and-pasting URLs into a spreadsheet, and hoping you didn’t leave anything out. When I started to do just that before a big content migration, the engineers on my team stepped in to help.

As writers, sometimes we forget that our words exist in a backend that has logic to it. So rather than go hunting for every bit of work, take a step back and see what can be automated.

Engineers on my team ran a script to pull the pages I needed — each with version control and localised counterparts. With that, what was to be a week’s worth of work suddenly turned into just a few hours. And a process prone to human error became incredibly accurate.

But this kind of collaboration is a two-way street. How can writers make tech work more efficient? Keep them from going hunting, too. That means making sure all copy is easy for your team to access, and the source of truth is clear. So when something needs to be shipped in a hurry, engineers don’t need to hunt for approval or translations — they’ve already got it.

This kind of cross-functional efficiency requires clear communication about what you’re working on, how you’ll do it, when it’s needed, and an honest projection of how long it’ll take.

So there you have it: a blueprint for the copy-tech partnership. I’d love to hear what’s worked for your teams, too.

By the way, we’re hiring. Check out transferwise.design to learn more about the design team and how we work.

I joined the design team at TransferWise six months ago. I’ll be honest: it took me a little while to understand how things work around here.

Our sunny corner of the London office is home to product, brand, and marketing designers, as well as copywriters and UX researchers. And a whole host of plants, too.

In my first weeks, I watched product designers sit with writers to co-work on prototypes, while engineers chipped in and analysts reported on progress.

I wondered how this kind of closeness to the product and collaboration was possible. And I wondered how I could carry it into my own work here.

So here’s what I’ve learned about the team, how we work, and how I put it all to use in my first project at TransferWise.

We design with empathy. And we’re all a bit different.

From sending hard-earned money to family back home to spending it abroad with the TransferWise card — people trust TransferWise to be simple, fast, safe, and fair.

As designers, our job is to understand what that means for our customers. We identify their wants and needs when it comes to their money, and then work out a vision to make it happen.

But we’re not all cut from the same cloth. Our design team is made up of many skills, backgrounds, and personalities — and five distinct disciplines.

—

UX researchers help us better understand our users, and product designers identify customer problems and design solutions to solve them.

Marketing designers help us clearly communicate our message, and brand designers make it recognisable and consistent.

And copywriters help it all sound clear, delightful, and effective.

—

Our many design tools allow us to explore different possibilities and find unique solutions to our customers’ problems, together.

As a team, we each bring our expertise to the table to build a strategic vision. And then we work out how to do it, step by step.

And then we help our product teams focus on what people really do, want, and need.

We don’t work with product teams. We work in them.

There’s no way we could achieve our goals as designers alone. Instead, many of us bring our skills to product teams, where we can really sink our teeth into specific areas of the customer experience.

With a team of product managers, engineers, and analysts, we identify the challenges our customers face, define a mission to make things better, and then get started.

We work everyday with our teams to understand and improve different parts of TransferWise for our customers. Each product team is autonomous and empowered to solve the problems they feel are most important. With everyone we need to get it done, we work together from start to finish to solve problems big and small.

That’s why, on any given day at TransferWise, I now find myself brainstorming with UX researchers to launch experiments, working on landing pages with marketing designers, getting knee-deep in numbers with analysts, and thinking big picture with product managers.

We solve big problems. Together.

With an understanding of how we design at TransferWise, I embarked on my first project with my product team, Help Experience.

—

The challenge: customers struggle to find answers to their questions in our Help Centre. Instead, they skip straight to contacting our (amazing) customer support team.

The mission: help customers help themselves, so they can have a little more time back in their day. Guide them to the right help articles at the right time.

The team: Product manager, product designer, analyst, engineers, our customer service lead, and me, copywriter.

And help from: UX researchers, brand designers, and marketing designers.

—

We have a tried-and-true process to get to the core of our customers’ struggles and figure out how to fix them. So, during a team summit in Budapest, we got started on fixing our Help Centre.

1. Really and truly understand the problem.

We knew the Help Centre could use some design and copy love. But we didn’t know just how much our customers needed it.

Our analysis revealed that more than 60% of our customers who visited the Help Centre weren’t reading articles to get the help they needed. Instead, they went straight for the Contact Us button.

So, we ran a series of tests to understand why users weren’t reading our articles. Turns out, when they visited our Help Centre, they felt lost and underserved. They wanted more structure and context to their own experience.

2. Decide on design principles.

Once we knew what we needed to improve, we came up with some principles to focus our work. Here’s what we decided.

Contextual. Information is relevant to my profile, state and journey.

Intuitive. It’s easy to find what I’m looking for.

Organised. I know where to search for something when it’s not presented to me.

Beautiful. I find it pleasant to look at and use.

3. Build a prototype and a plan together.

Armed with principles to guide us, we determined how to design, test, analyse, and build the new Help Centre.

As a team in Budapest, analysts were sketching on whiteboards, product managers were devising the perfect user test, and engineers were planning how to measure success. I know, it sounds like design heaven. It kinda was.

4. Test and improve.

We returned from Budapest with a Help Centre prototype that everyone on our team contributed to and believed in. Then, we put it in front of customers to see what they thought. Then we did it again (and again, and again).

After many (many, many) design and copy tweaks, we created an MVP that we’re ready to build.

5. Ready, set, build.

Our engineers are hard at work building the new help experience. So, stay tuned — we can’t wait to see what our customers (and you) think.

—

Sound like a nice place to be designer?

Well, we’re hiring, and we’d love to hear from you.