Onboarding strategy and design: Creating the ideal customer experience

One of the most challenging parts of a digital product strategy is getting started. For one, failure is always lurking around the corner and tolerance is low. The methodology we use is designed to withstand and tolerate failures. If anything, we want to enable teams to fail quickly, inexpensively, and learn along the way.

We built several templates that you can leverage when going through the creative process with your team:

• Persona template

• Lean canvas template

• Story map template

The above templates are meant to get you started—they’re by no means final for specific organizations and product types. All can be downloaded from www.devbridge.com/OnboardingKit.

Prior to diving into the mechanics for each step of our workflow, it’s important to cover the product design and delivery lifecycle as a whole to provide context. The process as shown in figure 6 is based on ideas that have been around for some time: build, measure, learn, repeat.

Figure 6: Product design and delivery lifecycle

Rapid prototyping

The first part of the process is rapid prototyping as illustrated in figure 7 below:

Figure 7: Rapid prototyping process

During this stage of the product lifecycle, we are establishing just-in-time requirements for an idea that hasn’t been tested yet. Due to the lean nature of these workshops, we’re able to validate or discard our onboarding strategy with minimal investment and short timeframe. The phase starts with the team setting goals, establishing user personas for the future product, and hosting a collaborative workshop where the stakeholders and the product team define product stories as shown in figure 8.

Figure 8: Storymap example

Customers are then interviewed, using the abstract scope captured in the story mapping workshop to further remove bias and introduce additional features not considered by workshop stakeholders. Following customer interviews, the product team reconvenes for a roadmap prioritization exercise. This is where a Minimum Viable Product 10 is defined, its features prioritized, and a roadmap established of how the product will be built with multiple MVPs. Ultimately, a Minimum Marketable Product (MMP) is released to market.

Aware of the MVP scope, the team proceeds to design a lightweight, visual prototype that has hotspots mapped using InVision. The idea is to quickly iterate over the feedback and produce a semi-working product that is presented to internal and external users/customers for testing. If the testing is successful, a higher complexity, interactive prototype is built, driven by real data. Alternatively, the team abandons the product with very little funds spent.

The interactive prototype is then put through another round of user testing. However, this time the team makes incremental improvements throughout testing, essentially accelerating the turnaround time between feedback and improvement dramatically. Based on the testing results from the interactive prototype, the product team and sponsors decide if the onboarding product should stay as is or pivot based on new information.

Productization

The second part of the process is the productization of the prototype, which uses a multi-stage, MVP-to-MMP strategy. Figure 9 is a visualization of the Dual-Track Scrum process that we use to iterate over the product roadmap.

It’s important to note that in the below figure we’re not abandoning our cross-functional delivery methodology after the completion of the prototype. Rather, the team starts working on productizing the MVP and implementing the needed functionality, while at the same time continuing to define requirements and design for future sprints.

Figure 9: Dual-Track Scrum

This just-in-time approach is useful because the product team can only consume the amount of requirements that are needed for the next delivery (a single sprint, or two weeks in our case). This frees up resources and lowers the cognitive load of having to analyze and store information that may not be necessary for objectives within the current sprint. We also are not abandoning the product validation. Even though feedback from the prototype may have qualified us to proceed with further investment into the product, we will still set up user testing sessions every couple of sprints to demonstrate and test new features with the customer.

The intent of delivery with Dual-Track Scrum is that the team is unburdened from unnecessary requirements. This approach also provides ultimate flexibility for the product. The scope can be drastically changed based on testing results along the way, building a better product for the customer.

While not in the figure, quality assurance (QA) is embedded within the team. Automated and manual testing scenarios are defined in parallel to the acceptance criteria of each user story, allowing the team to build a strong strategy and deliver a well-tested product by the end of the sprint. This transition to local QA dramatically lowers testing costs because defects can be resolved as they escape, versus at the end of delivery.

By listening to customers and using short iterations during the build phase, we are able to pivot and change the product to match customer needs and accelerate the business value generated — all while controlling our spend.

Now let’s discuss technical architecture to make this onboarding product a reality.