Finding the bigger opportunity in a simple feature request.

It started with a list.

One of the things users could do in Mosaic was explore businesses - searching and filtering millions of companies using everything from location and industry to financial and behavioural data.

A seemingly simple request came back from users:

Can I save a list of businesses?

The obvious answer was to build lists.

But before designing another feature, I wanted to understand what people were actually trying to do.

The useful part wasn't really the list itself. It was being able to collect businesses they'd found, organise them around whatever they were working on and come back to them later.

That opened up a slightly bigger question:

What does saving and organising things in Mosaic actually look like?

Designing the idea, not just the list.

Businesses could be discovered in several places across Mosaic - through search results, filtering, maps and individual company views.

So saving them couldn't just be a feature sitting somewhere else in the product. It needed to fit naturally into the process of discovering them.

I explored ways for people to:

• save an individual business as they found it;
• select and save multiple businesses from a set of results;
• create a new collection without interrupting what they were doing;
• add businesses to something they'd already created;
• recognise things they'd previously saved;
• return later and continue working with them.

The aim was to make organising something feel like a natural extension of finding it.

Even the name needed figuring out.

For something so apparently simple, terminology turned out to be surprisingly important.

User Lists was probably the most immediately understandable description, but Mosaic already had a List View for displaying search results.

Would having lists inside a List View be perfectly obvious, or unnecessarily confusing?

Collections was another option and potentially gave us more room if the feature expanded beyond businesses later.

Rather than pretend there was an obvious answer, I used both ideas while developing the feature. The intention was to test the terminology with users once we had something tangible enough to put in front of them.

Looking beyond the immediate request.

Once I'd started treating these as collections rather than simply saved search results, it was worth exploring what else they might eventually enable.

One obvious possibility was sharing.

If somebody had spent time finding and organising a useful group of businesses, being able to share that collection with a colleague could make it considerably more useful.

I explored how that might work in the interface, but it deliberately remained an idea rather than a validated feature. We hadn't established whether users actually needed it, and it never progressed beyond the design work.

That's an important distinction.

Product design isn't only deciding what to build.

Sometimes it's making an idea tangible enough that you can decide whether it's worth building at all.

The bit I like about this one.

There's nothing particularly spectacular about saving something to a list.

That's why I like this example.

The interesting design work wasn't making a nice-looking list. It was taking a very straightforward request and thinking through how that behaviour needed to work across the wider product.

Building a dedicated additional list feature might have been easier.

Questioning the potential underlying structure gave us something that would fit more naturally into the way people already explored Mosaic, while leaving room to test the things we didn't yet know - including what to call it and whether ideas like sharing were actually useful.

Sometimes product design is inventing something completely new.

Sometimes it's simply asking a few more questions before you start drawing the answer.