Chapter 7Case Study

7.1 Context

The final step in the development of the model was to apply the Flow Funnel as a tool within a "real" design process. I partnered with London-based startup The Engineering Company (TEC) to help develop their engineering development platform, aptly named Flow.

About Flow

Flow aims to be a complete platform solution for engineering workflows. In Flow, engineers can bring together requirements, data, physics equations, and any other piece of information to use in a project. These blocks can be placed anywhere on an infinite canvas and can be linked together to form relations and let data flow.

One of the core benefits of Flow is the possibility for exploration it provides. All the data on the canvas is live, and any change you make propagates throughout the entire system. This allows an engineer to try out different input values and see how the model responds, and test for various requirements.

About the project

Going into this project, the goal was twofold:

1. Apply the Flow Funnel model in practice: see in what parts of the design process it would come in useful, and in what ways.
2. Help bring flow (the concept) to Flow (the app): use the gained knowledge of flow, digital tools, and my model to benefit the development of Flow.

7.2 Process

The case study spanned five weeks in total. It closely followed the double diamond design process (Nessler, 2016; Black, 2008), with each phase lasting around one week.

Exploration

Starting out, I needed to understand what Flow was all about: the thoughts that went into making it on one side, and how users experienced using it on the other side. After getting access to a pre-release version of the application, I set up two interviews with members of the design- and engineering teams to find out what the philosophy behind the current design and functionality were.

In order to understand the typical process of a Flow user, a number of research sessions were set up with enthusiastic users of the alpha version of Flow. Similar to the sessions with photographers, these sessions consisted of an open-ended interview with ethnographic observation. I asked participants how Flow fit into their workflow, what features they liked and disliked, and they were asked to complete a short exercise in Flow to see how they would approach it and where they got stuck.

Ideation

The results of these sessions were highly informative. In fact, they were so informative that I immediately started trying to come up with solutions to problems I noticed.

While this resulted in a large number of ideas, it quickly became clear that many of these ideas did not align with neither Flow's strategic direction nor a user's typical process. I had fallen into the same pattern described in the literature review: focusing on features instead of building a mental model of user growth.

This is where the Flow Funnel came in. Based on the interviews, I identified four key phases in an engineer's typical journey from encountering a problem to modeling a solution. I then mapped out how many interface possibilities the app currently offered within each phase.

Ideally, the application should facilitate all these steps to make the entire user journey possible within the app, and each phase should be accessible to users of all skill levels. To visualise this, each phase was given its own Flow Funnel to display the depth the interface allowed for currently.

As it stood, Flow’s feature set touched upon all the outlined phases, but it didn't have the same breadth of possibility for each phase. There was one phase that already had a lot of depth and allowed the user to grow, but others were underdeveloped.

This user journey made clear which parts of the app needed to be developed further, and what new features would need to target to be successful. Another round of ideation commenced, this time aimed at cranking up a specific part of the user journey.

Prototyping

The ideas that followed from the second ideation process were discussed with members of the design- and engineering teams, and were finally combined into a Figma prototype. The prototype consisted of a mockup of the existing user interface, modified to include the new features. The interface could be interacted with by keyboard or mouse, as if it was a real application.

Testing

Finally, the prototype was tested in another round of interviews with alpha users. Participants were again asked about their workflow in Flow, and were then stepped through the prototype. Each feature was shown off with an explanation, and they were asked to give their opinion on the idea and whether they thought they would use it.

In general, users responded positively to most of the features presented and, more importantly, to the overall vision they pointed to.

I can't wait to have them. Those are really new ideas. That's exactly, I think, what Flow aims to do, is try and work in a different way and much more integrated approach. And those are exactly the innovative ideas I hadn't ever considered, which I'm so glad to see here.

These ideas [touch upon] kind of the whole purpose of what we're trying to do.

Synthesis

In the final week, the case study was concluded by a final presentation to all employees, detailing the process and its findings. Later, a wrap-up interview was conducted with my company supervisor (and Hyper Island alumnus) Davey van der Woert.

Feedback by the employees was very positive. Some features were more viable than others, but there was excitement for the new directions that hadn't been explored before.

Next to feature additions, the Flow Funnel model was deemed an especially useful part of the design process.

The funnel is giving me and the team a better understanding and a handle to talk about the difference in skill/experience levels of our users. We’re making a pro tool, so there inherently is a big difference between new and experienced users. For us to better understand how to move our users down that funnel is key.

7.3 Results

Both goals set out for this case study have proven successful.

The Flow Funnel turned out to be a great addition to the designer's toolkit. Firstly, it allowed me to steer my ideation towards ideas that would not only prove useful in themselves, but that would also form a cohesive set when chained with others.

Secondly, it allowed me to clearly communicate my reasoning to my stakeholders — and now allows others to do the same amongst each other. Creating a shared mental model like this put everyone on the same page. It could allow the entire company to develop common goals, and reasonings for those goals.

For the team it was a revelation to see this mapped. We’ve talked about this before, but we never really made it concrete in a document etc. Once we saw it, it was immediately clear and enlightening for the whole team.

While the features itself may not make it into the final product, it had inspired new features and validated the decisions they had made. Additionally, I had introduced the company to UX practices such as user interviews and ethnography. I'm very happy to have been able to contribute in such a way.