Digitization pitfalls #2: Understand UI: Translate user dialogue into architecture

Intro on business

The risc of this post is that it might become a bit technical. So lets first take the business view and demand here first. What I have encountered is that app/web development is driven through CX/UI design. Frontend designs imply to have a user reach its goal as simple and easy as possible. Customer Journey and User Interaction design goes first, like it should. The frontend (FE) design though reflects the online dialogue with the user. Dialogue. Talk to a customer from the UI.

Any UI interaction is a dialogue with the user. Given a complex dialogue it takes some steps to get the context. Invoking a button, respond with contextual data, show some selections, next step of choice, more data to present and so on. And at the end of the dialogue: submission. Service, sales; this is what the user wants to have a system to do or change. So app/web frontend serve the factual dialogue with the user. But what does that imply towards your architectural and pipeline setup? How to deal with southbound unformatted backend data serving the frontend?

Generic learnings

-         Splitting frontend (FE) from backend (BE) is understood by the business. They call it API thingies, but that is not all about it. You should take a more layered approach serving the dialogue (FE) from raw backend data (BE).

-         The frontend should be as dumb as possible. No calculations there. Deal with an omni channel approach like business wants. As an example: frontend can be different from language in app or web context. Native app based on React versus Web frontend based upon Angular as example.

-         The layer serving the full context of the dumb frontend is the calculating presentationlayer. The backend for frontend (BFF) we called it. It is just calculating what is needed to serve to the frontend.

-         Use services to gather data from factual backend. The BFF presentation layer can make use of single or multiple services gathering raw data from the factual backend

-         Prevent backend for frontend (BFF) monoliths. Monitliths are a risc for independent feature development so should be prevented. Split BFF wisely when needed, BFF should serve a purposed frontend-domain based set of function. Examples: Customer, products, settings, delivery, service, finance

-         Use purposed services gathering date to feed BFF, FE at the end whereas multiple services feed a FE-domained BFF

Talk to the business around (future) interaction design

Evaluating your setup, do keep track of what de (future) business (read design) needs are. If some page serves a set of processes, understand the purpose of the page and then decide to setup a specific purposed BFF for that using a set of microservices underneath gathering data from factual backend.

Understand user-interaction demand: Split BFF, based upon FE-domain based function

Look and understand to the (future) page and processes wanted. Look and translate. What is the main FE page purpose in the customer interaction? Is there a reason (now) to split the starting monolith to serve a certain FE-domain? Do developers want independencies in sense of pipelines? Then split up and refactor. Likely and hopefully driven by new UI needs. Goal or feature based refactoring (splitting) can be much better explained to business.

Obviously: split Frontend dialogue from raw data in your setup. Backend API are commonly not suitable to serve a factual FE. It needs a bit more in between. Lists, pagination, pagespeed. Backends by nature cannot serve those needs.

Summing up

Talk with the business. Also as a backend team or developer. Understand business demand from UI design perspective. Translate demand to your (future) setup.

Evaluate frontend features to FE-domain driven BFF. Split by FE domain. Whereas BFF consumes date from same or purpose-based microservices to gather data from raw-data backend.

Take away

FE and BE decoupling is what business understands. But do take into account that the factual dialogue with the user is driving your best setup. Use layers, FE, BFF and microservices to serve customer interaction needs.