Thread by @GeePawHill

A flow app, one that steps the user through an acyclic graph, typically gathering info at each stage, can be built to provide iterative user value by gradual refinement. Let's look at how that's done.

Before we get into it, for me, and maybe for you, too, geekery right now is not the most important story. It's just comfort food.

If you're out there working for change today, I support you wholeheartedly.

Black lives matter.

Stay safe, stay strong, stay angry, stay kind.

The standard flow app is when we walk the user through a complex operation, and we gather the pieces step by step. Though it looks like a straight line to any given user, the answers in previous steps actually shape the following steps, hence the directed graph under the hood.

In most web environments, flows are page-to-page. In desktop apps, they're set up like wizards. It doesn't matter, the key is that we're stepping the user down a single path in the directed graph. They neither know nor care whether there are other nodes that don't concern them.

I start by identifying my "cop-out". What do I mean? Well, we don't have that functionality now, that's why we're changing code, right? What does the user do now if that flow doesn't exist for them? Whatever that is, that's the cop-out.

In some situations, the cop-out is real and already there and active. Consider configuring a peer-to-peer client to maximize performance. We want a flow, but the flow is an enhancement: the user already can change all the settings. The flow just walks her through it.

In other situations, the cop-out is "get a human". If you need a custom configuration for a product you're buying using the app, you have no choice but to chat/phone/email to get that.

Of course, sometimes the cop-out is "no can do". That is, the flow isn't replacing or enhancing functionality, it's adding something we've never had before. In some settings, the first step towards a flow is to build a cop-out that's better than nothing.

So you're sitting there, you've got your complex directed graph, and it's big, it's got a lot of nodes and paths. How can you iteratively add value without implementing the whole graph?

The first step is likely the longest, and you may have to break your day-and-a-half target to get there. It is to draw one line through your directed graph from beginning to end and implement it.

At each node of that starter line, implement just two transitions: 1) if the user answers the right way, exit to the next step on the starter line. 2) if not, exit to the cop-out.

Now, story by story, we can take each node and give it additional exit. We add the new node or nodes, and we go to the old node and add another variant choice from the user.

Over time, we'll cover the entire directed graph. But the rather cool thing? Each user we've already covered will never know we regard it as incomplete. Each user we newly cover will gain value. The overall value of the flow is gradually and iteratively supplied to the user base.

There are tricks. There's always tricks.

To pick the starting line, we much prefer a *short* line. First one's hardest, so if it's shortest, we might squeeze in under a day and a half.

In some situations, you can make your starting line shorter by focusing on the *last* part of it before you do the first part. The cop-out gets you through the early part, then the flow steps in and handles the last few steps. Not always possible, but look for it.

The sooner you can detect the "going to have to cop out on this one" situation, the better. Best is if you don't even let the user *start* your flow if you can already tell you'll have to cop out. Nobody likes discovering at step 9 that it's not gonna work.

You might want to rearrange your info-gathering so that answers that force cop-outs are sought *first*. It might seem weird to ask, idunno, "Do you have an FPO/APO address?" before you get my name, but if you can't send to those addresses, get the crying over with early.

Anyway, that's one path towards iterative user value for flow applications. I want you to notice some things here that are true of *all* of the approaches to interative user value.

First, notice that nothing we said here amounts to rocket science. As we've said before, the deep issue here isn't that this kind of thinking or working is hard to do, or even hard to see. It's that, most of the time, we're not bothering to look for it.

Second, notice that this requires us to change code for one story and then change it again for another story. Yep. It is an absolute violation of RAT (Rework Avoidance Theory). And it means we have to get *good* at changing code, with real technique involved. But it's worth it.

Third, notice *why* it's worth it. By developing our change skills and changing things more than once, we get actual user value, we get steerability and interruptability, and we get the boost of rhythm and reliability.

Delivering iterative user value is entirely possible, and tremendously beneficial. All it requires us to do is give up the faux-efficiency of the RAT. If we look for these kinds of paths, we can find them, but we have to look for them.

Flows stepping through a directed graph can be built & shipped incrementally, one path at a time. If you're clever, and you don't buy into the RAT, you can readily get stories down to the size where your team can chew through them.

And your users will feel the value.

Try it!

Thanks! If you like my content, gimme the two-way big love:

1. Subscribe. It's free, spam-free, comes in full-text or audio podcast.

2. Keep working for & supporting change, in the trade and outside of it. We can do this. We're the only thing that can.

geepawhill.org/subscribe