Transition Diagrams Revealed the “Structural UX Problem” and the True Nature of “Provisional Optimal Solutions” [Technovate Thinking ④ Day2 Part2]

This is part 4 of my 12-part series documenting what I learned in “Technovate Thinking,” a course I took at business school.

This time, I’m writing about Transition Diagrams, which we covered in the second half of Session 2. The assignment was to map out the screen transitions of a web service, visualize the structural problems in its current design, and then design a “desired future state.” What I expected to be a UI design exercise turned out to be a conversation about business strategy.

What Is a Transition Diagram?

A Transition Diagram is a tool for mapping the “state changes” a user goes through when interacting with a service. It’s also known as a screen transition diagram or state transition diagram.

When designing a website or app, visualizing “what state is the user currently in?” and “where can they go next?” brings design problems to the surface. In Technovate Thinking, it was positioned as a tool for envisioning the desired future state (To-Be).

In my IT infrastructure background, I’ve worked with state transition diagrams before — for example, when designing server states like startup, shutdown, anomaly detection, and recovery, or when defining status flows like “Normal → Warning → Failure → Recovery” on monitoring dashboards. But the idea of using them as a tool for analyzing user experience was refreshing.

The Moment I Mapped the As-Is, Structural Problems Became Obvious

For the assignment, I chose a “reservation-type web service” that most people have likely used at some point. I analyzed the PC version of the site because the information separation at the screen level was clearer, making the structure easier to visualize.

What surprised me when I actually mapped it as a Transition Diagram was the sheer number of screens. Just the basic flow to complete a reservation involved around 8 screens. Add login processing, payment method branching, and post-reservation modifications and cancellations, and you’re looking at a structure where users navigate through 10 or more screens.

Each individual screen is thoughtfully designed. But when you step back and view the whole thing through a Transition Diagram, the structure of a “fragmented, easily interrupted” experience becomes immediately apparent. This is a structural-level problem that you’d never catch by improving individual UI elements.

Color-Coding by Blocks Revealed “Mixed Concerns”

To organize the transition diagram, I color-coded the processes by functional block: reservation flow, payment flow, authentication flow, and post-reservation processing. The moment I applied the colors, the diagram’s clarity improved dramatically.

That’s because wherever colors overlapped meant different concerns were mixed together on a single screen — and it was obvious at a glance.

For example, the payment flow alone had multiple branches. The destination screen changed completely depending on the payment method. Moreover, this branching occurs near the end of the flow, meaning users who get confused here are highly likely to abandon the process. The most complex structure was sitting right at the step that should be the most carefully designed.

The authentication flow was also interesting. Users can log in either at the beginning or midway through the flow, but the subsequent flow changes subtly depending on when they log in. The timing of when user information gets auto-populated differs. What appears user-friendly on the surface was actually the biggest contributor to the diagram’s complexity.

By examining the structure at the block level rather than the screen level, deep-rooted problems that no amount of individual UI improvements could solve emerged. I felt this was the same approach as “isolating problems by layer” in infrastructure design.

The Power of Visualization — Some Things Only Become Visible When You Draw Them

The strongest takeaway from this assignment was that “even things you think you understand in your head reveal new insights when you put them in a diagram.”

When using a service as an everyday user, you might vaguely feel “there are a lot of screens,” but you don’t think about whether that’s a structural problem. However, the moment you map it as a Transition Diagram, specific problem areas jump out: “branching is concentrated here,” “this block is abnormally complex,” “there’s no back-navigation designed.” Pinpointed issues emerge instantly.

I’ve experienced this in infrastructure design too. Even when you think you have a network configuration figured out in your head, drawing a diagram reveals things like “this path has no redundancy” or “this could become a bottleneck.” Visualization is analysis itself. The act of drawing forces your thinking into order and leaves no room for ambiguity.

The same applies in business. Explaining a business process verbally versus mapping it as a flow diagram yields completely different depths of understanding. The value of learning Transition Diagrams in Technovate Thinking isn’t just about mastering the tool — it’s about acquiring the mindset of “discovering structural problems through visualization.”

Designing the To-Be — Compressing Steps and Creating a Continuous Experience

Based on the As-Is problems, I designed a To-Be (desired future state).

The core idea was simple: compress the numerous screen transitions into the minimum number of steps. Combine condition inputs and selections into a single-page multi-step form that advances without page transitions. Merge information entry and payment, then finish with a final confirmation.

For going back, instead of navigating to a previous screen, the design allows users to step backward within the same page. Previously entered information is preserved. The goal: transform “fragmented and easily interrupted” into “continuous and self-contained.”

