A day in the life of a Content Designer

Adam Stokes
Purplebricks Digital
7 min readApr 21, 2021

Adam Stokes | Senior Content Designer at Purplebricks

An accurate representation of the start of the day… maybe minus the Duff beer.

Ask me again tomorrow, you might get a different answer

The best part about working in a product-led environment within Digital is that when the work is planned effectively, you’re very rarely doing the same thing twice.

Problems require solutions, and even if that means testing and iterating, you’re usually focussed on a new problem once you’ve finished the last, or at least a similar one under a new lens. In a broad sense, of course you could categorise the work we do as fitting under the umbrella of design. So sure, I write and design every day.

But at a granular level, the specifics of what I’m tackling often brings new problems sprint to sprint, day to day. So, while you can lean on design patterns and best practices to aid your decisions, you’re always having to think at pace.

And having worked in an agency environment early on in my career—where retainers were planned in month by month and you might be presented with a list as long as your arm of duplicitous items that needed completing over that four week period—I can tell you that this way of working most certainly suits me better.

Some of the activities Content Designers get up to in a day

09.00—10.00: Squad standups ☕️

Any good Agile day starts with a standup. I happen to have a few as I’m currently supporting a number of other squads alongside my primary one.

We start promptly at 9am, covering our Kanban board from right-to-left, from most recently completed work backwards towards our To-do column. This method isn’t adopted by all the squads, and the discussion of which Agile methodology is ‘better’ between Scrum and Kanban is a long-raging and somewhat redundant one, given both can work just as well as one another in different environments. Given the size and make-up of our squad, and the focus of our work, this approach works perfectly for us.

As well as covering our daily status updates on our work items, we also use our 15 minutes to cover any necessary user feedback that might have come in overnight from HotJar, or any tickets that might have been raised by the Support team that could take priority over any of our planned work. In those cases, any one of us (or all of us) may end up swarming on an issue in order to resolve it.

11.00—12.00: Design share 🥐

As a large, growing design team of 12—made up of Product and DesignOps; Product Experience Leads; and Product, UX, UI and Content Designers—it’s important that we are all tuned into what one another are working on, at squad level and beyond.

And while our now predominantly remote working environment has many advantages in terms of making many of our working practices much more efficient, these meetings also aim to combat the fact that there are less natural opportunities for ad-hoc catch ups, (though that’s not to say I often don’t conduct Teams calls to discuss something quick and trivial as an excuse to virtually socialise if I’ve had a particularly solitary day).

Design representatives from each squad take 5–10 minutes to give a very top level view of their focus within the current sprint. Where the need for further discussion or collaboration on a piece of works arises, we make a note of any separate catch-ups that need to happen outside of the meeting. This helps us to drive consistency across all our design work, initiates healthy peer to peer feedback, and makes us aware of any potential duplication of efforts that could occur.

Effectively, it allows us to stay in the know with that we need to know, when we need to know it.

13.00—13.30: Writing and designing at pace 👨🏻‍💻

When it comes to approaching copy and content, there are various different ways to practically address this based on the changes themselves, the environment they’re in, and the context of what is required.

In instances where we are making changes to existing language, but where this won’t have an impact on the visual or interaction design itself in any way, I have the ability to address them in isolation.

What this doesn’t mean is that I’m sat in Microsoft Word, completely detached from the user experience, in order to formulate a solution. In fact, for me, word docs are the last things I create, and are used only as a method of documenting the language and design thinking already made.

The best way to practically work on changes like this is with a very handy but under utilised tool I like to call Design Edit. It’s a bit like using Inspect element to make surface level changes to a web page, but without having to even pop open the hood.

  1. Open a new tab in Google Chrome
  2. Hit the bookmark star icon and select Add Bookmark
  3. Select More…
  4. Paste following into the URL field:

javascript:document.body.contentEditable=’true’; document.designMode=’on’; void 0

5. Name it accordingly (I’ve named mine Design Edit), and click Save

6. If it’s not already, drag it into your Bookmarks Bar.

7. To test it out, simply navigate to a web page, and click the bookmark.

You won’t see a refresh or visual indication of any kind, except for the fact that you can now select any body content on the page, and amend it however you please.

When it comes to making content focussed changes that don’t require any heavy lifting from a UX or UI perspective, this is a much, much more efficient way for me to work within the real environment, without having to mock up a design file. It allows me to generate quick, simple visuals for stakeholders, engineers or other disciplines when I want to kick off quick and collaborative conversations on proposed changes, without the need to over-engineer the visual documentation.

14.00—15.30: Pairing in Figma ✏️🎨📐

Then there’s the heavier lifting. Much of what we do won’t fit into the way of working outlined above, which is where pairing with my fellow designers in a collaborative environment really comes into its own. The ability to facilitate collaborative working within our primary design tool is one of the core reasons we decided to move to Figma.

Designing efficiently hinges on us being as inquisitive as possible, as early as possible.

Myself and my design partner(s) will jump on a Teams call (Microsoft told me I spent a total of 18.3 hours on Teams calls with my Senior UI designer partner last month), share screens, and run through a Figma file together. We’ll discuss and get our heads around the full user flow, including all the possible scenarios we need to design for. This will often involve some note taking, reactive discovery, and maybe a bit of back and forth in terms of challenging and questioning one another’s ideas to get the best out of each other. Designing efficiently hinges on us being as inquisitive as possible, as early as possible.

Once we’ve identified what we believe to be our full journey map and the high fidelity wireframes have been crafted, I can get to work on reviewing the templates and populating with the appropriate content. Part of this may very well result in me questioning what we have formed at wireframe stage, and us going back to the drawing board as a collective design group, discussing whether in this instance the UX or UI needs to be led by the content, or vice versa. Other times every element of design may hold equal weight. Each design decision we make is different, and always depends on context.

Once we get the designs to a place we feel is pretty close to completion, I’ll transfer all the content into a word document.

16.00—17.00: Other stuff 🖇

As Senior Content Designer, part of my role entails working very closely with Product and DesignOps to plan ahead and help manage the Content Design function. This means everything from quarterly capacity planning to reviewing velocity and being involved in the recruitment, onboarding and management of new and existing members of the team.

I will also often use open pockets of time to collaborate with the rest of the Content Design function and discuss any recent updates or discussion points. This often includes updating our Copy Style Guide as we uncover and craft new language patterns while carving our way through different areas of the user journey, from one customer type and device type to the next.

Having to jump between thinking as broad as quarters, to as granular as which verbs we should be using within call-to-action buttons and why, certainly has it’s challenges. But it’s what makes each day as different and interesting as the last.

So, what does a day in the life of a Content Designer look like? Ask me again tomorrow, you might get a different answer.

Disclaimer: Like any good biopic, some timelines and events have been altered and combined for story-telling purposes.

What? You thought that when you watched ‘Ali’ or ‘Steve Jobs’ that everything happened exactly in the order they said it did? If this blog can teach you anything, let it be that creative license is the key to any good story telling.

--

--