Lessons Learned From My First Commercial Product: User Flow

A yellow line on a roadway.

It was 2013. We were watching videos of the Harlem Shake, Daft Punk's Random Access Memories just came out (and signalled when I was okay admitting EDM was my preferred style of music), and I was in a startup incubator in Fredericton, New Brunswick.

I was part of the founding team for a parking app that was going to be the best darn parking app ever, and we were all young and naรฏve. It's weird how a parking app can provide a perfect low-stakes microcosm for important lessons in product design.

Lesson 1: You can't interrupt expected flow

The old saying goes "you can lead a horse to water, but can't make it drink". That's horses, but if a human wants water everything you offer them must be in direct and expected aid of the goal they have in mind, or they will ignore it.

At HotSpot Parking we tried an experiment. A bunch of people parking in Fredericton (our trial city at the time) would get a popup offering them a half hour of free parking for clicking a button. The message was approximately "Thanks for being a HotSpot customer, your next 30 minutes are on us!" The options presented were "Great!" and "No, thanks."

Now from an economic perspective the thing people should do is obvious, click "Great!" and receive about $1 of value and be about your business. The problem? People didn't want an offer, they wanted to park. We ran this promotion over multiple days and which button people would press was as good as a coin flip.

I'm so happy we had the decline option to be able to witness this behavior. This lack of desire to interrupt flow was ultimately why HotSpot Parking had to drop the advertising-based cost recovery model, although the company attempted to make advertising work for about another year.

Since this experiment I've seen a lot of users of various products I built close dialogues without reading them. They'd usually do this while completing a task because their brain identified the popup as not part of the flow they expected. You've done it too, whenever you sign up for a new tool and want to get started, and their product team decided they wanted to have a "walk-through" wizard. You didn't read that shit, no one does.

The lesson here? Once a user is working toward a goal, you can't do anything that will disrupt the continued progression of that task. If your user starts a flow by clicking a "Park" button, everything after that point must be an expected flow for parking

Expected flow:

  1. Click Park (which for a parking app is launching the app)
  2. Select or enter lot
  3. Enter vehicle or space details
  4. Select time
  5. Provide payment
  6. Confirm completion.

You can combine or re-arrange elements a bit, but this is the generic, expected flow someone is going to want to go through once they start. Any friction outside this flow will cause unease and at best will be brushed aside. At worst, an experience like this will be seen as active malice toward the user (generating a "they don't care about their customers" review, or at least lowered sentiment).

Here's a believable, but terrible case from a user friction perspective:

  1. Click Park (Launch App)
  2. Get a 5-page welcome greeting on how the app works
  3. Be asked to sign up or log in
  4. Select a subscription plan for your service
  5. Select or enter lot
  6. Enter vehicle or space details
  7. Enter the time you want parking to expire
  8. Provide payment from your wallet, which is low or empty
  9. Select how much to fill/re-fill your wallet
  10. Receive a prompt to review the app on a five-star scale.
  11. Be asked if you have a coupon or voucher
  12. Provide payment, for real this time
  13. Get an ad or notice to receive a discount
  14. Receive confirmation.

If you had to do that to park next time you shopped at the Farmer's Market, you'd probably have a fair bit of ill-will toward the product. Especially for a first-time user, you want the flow to look more like the first list than the second. Give the user the best possible experience and then offer to let them sign up, subscribe, or receive discounts in the future.

For every element in the flow, we need to review it and challenge it with a "why?" Let's start with the registration experience: Why does a user need to be logged in to park? There are surely some benefits to the company for analytics, and you might be tricked into thinking this is easier, but it really isn't. Good e-commerce flow allows for the "guest checkout", and "Log in to view your saved vehicles" as an option on the "Enter vehicle" screen is much more streamlined for the activity being performed.

If you're a new user, why should you need to choose a subscription plan now? It's raining, you're cold standing beside a parking meter, and now isn't the time to figure out if you're a "monthly" or "annual" kinda gal. You can have a "Pay $X more to get a monthly subscription" option later to convert the user, right now they're parking, dammit.

Entering the time you want parking to expire is an interesting complication. In theory, it makes sense and could be more effective. I could easily make an argument that it's a better method of figuring out the parking time for the user. The problem is this isn't the expected flow, and it will confuse a decent number of users. Even if it's less efficient, use the flow the user is going to be the most familiar with.

If you're an app that relies on a digital wallet, especially for something that doesn't normally work on a stored value (gift card) system, you need to find a way to avoid it being part of the active flow. Most payment processors will allow you to place a hold on a card and then bundle together multiple transactions later, and if your chief concern is card fees you may be able to reduce some of that reliance using this method. If you must use a digital wallet flow, build the minimal charge amount into the payment confirmation, so it becomes a "Recharge and pay" option. But this is a distant second choice.

Don't ask people to review your product while they're using it. They're there to do something, not provide a vanity metric. As the experiment with free parking shows, people will do whatever they have to do to get the stupid popup out of the way. For this reason I don't view NPS as a viable rating system for users in almost any case I've seen. Understanding your user journey and drop-offs can be much more powerful when properly defined.

We have already discussed the ad / promotion modal, but did not cover good ways to approach this. If you have a promotion you want to share, or a new feature you're excited to share, you should have a home for those items. A place a user can choose to go and experience that content at their discretion. An "Offers" or "What's new?" menu can work really well. Fewer people will see your promo, but those who did will have a higher satisfaction as they chose to see it.


  1. Think about the tasks your users want to complete and what the best and expected flow for each is.
  2. Make a list of all the steps required to complete your top flows and ask "Why?" to each step.
  3. Are there friction points you can remove?
  4. How are you reverently protecting your user's flow and focus to get their task done?
  5. Share this lesson with the product person in your life ๐Ÿ˜‰