When we talk about digital products, services, initiatives we always try to bring agile methodologies and frameworks to the table to improve development teams like XP, Pair Programming, Scrum, SAFe, Spotify's Agile Scaling Model and many others, but we usually find it very hard to design the experience without iterating and identifying the value of it, for that we usually use Journey Mapping technique, which is an activity that we do on our projects with our customers. It is the result of applying Design Thinking and Service Design methodologies and it is how we map customer experiences or customer flows into an artefact aka Facilitation Maps that enables customers to iterate and discuss their own business.

With that in mind, we created Journey Designer in our product, with a mission in mind - reduce the gap between business and technology on a digital product to enable the following actions:

• Create solid user stories fully integrated; Describe stories, identify gaps and edge cases, create functional processes, materialize it with look and feel and find which integrations need to be used and which need to be created. Creating a single view for a customer journey that lives beyond frontends and backends. This solves problems such as:
  • Long documents with functional analysis but very hard to identify gaps;
  • Hard to connect the dots between the functional and the technical;
  • Documents that become obsolete very quickly as we evolve through the development;
• Foster a cooperative approach, instead of a competitive approach, by enabling people to work together;
• Reduce development errors and code complexity;
  • Helps have things in place so that when we need to change something or when we need help on something people can identify and work the same way. This way you pave the road so that every process is done pretty much the same way, we can improve and everyone improves, we can fix and everyone gets the same fix. As a global team we want to go further, we do not want to be reinventing the wheel over and over.

Journey Designer allows you to have any frontend or any IoT device communicate with our ecosystem, with the minimum know-how of how the full lifecycle works, a fully headless engine.

‍

Manage your business

This matter because defining a Customer Journey is a hard and complex process with many edge cases and until you step in on one of those routes everything seems fine, but then you enter the rabbit hole and it becomes very complex to leave.
We can improve our development by reducing development errors and code complexity by creating a journey.

We might end up with something like this (Facilitation Map or Journey Map within the product):

‍

‍

A massive facilitation map that lists all the functionalities that a user might have on a complex journey, iterations, approvals, external APIs calls, rules, services.

This automatically creates a State Flow map, which is basically a distilled map of the Journey Map but catered to developers. This map allows developers to add their APIs and configure when they can be called and by whom. These states are like Gate Keepers between customer/user interactions, screens, integrations.

An example of a generated State Flow:

‍

These maps show a complex onboarding flow with many edge cases, but we can provide a couple of examples on how to use State Flow:

• Ensure that a specific call can only be performed at a certain stage of the process;
• Provide control to the business to enable use cases like: “A price plan can only be done by someone with an operation profile”;
• Validate that all data is filled-in correctly before submitted to the external API;
• A much cleaner code without hording “if statements” across the code.

‍

How we see the evolution of Journey Designer

There is a long road ahead regarding Journey Designer and Journey Mapping tools, several tools exist on the market but do not work together:

• Journey Mapping - smaply - is a great example of a Journey Mapping tool where you can define the story and the interaction that a customer can have;
• BPM engines are great to define processes, apply business rules, KPI metrics;
• API Gateways are great to monetise APIs, analyse, monitor and restrict APIs.

We think of Journey Designer as way not to mimic Design Thinking and Agile methodology but to leverage from that. A way where you can create new stories, build empathy, reveal opportunities and break down silos.

A single place where you can design your story, regardless of the touch point, understand the impact of changing an API on the ecosystem and design rules in a single place, call APIs with context from the previous or any other, and create a full Microservices Architecture (µArchitecture).

A place where business specification will always be updated, and settings can be changed on the fly. This is what you can get today. As for tomorrow we want to continue to push this further and make sure that you can create your µAPIs cloud-ready and cloud-native without much code needed.

That you can leverage external APIs(OpenAPI, OpenBanking, TMForum) and connected them without complex coding so that you can connect the dots.
This is important in 2020 by the simple fact that we are connecting anything to everything. From our weight to our food, to the time that we spend commuting to the weather to our mood, to the people that we interact and to their lives.

‍

A glance on how to use it

Where does Journey Designer live within an Architecture:

‍

‍

Starting with a basic Spring-Boot Controller example for a µShoppingCart where we could simply have the logic to get/add/remove/validate cart:

‍

‍

And then we add the logic to Journey Designer State Flow map.

‍

‍

With State Flow we can prevent unexpected actions, and a much cleaner code, for instance, send an item on a shopping cart before billing the customer, or buying stocks without checking balance.

Looking at the 1^st example above we know that:

• We can call Create API as our first API, this will set me on Created State
• We can only call AddItem or DeleteItem, and if we try to call the Validate API we will get an error identifying that we are not on that step.
  ‍

‍

And on 2^nd example, for each API we can also tell who can call that API.

‍

And like on 3^rd example, you can validate before or after your calls, to check if things went south.

‍

‍

Or use the mapper to enrich and transform your dataset.

‍

APIs are calls with context from previous calls and this enables you to create a fully µArchitecture where the logic is detached from the Microservices and they can fully serve their purposes.

These are only a few examples that enable teams to deliver better and faster, but they do not come cheap. We need to learn new ways of doing things, but the gain on the long term will help.

‍

Article by João Castanho Maia