EngFlow

Role
Product Designer
Collaborators
Engineering, Customer Experience (CX)
Product
EngFlow
01 · Proof-of-concept onboarding · KPI: Time to value

From a month to a week.

Making developer onboarding simpler.

I worked on improving the proof-of-concept (POC) onboarding experience at EngFlow, helping potential customers set up the product in their own environments and understand its value sooner, while reducing the manual coordination required from our team.

The context

Before adopting EngFlow, potential customers needed to complete a proof of concept in their own environments to understand how the product worked and how it could benefit their teams.

Getting started, however, involved several technical steps and coordination with the EngFlow team.

The problem

The existing onboarding process was manual and document-based.

Developers received a document containing instructions to install and configure EngFlow. They had to follow the steps individually, without an interactive way to track progress or understand what came next.

Some steps also depended on the Customer Experience (CX) team, meaning customers sometimes had to wait for confirmation or an email before continuing.

Because the POC wasn’t always their immediate priority, customers could lose momentum and postpone the setup. This created friction for customers and additional work for the internal team.

The opportunity

How might we help developers navigate a technically complex setup independently, while reducing the manual coordination required from the EngFlow CX team?

The opportunity was to move from static documentation to a guided, self-service experience that helped customers make progress with greater confidence.

My approach

I worked closely with the engineering team to understand the existing setup process and how it could translate into a clearer user experience.

The team provided documentation outlining the required steps and the interactions between customers and CX. I used this as a starting point to map the workflow and identify opportunities to simplify the journey.

My focus was on making the process easier to follow, helping users understand what to do next, and reducing unnecessary handoffs and dependencies.

The solution

I designed a guided onboarding interface that transformed the document-based process into a more structured experience.

Customers could follow a step-by-step journey, mark steps as completed, provide the information required at each stage, and understand what came next without relying entirely on email communication.

The experience also needed to help users troubleshoot when something went wrong, allowing them to move forward without immediately contacting the team.

The goal wasn’t simply to digitise the existing documentation, but to make the entire journey easier to navigate and help customers complete their setup more independently.

The onboarding journey

  1. 1Choose your trialPick how your project runs today
  2. 2Create your accountTwo minutes, any details work
  3. 3Explore your workspaceHome, clusters and setup
  4. 4Set up your clusterEight guided steps to live builds
app.engflow.com/trialLive prototype

Designing for technical complexity

The onboarding process involved technical requirements that couldn’t simply be removed. I collaborated with engineering to understand the underlying workflow and translate it into an experience that was easier for customers to follow.

The challenge was to balance technical accuracy with clarity and usability. Rather than expecting users to figure everything out independently, I focused on presenting the necessary information in a structured way and making progress through the process more visible.

One of the more interesting challenges was helping users troubleshoot without us being in the loop.

Some steps happened on the user’s own machine, which meant we couldn’t directly observe what had gone wrong. How could we help users understand the problem and find their way forward without relying on someone from our team?

This became an important consideration in designing a more independent onboarding experience.

02 · Iterative design with feedback in the loop

From an accordion to a guided stepper.

Making progress visible.

User testing showed that the accordion made it difficult to understand how the setup steps connected. Each section expanded in place, the page shifted as users navigated the instructions, and there was no clear sense of how far along they were.

I replaced the accordion with a connected stepper that made the sequence easier to follow and progress more visible. Each step had a clearer place in the overall journey, with the relevant command presented inline and a copy button to make it easier to use.

The setup flow
Before
app.engflow.com/setup
EngFlow setup before: an accordion under Setup, Use and Upgrade tabs where each step expands in place
Before. An accordion under the Setup, Use, and Upgrade tabs, with each step expanding in place.
After
app.engflow.com/setup
EngFlow setup after: a connected stepper with progress, inline commands and copy buttons
After. A connected stepper with visible progress, inline commands, and copy buttons.

The change wasn’t just about reorganising the interface. It was about helping users understand where they were, what they needed to do, and how each action brought them closer to completing the setup.

The impact

The redesigned experience addressed key sources of friction in the POC onboarding journey, making the process more structured and reducing reliance on manual instructions and internal coordination.

Previously, completing the process could take around a month, even in a best-case scenario, partly because customers needed to coordinate with our team and arrange time to complete the setup together.

The new guided experience was designed to help customers progress sooner, experience the value of EngFlow earlier, and reduce the support effort required from the POC and CX teams.

03 · Build performance

Making build speed something a developer can see and trust.

The problem

On a large codebase, changing one line can mean retesting everything. Bazel rebuilds only what changed, so the engine was already fast. The interface just gave developers no way to see that speed, or where they could go faster.

app.engflow.com/invocation
EngFlow invocation performance view, showing cache hits, network statistics and the critical path
The invocation page: where a build's time went, down to the critical path.

Show where the time went.

On the main platform I designed the landing, the invocation page and its performance graph: cache hits, execution location and the critical path, laid out so the biggest opportunities surface first. Comparison lines up any two builds and shows what changed.

  1. 1Browse invocationsEvery build and test run, filterable
  2. 2Select two to compareTick two invocations from the list
  3. 3Compare side by sideSpot what changed between them
  4. 4Analyze the breakdownCache, timing and the critical path
app.engflow.com/compareLive prototype
04 · Recommendations, before and after

Turn data into a decision.

From raw numbers to a next step.

The invocation page showed where the time went, but a developer still had to read all of it and work out what to change. I added recommendations that read the build's own signals and turn them into a plain-language next action.

The invocation page
Before
app.engflow.com/invocation
EngFlow invocation page before: cache hits and network statistics shown as raw numbers, with no guidance
Before. Raw numbers, and the diagnosis left to the developer.
After
app.engflow.com/invocation
EngFlow invocation page after: an Actions caching panel with a recommendation flagging low cache coverage
After. The same signals, read for you: cache coverage is low, and why.

What I took away

The speed was already there. Developers didn’t need a faster engine. They needed the signals the build already produced to tell them what to do next.

A final thought

Effective onboarding isn’t just about explaining a technical product. It’s about helping users make progress, overcome friction, and experience value as early as possible.

Go to next →