Think, Make, Check — Moving Quickly, Together.
Written by: Matt Goldman and Tobias Holm Jensen
At Kustomer, we foster shared ownership and collaboration with cross-functional product teams. These cross-functional teams are typically made up of one Product Designer, one Product Manager, one Engineering Manager and a collection of Engineers. The idea is to create teams that come together to work on specific product improvements within an area of the Kustomer platform. To make this successful, we strive to involve everyone in every phase of the project — from problem discovery through implementation.
We, Matt (Software Engineer) and Tobias (Product Designer), work together on the team called Platform Automations. This team is responsible for the product features that enable our customers to set up automated workflows in the application. Our team is always looking for ways to enhance our collaboration and deliver valuable software to our users. Recently, we began working using a process inspired by Lean UX which allows us to quickly test and validate our assumptions using functional prototypes. This process consists of three main phases: Think, Make, and Check. In this blog post, we will present the work we did and how Lean UX helps us remove process waste, and foster constant collaboration and rapid experimentation.
💡 Think
The first phase of Lean UX is about aligning the team on a problem, our assumptions about it, and our ideas for how to solve it.
Starting with a goal
One of the main objectives at Kustomer is to improve the product for tremendous scale and growth. A key ingredient in doing so is reducing the time our internal implementations team spends on custom implementations to get new customers set up in the Kustomer platform. To reduce this, we need to come up with innovative solutions that allow new customers to set up Kustomer on their own. One specific problem that we observed was that our implementation team spends a lot of time ingesting data from our customers’ old systems into their Kustomer instance. To achieve this, they would set up workflows that sync data through a webhook into the customer’s Kustomer instance. This seemed like a problem worth focusing on, so we decided to research it further.
Building empathy through research
To better understand the observed problem and to understand whether this was an impactful problem to solve, we decided to set up multiple interviews with Kustomer employees from the implementation team. To make sure we could collect diverse perspectives and foster alignment within the team, we involved all team members to sit in on these interviews and ask questions. After the interviews were done, we would debrief on key takeaways, surprising insights and observed pain points.
What we found was that about 75% of custom implementation work was made up of ingesting data into Kustomer. This validated our initial observation that the custom work performed by our implementation team mostly consists of ingesting data.
Map out the user journey
To create mutual understanding of the problem area, we decided to do a cross-functional workshop with the team. The goal was to map out the user journey with a clear understanding of the goals and jobs to be done. We started by outlining each step in the process, which people and activities were involved, and in particular the pain points along the way in this process.
Next, we brainstormed on the opportunities for improving the highlighted pain points. The goal here was to generate a wide range of divergent ideas in order to fully understand the various approaches to solving the problem.
Then, to understand which idea to focus on, we decided to prioritize each idea on a spectrum between effort and impact. The goal of this exercise was to identify the ideas and opportunities that balance the effort required from an operational and technical perspective as well as the actual business and user impact it will have. After prioritizing each idea and placing them in the impact and effort matrix, we started discussing which of these ideas would comparatively offer the biggest opportunity for solving the problem.
Establish a hypothesis
After having researched the problem, mapped out the user journey and aligned on the problem to solve, we decided to go with a solution that would offer Kustomer employees a tool that would allow them to set up an inbound webhook, map the fields coming in from this webhook and then automatically generate a workflow for them. Our hypothesis was that by providing a tool that would streamline the data mapping and workflow ingest process, we would shorten the implementation time by at least 10%.
🔨 Make
When the team has settled on a problem and the most impactful solution, the next phase is the Make phase. Here, the goal is to design collaboratively to make a minimum viable product that will help the team test their assumptions and hypotheses.
Sketch it out
Next up was translating the idea into an actual product. For this, we first sat down together and mapped out the desired user flow that would lead the user to accomplishing their goal. We often leverage user flows as a way to think process before user interface and to quickly start the conversation about the user experience we wish to create. We used this user flow to gather feedback from different stakeholders and to align on the proposed solution.
Then, we translated the steps of the user flow into actual wireframes of the product. By having the steps and tasks outlined it makes the wireframing process very quick. From this wireframing, we quickly decided on the solution to go with.
By doing the user flow and the wireframes, we were also able to articulate our assumptions about potential gaps in the solution. We decided to capture these and use them as validation points later in the process.
The solution we ended up with was a step-by-step experience that allows admins to set up a webhook connection to their backend, map the fields coming in via the webhook to the object in Kustomer and then automatically generate a workflow.
Prototype it
The basis for our prototyped solution was that all of the functionality to create a data ingest connection already existed in the Kustomer web application for years. However, users would have to jump between three different settings pages without any in-app direction to build a data ingest Workflow:
- Configurations for creating a new inbound webhook and managing your existing hooks.
- Another configuration page for defining the custom data model (Klasses) in Kustomer that the source system will be mapped to.
- The Workflow Builder: Workflows in Kustomer can be considered a visual programming language. The Builder is an advanced interface for building an automation triggered by POST requests to your inbound webhook to create or update objects in Kustomer, and perform other actions. A powerful and flexible engine that can be challenging for non technical personas.
Fortunately, Workflows built for ingesting data from another system followed a common structure. Our professional services team would consult internal documentation to guide them through creating a data ingestion Workflow, so we did have best practices documented, but setting it up was still a very manual process prone to user error. With this in mind, we were able to set our requirements for a useful prototype that we could build in a short timeframe:
- Consolidate the required configurations (Webhooks, Klasses, Workflow) into one wizard instead of being scattered across multiple pages.
- Building a lighter version of each of the aforementioned settings pages within the wizard was a breeze since each of these resources were already stored in our global Redux state. The Redux actions and selectors for creating, updating and fetching these resources in the global state can easily be connected to our new wizard component so that all of the necessary metadata is readily available.
- Our new wizard should generate a complex Workflow based on minimal user input.
- As mentioned before, while these data ingest Workflows are complex, they follow a similar structure. Our wizard should be able to abstract the common patterns. In other words, the user should not have to worry about adding logic to the Workflow to account for looking up customers by email/phone, when to create an object versus update, error handling for bad data, etc. We can have the user just specify which attributes they want to map from their source system to Kustomer and our application will plug those parameters in for you to generate a robust data ingestion Workflow.
- All form elements should use our existing reusable components.
- We should only need to focus on creating a new component to track the form state of our wizard and handle generating the Workflow at the end. All of the form inputs in our prototype should be reusable components that we are already using in other settings pages in our platform. Having these reusable components readily available to plug into our prototype allowed for seamless communication between design and engineering while optimizing for developer velocity.
🔎 Check
The third phase of Lean UX is to test the created artifact. In our case, we had now built a functioning prototype that would allow the user to configure actual functionality in the app. The goal here was to collectively understand the use of the prototype and potential shortcomings that we would need to improve on.
Testing
Building a new tool that simplifies a complicated and manual technical process for our admin users was exciting, but can also be overwhelming if we start thinking of all the possibilities of how we can extend the tool further. When considering the requirements, it was just as important for our team to set expectations and document what was out of scope for the prototype and could be addressed in future milestones.
Before we got too deep into planning the future milestones of this feature, we wanted to verify with our internal users that this minimum viable prototype saves them a significant amount of time when compared to the manual process. After our initial demo, the feedback was overwhelmingly positive and was the validation we needed to turn this prototype into a fully productized feature available to all our customers.
We even came up with new requirements while the prototype was still in progress, but also waited to validate with our internal Implementation Engineers’ feedback that we were heading in the right direction. We gathered feedback from this internal team by asking them to use our new wizard for real tasks they had to complete for clients instead of continuing with the old, manual and laborious process. It was in this phase that we tightened our feedback loop with this team by having a dedicated Slack channel and weekly video call to collect feedback and strategize around this feature.
Iterating
Depending on the feedback that we received, we quickly addressed it by creating a new ticket and/or adding the feedback as a line item in the product requirements document we were maintaining for this tool. Some of the new milestones included:
- Persisting the wizard configuration. In the prototype, we just want to prove that the wizard allows the user to easily create a complex Workflow. While being able to open up the wizard to modify an existing Workflow is a must for a GA release, we can demonstrate the value of our prototype without this requirement.
- Different types of generated Workflow templates (such as mapping to Customers instead of a Custom Object). If our prototype can generate a Workflow for one use case, we should be able to adapt to other Workflow structures in the future.
- Opening the wizard from a settings page. Since this was a prototype, we did not have to expose the wizard with a conventional settings page link or button. Instead, we can opt for using an obscure application route that we would only share with our internal users for testing.
There were also a handful of small bugs discovered by our internal team as they used it in more real world scenarios. It was very easy to quickly fix and safely release bug fixes thanks to the continuous deployment infrastructure that we have for our web application.
👀 Key takeaways
Following the three phases of Lean UX: Think, Make, Check we successfully launched an impactful feature in a short amount of time. Looking back at the process, there are few important things to highlight.
Solving problems as one team
By bringing together the whole team throughout the process, we manage to create a shared understanding and alignment on the problem. This makes moving forward much faster as the need for documentation and alignment meetings is practically gone. Furthermore, this creates a feeling of shared ownership across functions in the team. It gives a feeling of togetherness and this enhances the collaboration even further.
Rapid experimentation
In addition to creating alignment, Lean UX also allows us to rapidly create artifacts that can be used for experimentation. When the focus is not on the perfect solution, but rather on the minimum viable and valuable product, we can much earlier in the process start testing our assumptions and then iterate based on the feedback received. Furthermore, as engineers, the requirements for a project or initiative may not be fully defined or even validated before it lands on our plates. A proof of concept or prototype that can be demoed to a small select group of users can be a great first step in eliminating uncertainty around the requirements.
Design is a team effort
Lean UX also allows everyone on the team to participate in the design process. By bringing together everyone from problem discovery to implementation, everyone on the team has a say about how to solve the problem and what solutions could get us there. In addition, the focus is less on design deliverables and more on making artifacts that can be used to validate assumptions.
