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.
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.
Major pain points we discovered
Transitioning to ideation
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.
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.
The wireframe of the problem view
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.
The page where users can see all the problems in a project
The view of a specific problem with all its metadata and media
Adding a problem in Filo in one step
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 (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 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 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
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.