How to Create a Sequence Diagram: Step-by-Step Guide

To create a sequence diagram, list the participants that take part in one interaction, put them along the top in the order they are first used, then draw each message as a horizontal arrow from sender to receiver, top to bottom in time order. Everything else — activation bars, loops, alternatives — is detail you add once that spine is right.

Live interactive diagramUse the player controls to follow the steps

Kerberos authenticationPlaying silently in this guideWatch with narrationOpen in editor

When a sequence diagram is the right choice

Reach for one when order is the point. If the interesting thing about your subject is that A must happen before B, and that C only happens when B replies, a sequence diagram shows it better than anything else.

Three cases where it earns its keep:

• Authentication. A login is not one step, it is a negotiation. Who issues the token, who validates it, and what never crosses the network are all questions a sequence diagram answers directly.
• An API round trip. Request, validation, a database read, a serialized response. A flowchart would show the branches but lose the fact that the caller is blocked the whole time.
• Calls between services. When four services collaborate on one order, the diagram that helps is the one showing what each sends and what it waits for.

Do not reach for one when order does not matter. A list of features, a set of components, a data model — those are not sequences, and forcing them into lifelines makes them harder to read, not easier.

If you can shuffle the steps and the meaning survives, you do not want a sequence diagram.

The parts, and what each one promises

Sequence diagrams have a small vocabulary. Each element makes a specific promise to the reader, and the diagram is only honest if you keep it.

• Participant. A box along the top — a person, a service, a database, a queue. Diagramium offers eight kinds (participant, actor, database, boundary, control, entity, queue, collection), which change the icon, not the behaviour.
• Lifeline. The vertical line under each participant. It represents time passing, downward. Nothing else.
• Message. A horizontal arrow. The arrowhead and line style say what kind: a solid filled arrow is a synchronous call, an open arrow is asynchronous (fire and forget), and a dashed arrow is a reply.
• Activation bar. The narrow rectangle on a lifeline showing that the participant is busy with this call. Worth adding wherever "who is blocked?" is a real question.
• Fragment. A labelled box around several messages — a loop, an optional section, or a set of alternatives.
• Note. A callout attached to a participant, for the constraint the arrows cannot carry.

The single most useful discipline: a reply is a dashed arrow. If every arrow in your diagram is solid, a reader cannot tell a new call from a returning value, and the whole picture becomes ambiguous.

How to create a sequence diagram, step by step

1. Write down the one interaction you are drawing. One sentence, out loud: "a user signs in with an existing account." If you need "and" to describe it, you have two diagrams.
2. List the participants. Only the ones that send or receive something. A component that merely exists is not a participant.
3. Order them left to right by first use. The initiator on the left. This alone removes most of the crossing arrows people fight with later.
4. Add the happy path only. Every message, in order, with no branches and no errors. Read it back top to bottom — it should tell the story unaided.
5. Mark the replies. Convert every returning value to a dashed reply arrow. This is where a vague diagram becomes a precise one.
6. Add activation where blocking matters. If a reader would ask "is the caller waiting?", show it.
7. Wrap the variations. Now, and only now, add loops for repetition, alt for genuine alternatives, and opt for the step that sometimes happens.

The order matters. People who add branches at step four end up with a diagram that has three paths and no story.

Worked examples you can open and edit

Each of these is a real, editable diagram, not a screenshot. Open one, change a message, and watch the layout follow.

A login, in sequence

The Kerberos example above is worth reading closely even if you never implement Kerberos, because it makes a point every authentication diagram should make: the password never travels. The user proves knowledge of it to one service, receives a ticket, and presents the ticket to another. Drawn as a sequence, that becomes obvious — three exchanges, and the secret is absent from all of them. Drawn as a flowchart, it would be a series of boxes that never shows who holds what.

A REST round trip

For an API call, the shape that reads well is: client sends a request, service validates, service queries a store, store replies, service replies to the client. Five messages, two of them dashed. Add an activation bar to the service and the diagram now also answers "how long is the client blocked?" — which is usually the question behind the question.

Services collaborating

The drop-shipping example in the gallery is a microservice sequence with the honest complication built in: the store never holds the stock, so the supplier and the carrier are separate participants with their own timing. When you draw your own, resist the urge to add every service. Draw the ones that exchange messages in this interaction; the rest belong on an architecture diagram.

Building one in Diagramium

Open the sequence diagram editor and you can work two ways — on the canvas, or in text. Both edit the same diagram, so you can switch whenever one is faster.

