Launching a B2B platform for designers and researchers with a remote team in four months

Filo started out with a simple mission: to help design and research teams make research more accessible, effective, and actionable via a modern repository. We’ve based the product around what teams are struggling with: storing, sharing, and showing the impact of research.


As with any other start-up, a team of three is plenty to do it all! Besides myself, we had our brilliant Luke driving the product vision and John, hands down the best developer I’ve ever had the pleasure to work with.

See the team


The goal for Filo was to become the only tool teams needed for their research within two years from launch. We knew this was ambitious, but our experience in the field of design and research told us that there was a big need for this type of product — one that would allow teams to standardise and share their findings with stakeholders.


While usually at this stage I would embark on a mission to find out everything there is to know about the problem at hand, this time was a bit different. This was the first product ever I was scratching my own itch. Not only was I familiar with the pain points, but Luke, a seasoned researcher, could add to the list as well.

During these first weeks we organised our massive list of pain points and prioritised them. It was a challenge to commit to an MVP, since we could see a lot of opportunities. Business-wise, we started talking about potential avenues for growth, product strategy, and how to reach profitability.

Demonstrating a product/market fit

The biggest priority was to demonstrate that we had an idea worth spending time and money on — was this the right product, the right team, and the right time?

We talked to researchers and designers in our network about how they do research. Having access to friends and colleagues who could help was a luxury we made use of.

It didn’t take many conversations to understand that we were onto something. We were not the only ones struggling with this problem; the whole industry was. And as problems and pain points kept emerging, we realised that most of them were aligned with our pain points. These interviews acted as the green light we needed to move forward.

Biggest pain points

There were plenty challenges to solve. One of the patterns that stood out was how teams of all sizes were using tools created for others purposes as research repositories. All teams were looking for a “single source of truth” to help them store findings, show the potential impact of their research, and share their insights, and they were all experimenting with Jira, Trello, or AirTable. Some companies were even less advanced, using PowerPoint and PDFs to manage research.

We also uncovered that researchers struggled with showing the impact of their work, and that managers had no way of knowing whether their research teams were performing well or not in relation to the product and business goals.

Filo's pain points

Major pain points we discovered

Transitioning to ideation

Turning problems into challenges is something I do using How Might We questions — one of the tools that I find the most useful to transition from Discovery to Ideation. I’ve put together a list of HMWs that helped us frame our findings and prepared us to decide what the MVP should include.
Filo HMWs

The HMWs we based on MVP on

Main focus areas

We gave ourselves a deadline — to launch the product in less than five months, since we heard rumours about Uber building a similar product for their in-house team. While we didn’t think they will open source their tool, we didn’t want to take the risk. As such, there was not only a matter of what we wanted to do. It was more a matter of what there was time for. With that in mind, we chose four areas of focus for the MVP.

Making it easy to add and view problems in the repository

Giving customers a way to export their library of findings

Introducing impact metrics that users could attach to each problem

Building a dashboard that gives users an overview of their research efforts


Since we were looking at a process that was different for every team we spoke to, we knew we had to find a common denominator — the one thing that every team thinks of in the same way. We realised that however they do research and whichever tools they use, all teams start with problems. That’s why we’ve designed Filo around them.

We wanted to help teams show the depth of their work, so we added metadata they could enhance problems with: status, impact, themes, lenses, quotes, and media. These are tools researchers know well, but there was never a product where they could seamlessly integrate all of them.

Filo Information Architecture
The basic IA we came up with for the MVP


While creating wireframes I explored the best ways to meet the four goals we outlined above. Here’s where we iterated and came up with several ideas that ended up shaping the product:

  • allowing users to export insights into a PowerPoint template to save time
  • introducing ‘sales’ and ‘contact’ impact categories to give users metrics to attach to their problems
  • introduced the concept of ‘themes’ and ‘lenses’ to allow users to categorise problems based on their place in the user journey and complexity; this, together with the impact, helps teams prioritise work
  • built ways to attach videos and quotes recorded during customer interviews to each insight to make findings more impactful
  • brought it all together in a dashboard to show how much impact can be made by solving certain problems.
Filo wireframe
The description of the problem, placed right before the title and theme
A place for videos/photos and customers quotes, some of the best ways to frame problems in large organisations
Showing how this problem impacts the business. ‘Fragmentation’ is one of the three impact metrics that didn’t make it in the MVP.

The wireframe of the problem view

Filo wireframe
Exporting problems to PowerPoint is as easy as toggling themes on and off
Initially, the ‘Export’ menu option was at the bottom, as we wanted it to stand out. We dropped this in the final design.


The wireframe of the export screen

To test or not to test — and where’s the right balance?

At British Gas I was spoiled with an in-house usability testing lab and the chance to put products in front of customers as often as I chose to. In early-stage start-ups looking to get their wheels off the ground, like Filo, Design has to be adapted. While it would have been ideal to jump into a lab for a couple of days, we chose not to. Filo is a self-funded start-up and there’s a matter of compromising and choosing where to spend money wisely. Our early Discovery gave us the confidence that we have a product/market fit, so we saw no need for conceptual testing.

