In my last article for Ditto, I spoke about what content-first design is, and how it can truly work in a product-driven world where designers don’t get ownership over full experiences.

I’m part of a small design function within the wider eBay org. We’ve been working in a discovery space for a while now, looking into emerging tech in ecommerce. In some ways, this means we’ve had time to experiment with our ways of working. But our Figma files are messy! We’ve been spinning up pitch decks and concept pieces so we don’t always follow a set process.

Yet, the one constant is that we find ourselves coming back to content-first. 

In this article, I’ll chat about how my colleagues and I put it into practice. 

‍How we’re set up

For full context, this is how my design function area is set up. There’s:

• 1 content designer (me)
• 3 product designers
• 2 user researchers
• 1 service designer
• 1 senior design manager

We’re all working on a shared product space, but often own smaller parts of the wider strategy and report into different squads.

The start of a project

At the start of any project, we’ll all learn about the problem or opportunity together, alongside a product manager.

If it’s an existing problem or journey, we’ll investigate any previous work. This involves exploring design files and past research. We’ll critique what exists and agree on what we want to use going forward.

If it’s entirely new, we’ll use post-its to map out the general steps a user might take, as well as any considerations we need to bear in mind like business needs or product requirements.

The content structure

When we’re ready to actually start figuring out the structure of the journey (or interaction) we’re designing, I will write out the content skeleton or content wireframes needed. This might include:

• Writing the main goal of the page and then how the narrative unfolds
• Crafting a variety of messages to get early feedback
• Demonstrating how the content might change throughout the journey
• Defining the logic for any dynamic interactions – when should this heading be used versus this other heading? Would this link text only show if this certain condition is met?

This can look like:

• a flowchart in FigJam
• a bunch of post-it notes
• lots of lines of text referring to HTML elements like headings and buttons.

‍

‍

I like to get feedback from my design and product partners at this point, because it helps us to get closer to a better final solution before we’ve committed any efforts to visual design. I’ll either send a link in Slack for people to comment on a-sync, or bring it to a design crit where we can talk it out.

The fun messy middle

When the content structure is in a good place, we’ll start mocking up how it would actually look and work.

I’ll join our product designers in Figma to do this, using the content structure and playing around with different UI and patterns. We’ve got a good design system that makes this bit easier (thanks Evo!). 

Sidenote: In the past, I might not have been invited or expected to join in this part. But I feel confident now that I don’t even ask – and if I’m ever not an ‘editor’ of a file, I’ll say “I need access” rather than asking.

As a group, we’ll spend a bit of time exploring lots of potential ideas until it feels right.

Sometimes, it’s going back and readjusting that initial content structure. If we can’t nail the UI, it’s probably because that narrative just isn’t flowing well. Then we’ll go back to the content structure and tweak.

Learning as much as we can

As soon as possible, we’ll get in a room with our research partners and show them what we’re thinking. This never feels difficult as we speak daily anyway, sharing early ideas in Slack for quick feedback.

If there’s time and it’s the right thing to do, one of our researchers will launch a test – from standard usability to more detailed comprehension testing (how would people describe this feature in their own words? Is there anything they didn’t understand?).

Recently, we’ve found an “all hands on deck” approach works well. The researchers set up and run the test, but we’ll all help take notes. Once it’s complete, we all jump into analysis by identifying themes and coming up with tweaks based on the feedback. 

The result? Usually a whiteboard covered in participant quotes, research themes and ideas for design and content changes.

Another sidenote: sometimes running a test is not possible. I’ll still always ask researchers for their feedback on designs – they often spot patterns as they’re so familiar with what users love or hate!

‍

‍

The content is never ‘done’

If it’s needed, we’ll re-do the content structure based on the research notes and design suggestions. Obviously, this step isn’t always necessary.

Our highly skilled product designers take away my edited structure and annotations to work up some options in higher fidelity. This might mean changing the UI, because it no longer serves the content.

No one’s job title is precious.

I think my favourite thing about this group of designers and how we work is that no one is tied down to a job title.

I often try out my own designs in Figma and post them in our Slack channel for feedback. The product designers might rewrite some content or suggest new naming ideas. It’s a true collaboration, which I love 🤝

How did we get here?

It’s lots of little things built up over time. I’ve been here for 2 years now and we’ve finally settled into this rhythm. 

Some things that I think have helped:

• I set up a cross-function design crit and present work just like any product designer, so I’m not seen as ‘different’ or lesser than
• We don’t have a ‘content’ page or project in Figma. I do everything in the same ‘playground’ space as the product designers (obviously there are more strategic things in Docs, but the design part is all done together)
• I don’t ask for permission to join in. From the first day I got here I just did it, instead of asking. If I wasn’t involved, I’d just mock up something and send it out for feedback to product and design partners – eventually this made it feel normal!
• Meeting people where they’re at. I spend time with our product designers and observe how they work – instead of expecting them to always invite me
• Our senior design manager has set a culture of “we’re all designers, we just specialise in different areas”. I got lucky with that one!
• I regularly offer feedback on visual design and ask for feedback on content – this helps everyone feel less defensive and more involved.

Last but not least, I show content-first as a process instead of talking about it. Sharing screenshots of good work is better than moaning about not doing the work right.

Why it works for us

It’s not set in stone and everyone is very flexible to different ideas. But no matter how tricky the problem, this process helps us work out some of the knotty details.

For me, the best bits are:

• I get to feel like an actual designer. No one is gatekeeping Figma files or the visual design part
• The product designers get to upskill in content. And they often get an easier path to the right solution, working from content wireframes
• Our researchers can see where we’re going early on, and feel included in the design process.

Ultimately we aim to work content-first, but I think what gets us there is transparency and collaboration.

‍