Of course, this is an “ideal” — implementing it involves significant system-level constraints. Legacy core system integrations, session management, payment API specifications — it’s easy to imagine how these technical realities produced the current As-Is screen structure. Coming from an IT infrastructure background, I can simultaneously see “why it can’t be easily changed.” That’s precisely why, when designing the To-Be, I imposed a rule on myself: “Don’t use technical constraints as an excuse.”

The True Nature of “Provisional Optimal Solutions” — Today’s Optimum Isn’t Tomorrow’s

Comparing the As-Is and To-Be side by side, I realized that the current UI has perfectly valid reasons for being the way it is.

The high number of screens comes from a design philosophy of accommodating users who aren’t comfortable online — reducing the information per screen and guiding them through one careful confirmation at a time. “One screen, one action” is less confusing and reduces mis-clicks compared to “do everything on one screen.” From an operational cost perspective of reducing call center inquiries, this design is rational.

In other words, the current UI is a “provisional optimal solution” tailored to today’s primary customer base. It’s not “hard to use” — it’s “easy to use for a certain segment.”

But how long this “provisional” state holds is a different question. As the mobile-native generation — people who grew up on smartphones and consider a 2-3 tap experience “normal” — becomes the core customer base, opinions like “too many steps,” “can’t go back,” and “the design feels heavy” will become mainstream. Today’s optimal solution won’t be the optimal solution in five years.

This problem isn’t limited to any one industry. Online banking, insurance quote sites, government e-services — many service UIs harbor the same kind of “provisional optimal solution.” When generational shifts advance, services still clinging to their provisional solutions will suddenly be branded as “hard to use.”

The key isn’t to criticize provisional optimal solutions, but to assess their lifecycle. Understand why the current design is rational, then plan “when, at what timing, and where to start making changes.” I felt that Transition Diagrams can also serve as a tool for estimating that risk in advance.

Where Transition Diagrams Meet Infrastructure Thinking

What I found fascinating about this assignment was how surprisingly close the Transition Diagram approach is to thinking in infrastructure.

Take monitoring dashboard design, for example. When designing the flow where a server’s state transitions from “Normal → Caution → Warning → Failure → Recovery,” you’re literally drawing a state transition diagram. “Which states can transition to which?” “Are there any one-way transitions with no return?” “Is there a fallback for unexpected state transitions?” — these are all the same questions I was asking in this service flow analysis.

Or consider network architecture diagrams. Designing which routes packets take, which devices they pass through, and where they ultimately arrive — this work is structurally identical to a Transition Diagram.

The difference lies in “whose perspective you’re viewing the transitions from.” In infrastructure design, you view transitions from the system’s perspective. In this assignment, you view transitions from the user’s perspective. Same tool, but changing the angle yields completely different insights.

Furthermore, in infrastructure design we exhaustively map out “error-case transitions.” The normal path alone makes for a simple diagram, but add timeouts, retries, fallbacks, and rollbacks, and complexity explodes. The same thing happened in this UI analysis. The basic reservation flow is simple, but add login timing variations, payment method branching, and error recovery — the moment you include “exceptional transitions,” structural complexity skyrockets. Recognizing this parallel was a significant discovery for someone with my IT infrastructure background.

Lesson: Screen Transition Design Isn’t a UI Problem — It’s a Business Strategy Problem

In the Technovate Thinking class, Transition Diagrams were introduced as “a tool for envisioning the desired future state.”

Having done the exercise, I fully understand why. Simply mapping the current state (As-Is) visualizes structural problems, and from there you can reverse-engineer the To-Be design. You gain a perspective that looks not at “what’s the problem right now?” but “where in the overall state transitions does the distortion lie?”

And by comparing different types of services, I gained another major insight: screen transition design isn’t a UI problem — it’s a business strategy problem. “What kind of users, what kind of experience, and where to generate revenue” — these management decisions are directly reflected in the structure of a transition diagram. UX design isn’t about improving appearances; it’s the business decision-making itself.

For example, some services strip screens down to the bare minimum to maximize impulse purchases, while others guide users through careful screen-by-screen confirmations to prioritize a sense of security. It’s not about which is “right” — it’s about which fits that service’s business model. Look at a transition diagram’s structure and you can see what that service truly values.

While I’ve used screen transition diagrams in enterprise system design before, drawing them specifically to “uncover structural problems in user experience” was a new experience. Learning to use Transition Diagrams not just as a technical design tool but as a business decision-making tool was the biggest takeaway from this session.

Next Up: Bubble Sort and the Essence of Algorithms

In Session 3, we dive into algorithms. I’ll write about the experience of building a simple sorting algorithm with my own hands and what it taught me about what makes a “good” algorithm.

Books Referenced in This Post