1. Add participants from the left panel, or type them in the Text editor tab.
2. Drag from one lifeline to another to create a message, then type its label.
3. Pick the arrow style in the inspector — synchronous, asynchronous or reply.
4. Select a run of messages and wrap them in a loop, alt or opt fragment.
5. Press Present to play the exchange one message at a time — which is how you should explain a protocol to someone seeing it for the first time.

Writing a sequence diagram from text

The Text editor tab holds a text form of the same diagram, kept in sync with the canvas. For anyone who would rather type than drag, this is usually the fastest way to get a first draft down. The syntax:

title Sign in with an existing account

actor User
participant App
participant Auth
database Users

User->App: Enter email and password
App->>Auth: POST /session
activate Auth
Auth->Users: Look up account
Users-->Auth: Password hash
alt Hash matches
  Auth-->App: 200 + session token
else No match
  Auth-->App: 401 Unauthorized
end
deactivate Auth
App-->User: Signed in, or an error
note over Auth: The password itself is never stored

What each piece does:

• Participant kinds: participant, actor, database, boundary, control, entity, queue, collection. Quote a name that contains spaces.
• Arrows: -> synchronous, ->> asynchronous, --> and -->> reply. The label follows a colon.
• Fragments: loop, opt, alt, par, break, critical, seq, strict, neg, assert, ignore and consider, each closed with end. else divides an alt or par.
• Lifecycle: activate and deactivate; A->*B creates a participant mid-diagram and A->xB destroys one.
• Annotation: note over A: text (or left of / right of, and note over A,B: to span two), state A: text for a state invariant, ref over A: text to point at another diagram.
• Structure: title on its own line, == Phase name == for a divider, and // for a comment.
• Styling: append #4f46e5 for colour, or size:, font:, textcolor:, border: and borderstyle: tokens.

Text works for sequence diagrams, org charts, mind maps and sitemaps. The other editors are canvas-only — the Text editor tab is hidden there rather than offering syntax that does nothing.

Presenting, animating and exporting

A finished sequence diagram is usually something you have to explain to other people, so the output matters as much as the drawing.

• Present plays the diagram one message at a time, with optional step notes and narration. For a protocol walkthrough this beats talking over a static picture.
• Export as PNG, SVG, PDF or plain text at any time, with no account. Animated SVG, GIF and video exports need a free account — no subscription.
• Embed a published diagram in your own page as an interactive player, which keeps the step-by-step reveal in a document that would otherwise get a flat screenshot.

Common mistakes

• Every arrow solid. Without dashed replies, a reader cannot separate calls from returns. Fix this before anything else.
• Participants ordered by importance. Order them by first use instead; the arrows stop crossing almost immediately.
• One diagram, several scenarios. Sign-up, sign-in and password reset are three diagrams. Merging them produces a picture nobody can follow.
• Error handling everywhere. Draw the happy path, then add the one or two failures that change what someone would build. A diagram with nine alt blocks is a specification, not an explanation.
• Internal steps as messages to yourself. "Service → Service: validate input" is a note, not a message. Reserve arrows for things that cross a boundary.
• Labels that name a method instead of an intention. doAuth(u,p) tells a reader nothing that Check the password does not tell them better.

Related diagram types

• If the branching matters more than the ordering, you want a flowchart.
• If you are showing which components exist rather than what they say to each other, draw a system architecture diagram.
• If the question is where information is stored and what transforms it, use a data flow diagram.
• If one participant's own lifecycle is the subject, a state machine fits better.
• If the hand-offs between teams are the story, try a swimlane diagram.

Questions people actually ask

What is the difference between a sequence diagram and a flowchart?

A sequence diagram shows who says what to whom, in order. A flowchart shows what happens next depending on a condition. If your subject has several participants exchanging messages, use a sequence diagram; if it has one actor making decisions, use a flowchart.

Do I need to know UML to draw one?

No. The vocabulary above — participants, messages, replies, a loop and an alt — covers the great majority of real diagrams. UML defines much more, and you can ignore nearly all of it until something forces you to care.

How many participants is too many?

There is no rule, but past six or seven the arrows get long and the diagram stops being scannable. That is usually a sign the interaction should be split, or that some participants are not actually exchanging messages in this scenario.

Can I make a sequence diagram from text?

Yes — the Text editor tab takes the syntax shown above and stays in sync with the canvas, so you can type the first draft and then adjust it by dragging.

Should replies always be drawn?

Draw a reply when the caller does something with it, or when the wait is part of the story. A fire-and-forget message to a queue has no reply, and inventing one would misrepresent the system.