However, we did run a few usability testing sessions remotely with my network of designers. We discovered issues which we fixed before launching, but nothing major. At every step we remembered that Uber might work on something similar, and this uncertainty made us want to launch fast.


We knew that users might add hundreds of problems to Filo, so it could easily become overwhelming. This is why I chose a minimal design with a light colour scheme, generous white space, and clear call to actions. I’ve also tried to keep the interface slightly playful, following other B2B platforms such as Slack or InVision.

To build the app faster and to ensure consistency, I’ve created a pattern library, with the goal of using that as a building block to creating a Design System as the product evolves over time.

Problem view
Quick way to filter through the problems in different themes.
Displaying problems with the most important metadata — impact and lens.
Themes are collapsible to make large lists of problems less overwhelming

The page where users can see all the problems in a project

Problem view
Quick way to navigate back to all problems
Photos, videos, and any customer quotes sit on the right-hand side to not risk being pushed below the fold

The view of a specific problem with all its metadata and media

Adding a problem in Filo
Themes can be quickly added from here if they don’t exist yet
Impact can be added from here in a modal appearing on top

Adding a problem in Filo in one step

Filo dashboard
Seeing a breakdown of all problems helps teams understand where their efforts should be directed to
The impact section is the most useful, showing how problems of different complexities discovered through research can help the bottom line

The dashboard showing the impact of the research team

Post-launch and second iteration

We’ve launched the beta version using our own channels and network, alongside a section where users could give us feedback. While we didn’t become millionaires over night, launching has been useful to understand what people thought of our approach and what we could have done better.

Before designing the features we didn’t prioritise in the MVP, I wanted to take some time to work out what could be improved in the foundation of the product, since it became clear that we missed the mark on some aspects. I walked some of my network through the product and based on the other feedback we received we set out to improve four main areas:

  • improving the flow of adding problems
  • removing confusing metadata such as themes and lenses
  • simplifying the library view
  • rethinking the impact feature.
Old "add problem" screen New "add problem" screen

Old “add problem” screen (left) and the improved version (right)

Better flow for adding problems & removing confusing metadata

Adding problems (renamed to insights in the second iteration) sits at the core of our product. If it’s not the simplest flow possible, it’s not good enough, and it became clear to us it was confusing.

We’ve moved the optional metadata to a sidebar and left the mandatory fields unchanged. This made it more clear what was expected of the user and what additional metadata could be added, but also that it was optional. This way we’ve also kept everything above the fold, unlike in the MVP.

While talking to other researchers and designers it became clear that thinking about research through the perspective of ‘themes’ and ‘lenses’ was one way of doing it; but it was not the way. Instead of trying to force everyone to use our research methodology, hence limiting our product to the people who bought into it, we’ve decided to take a step back and allow teams to use our product in whichever way they see fit. This is why we’ve removed ‘themes’ and ‘lenses’ as metadata in the second iteration.

Old Filo repository New Filo repository

Old repository (left) and the improved repository (right)

Simplifying the library view

With ‘themes’ and ‘lenses’ gone, there was no way to sort insights in the library anymore. This is why we’ve added folders in a sidebar, which helped us slim down the problems look as well — now displaying only an image and the title. This makes for a much simpler and intuitive interface.

Old Filo dashboard New Filo dashboard

Old Dashboard (left) and the improved Dashboard, renamed to Impact (right)

Rethinking the impact feature

One of the features we were most vocal about in the MVP was the option to attach numbers to problems — how much would fixing this problem save us? What we ended up realising was that most teams don’t numbers. Most researchers don’t even consider that somewhere hidden in a spreadsheet there might be some data they could use. As much as this hurt, we had to kill our darlings and remove impact; or at least change its implementation.

Instead of allowing users to add numbers to problems, we allow them to add data based on the pirate metrics framework, which is widely used. This also changed the Dashboard from “These issues cost you £150,000” (which most teams wouldn’t know) to “These issues impact your retention” (which is enough to help teams start track impact).

Final words and lessons learned

There were more changes than just the ones mentioned above, but these four were the major ones worth mentioning. After launching the second iteration, we also introduced Journeys and Presentations, two features that we didn’t have time for in the MVP.

Lessons learned

One aspect I’ve learned is that testing prototypes with friends will likely skew your findings, since they are less likely to give criticism. Had we discovered some of the issues outlined above earlier, it might have saved us considerable time in design and development.

Working on Filo has also confirmed to me something that I’ve long believed — that it’s possible to build a company, a team, and a good product working entirely remotely, as long as the right processes are in place. Luke, John, and I have met in person just one week before launching. This strengthened my opinion that the dichotomy of ‘creativity only happens when people sit together in a room’ is false.