From application workflow to user journey

User experience

User experience is the holy grail today.
The prime goal for any new information system, for any substantial system modernization. User centric attitude is more than a trend: without users the system is nothing but a cost dead end. Even worse, losing users or driving users to get lost means losing their confidence in the system, thus in the enterprise or organization that built it.  And users means customers, partners, employees: the whole ecosystem personas. And if we loose them they will find another enterprise which deserves their trust: this is not what we want ;)

How comes we are at risk now, when everything was OK till now?
Many responses. We will concentrate here onto the workflow paradigm.

Workflow as the application’s core decision center

Till now the paradigm was:  let’s describe the business process, code its rules and sequence into a workflow, and build the application around this workflow.
Using a workflow engine or hard coding rules and sequence into application’s code doesn’t change the paradigm by itself. The whole thing results in a perfectly precisely defined sequence of operations, and all parts of the application are screwed to this sequence at some point. Usually, it ends up with something that looks like that:

From the business process design perspective it’s probably perfect.
The application fits any rule that was specified. At least until the rules change, but it’s not the point of this post.

From a 2022 user perspective it’s probably… perfectible!
Even if the initial design was done using personas and taking their hopes and needs into account, which is all but guaranteed, the first couple of trials to play the process will certainly produce some interesting usability feedback. Not even speaking of the bunch of next trials which will tend to propose another process to achieve the same goal with much emphasis on user’s needs.

User journey as an autonomous experience

Let’s face it: as a user I would like to get the most friendly UI possible.
And even more: I would like to be able to choose some paths rather than others one during my journey. And furthermore: I would like to send my feedback on what could be achieved more friendly from my stand point, and then have the satisfaction to see my wishes granted some days later in a new version of the UI journey.

There are probably several ways to get this high level of responsiveness from the information system. Let’s see what we can do with the “Product Architecture” approach (this approach will be described in further posts).

The idea of “Product Architecture” is to organize the whole system as it was made of coarse grain micro-services holding:

• business objects and associated business services, we call them Business Products,
• and Presentation Products dedicated to hold the user journeys.

We could roughly see this architectural pattern as a coarse grain MVC architecture where the (M)odel part holds business objects and services independently of  the user journeys that use them.

Workflow redefined

While we still have a coarse grain business process, the idea of a workflow which describes it entirely doesn’t apply anymore because we want the journeys to be designed by users. But what is the business limit when giving control to the users? The trick is: let’s concentrate on business objects statuses and tell what is acceptable and what isn’t.

• Ex: in a situation where a contract holds services legal descriptions, we can’t create a Contract object if at least one related Service object has been created cause a Contract may not be empty.

So we speak here of business rules. Or at least some kinds of business rules. We may code them directly into Business Products or prefer to put some of them in a shared component. For example the rules that drive the main business process steps. This is a kind of lazy workflow compared to the classical workflow described previously but it’s still a workflow.

On another hand, the same idea is true for Presentation Products and the journeys they hold. We can code transitions directly into the Presentation Products, or choose to share the main orchestration points into a kind of workflow, that here we call Orchestration:

A huge change

That’s it. We got a system where users have control on what they see, and business has control on what they get. The modern version of WYSIWIG!

Look again at the two schemas: “A change is gonna come” as would have said Sam Cooke ;)