Screen Flows and User Journeys

Year Three starts by moving from isolated screens into connected software experiences. A single screen can look polished and still fail if the person using it cannot tell where to start, what happens next, or how to recover when something is missing.

A screen flow is the path through the experience. It might begin on a dashboard, move into a form, show a review step, and end with a confirmation. A user journey is the bigger story behind that path: what the person came to do, what they need to understand, and how the software helps them finish calmly.

This is where application thinking becomes more serious. You are no longer only asking, "Does this page look right?" You are also asking, "Can a real person move through this without guessing?"

An entry point is where the person starts. It could be a button on a dashboard, a link in an email, a card in a lesson archive, or a call to action on a public page. Good software makes that starting point obvious.

After the entry point, every screen should answer the next practical question: what should the person do now? The answer might be "fill out this form," "review these details," "choose one option," or "continue to the dashboard."

Weak flows often hide the next step. A form may submit successfully but leave the person on the same screen with no message. A dashboard card may open a page but not explain what the page is for. A lesson may end without showing where to continue. Your job as a builder is to make the next useful action visible.

A decision point is a place where the path can split. If a support ticket is urgent, it may need a different next step. If a service request is missing contact information, the flow should guide the person back to the missing input. If a student has not finished earlier work, the app may point them to the earlier lesson first.

A success state tells the person their action worked. It might be a confirmation message, a completed badge, a saved-progress note, or a clear "Submitted" state. Without a success state, people may repeat actions because they are not sure anything happened.

A dead end happens when the flow stops without a helpful next action. The person might see a blank screen, a vague error, or a page with no return path. Dead ends make software feel broken even when the underlying action technically worked.

A return path gives the person a safe way to keep moving. After a ticket is created, they might return to the ticket list. After a lesson is completed, they might return to the track. After a failed form check, they should return to the exact place that needs attention.

Return paths are not only "back" buttons. They can be links, secondary actions, retry buttons, summary panels, or messages that explain what to do next. What matters is that the person is not stranded.

Good recovery language is specific and calm. "Add an email address before submitting" is better than "Invalid input." "Return to your track" is better than making the student search for where they were. The more practical the message is, the less stressful the flow feels.

Imagine a service request tool. A visitor starts on a request page. They enter contact details, choose the service type, describe the problem, review the information, and submit. Staff can then see the request in a queue.

A weak map might only say: "User fills form, staff gets request." A stronger flow map is more specific:

Entry point: visitor clicks Request Service.
Input step: visitor enters contact and service details.
Decision point: required details are present or missing.
Recovery step: missing details are shown clearly.
Success state: request submitted message appears.
Return path: visitor can go back home or view what happens next.

This kind of map helps before you write code. It gives each screen a job and helps you notice missing steps early.

Multi-screen software should feel connected. The person using it should understand where they are, what just happened, what they can do next, and how to recover when something needs attention.

Before building a screen, name the entry point, the next step, any decision points, the success state, possible dead ends, and the return path. If one of those pieces is missing, the screen may still display, but the experience will feel unfinished.

In the next Year Three lesson, you will break interface work into smaller reusable parts. That becomes easier when the overall journey is already clear.