Designing a filtering model that works across products

The challenge

Filtering seems like a straightforward interaction problem, but it becomes more complex when it has to work across different kinds of information and different user contexts.

I first worked on filtering for a file-finding experience, where the goal was to help people progressively narrow a large set of information without requiring them to construct a precise search upfront.

When I later began working on filtering for a calendar experience, I recognised the same underlying interaction problem.

Rather than treating Calendar as an entirely separate design challenge, I used the principles we had developed for Files as a starting point and explored how they could adapt to a different context. Files and Calendar are both part of the Microsoft 365 Companions suite.

01. Starting with a reusable interaction model

My work on Files gave me a useful foundation for thinking about filtering as a progressive interaction, rather than a collection of individual controls.

The broader idea was simple:

Start broad, give people meaningful ways to refine, and keep the interaction lightweight.

That shifted my thinking from designing a feature for one surface to asking a larger question:

What should remain consistent when the same interaction pattern appears in another context?

This became the starting point for my work on Calendar.

02. Adapting the model, not simply reusing it

Calendar presented a different information model and different user needs.

My goal wasn't to make the two experiences identical. It was to understand which principles should carry across and which needed to adapt.

That distinction became important to how I approached systems thinking. Consistency didn't mean copying an interaction from one product into another. It meant creating enough familiarity to make an interaction understandable while leaving room for the context to shape the experience.

03. Exploring the solution space

I explored multiple approaches to understand how the filtering model could work in the Calendar context.

I built an interactive prototype so that the ideas could be experienced rather than discussed abstractly. The prototype helped me compare interaction models, surface trade-offs and give the wider team something concrete to respond to.

At this stage, I deliberately kept the space broad. The goal wasn't to arrive at the answer immediately. It was to understand the possibilities well enough to make a better decision later.

04. Bringing research into the design process

I partnered with research to pressure-test our assumptions and understand how people made sense of the experience.

Rather than treating research as validation at the end, I used it as another input into the design process, alongside the prototype and feedback from cross-functional reviews.

I also shared the research outcomes and design exploration with the wider team so that we were making decisions from a more shared understanding of the problem.

05. Recognising when exploration needed to stop

The exploration did its job: it showed us what was possible.

But it also created a new challenge.

We had several viable directions and a lot of feedback. At that point, I realised the team didn't need another design iteration. We needed a decision.

I shifted from exploring possibilities to helping narrow them.

I recommended focusing on a smaller, coherent first experience that we could learn from and iterate on, rather than trying to solve the entire filtering space at once.

I translated that recommendation into a concrete design direction, giving product, design and engineering something specific to evaluate and align around.

Impact

The value I brought wasn't simply designing a set of filters.

I helped:

Connect related experiences

I recognised a reusable interaction problem and applied the underlying principles across different contexts.

Turn exploration into direction

I moved from generating alternatives to recommending a focused path forward.

Bring research into decision-making

I used research alongside design exploration and partner feedback to inform product decisions.

Create alignment

By making alternatives and trade-offs tangible, I helped cross-functional partners move towards a shared direction.

What I learnt

This project changed how I think about exploration.

Earlier in the work, I saw value in showing the breadth of what was possible. I still do. But I learnt that product design also means recognising when exploration has produced enough information to make a decision.

It also strengthened my systems thinking. Reuse isn't about making products look the same. It's about identifying the interaction principles worth preserving, then adapting them thoughtfully to the needs of a new context.

My biggest takeaway:

The designer's job isn't only to create possibilities. It's knowing when to narrow them into a direction the team can move forward with.