The Tech Behind a User-Friendly Wizard (User Flow)

As a software developer with 23 years of experience, I’ve seen my fair share of user interfaces. One pattern that consistently comes up in web applications is the wizard - a step-by-step interface guiding users through a complex process. Whether you call it a wizard, a click funnel, or a user journey, the challenges of building these interfaces remain the same. Today, I’m going to share some key principles I’ve learned for creating user-friendly wizards that are also developer-friendly.

Why Build a Better Wizard?

Before we dive into the how, let’s talk about why this matters. A well-designed wizard can:

• Improve user experience by breaking complex tasks into manageable steps
• Increase conversion rates in sales funnels
• Reduce errors in data entry processes
• Guide users through unfamiliar or infrequently used features

But poorly implemented wizards can be a nightmare for both users and developers. They can trap users, make testing difficult, and create maintenance headaches. That’s why it’s crucial to get the foundation right.

The 5 Key Principles

Let’s break down the five principles I’ve found most effective when building wizards:

1. Assemble Records into One

Problem: Scattered data makes it hard to manage the overall state of the wizard.

Solution:

• Attach all related records to one main workflow record
• Use database normalization techniques

Here’s a quick example of how this might look in a Ruby on Rails application:

class Flight < ApplicationRecord
  # No data attributes
  has_one :address
end

class Address < ApplicationRecord
  belongs_to :flight
  attributes :street_name, :city, :country # etc.
end

This structure allows you to easily access all parts of the wizard through a single entry point (the Flight record in this case), making state management much simpler.

2. Save Records Outside the Main Page

Problem: Users need to be able to leave the wizard and come back later without losing progress.

Solution:

• Implement a way to save partial data for each step
• Use AJAX requests to save data without full page reloads

Here’s an example of how you might implement this in a Rails controller:

class AddressesController < ApplicationController
  include SimplySavable

  def update
    @address = Address.find(params[:id])
    @address.assign_attributes(address_params)
    simply_save_and_render(@address)
  end
end

And in your view:

<%= turbo_stream.replace 'address_form' do %>
  <%= render 'direct/addresses/form', address: @address %>
<% end %>

This approach allows users to save their progress at any point, even if they haven’t completed the entire wizard.

3. Advance Steps Without Calculation

Problem: Complex logic for step advancement can lead to bugs and make the wizard hard to maintain.

Solution:

• Use simple validations to determine if a step is complete
• Avoid complex calculations for step progression

By keeping the logic for advancing steps simple, you reduce the chances of introducing bugs and make the wizard easier to understand and maintain.

4. Calculate the Last Possible Step

Problem: Users should be able to jump back into the wizard where they left off.

Solution:

• Implement a method to determine the furthest step a user can access
• Forward the user to this step when they return to the wizard

Here’s an example of how you might calculate the maximum possible step:

def maximum_possible_step
  constraints = [5]  # Assume 5 is the total number of steps

  constraints << 1 if product.nil?
  constraints << 2 if customer_data.nil?
  constraints << 3 if contract_data.nil?
  constraints << 4 if address.nil?
  constraints << 5 if seat.nil?

  constraints.min
end

This method checks which steps have been completed and returns the furthest step the user can access. When a user returns to the wizard, you can use this to start them at the appropriate step.

5. Use Policies for Authorization

Problem: Ensuring users can only access and modify their own data in the wizard.

Solution:

• Implement robust authorization policies
• Use these policies consistently throughout the wizard

By using a solid authorization framework (like Pundit in Rails), you can ensure that users can only interact with their own data, preventing unauthorized access or modifications.

Putting It All Together

When you apply these principles, you end up with a wizard that:

• Allows users to leave and return at any time
• Can be worked on by multiple developers simultaneously
• Is easier to test independently
• Has reusable components

While I’ve used Ruby on Rails in these examples, the principles apply to any web framework. The key is to have:

• A way to save partial data for each step
• A strong authorization framework
• Good validations

If you’re struggling with a complex wizard implementation, it’s a sign that there might be a better way to structure your code and data.

I’ve found these principles incredibly useful in my career, but I’m always learning. What kind of problems have you encountered when building wizards or user journeys? Have you found other solutions that work well? I’d love to hear about your experiences in the comments below.

And if you’re interested in diving deeper into web application architecture, check out my full video.