Business logic: the design behind the design

Although a highly visual discipline, interaction design is not really about how things look: it’s more about how they behave. 

Because a customer journey goes on over time and over multiple pages, interactions on a page don’t just affect that page, but many.

It’s important to keep track of all the possible instances of a page, its options, and onward journeys.

That’s why I create map of the business logic I am designing to, or with. Sometimes these maps point to improvements that can be made to the logic itself: a very good, if not the best place to start on any simplification project. 

These documents are easy to share with dev and business teams for discussion and iteration.

I find that different people tend to respond differently to different types of visualisation. Business analysts and developers like a flow chart.

But flow charts can be difficult to read at-a-glance, and tricky to summarise (I think because they are too dense, and contain too much branching logic).

When discussing subtle and potentially confusing logic flows with non-technical folk, I visualise the logic with wireframed screen states. This gives context, and makes the logic much easier to follow and discuss.

As an example, the logic expressed in the flow diagram above came out like this:

Viewed like this, thinking can be shared with the whole team, from marketing to devs and designers, and group decisions made quickly and effectively.

The documentation informs story writing, visual design, copy and development direction.

Holding ‘3 amigo’ sessions at this stage, before detailed analysis and implementation has begun, gets great early feedback on what’s feasible (and what isn’t) and how objectives might be achieved in better ways.

Those changes can then be explored, prototyped and tested before going into production.