Use case diagram examples for a blog, a shop, and support

These use case diagram examples are a pack you can paste for three ordinary products: a blog, a shop, and a support tool. Mermaid has no use case diagram type, so each picture is a flowchart on purpose. Circles are the actors. Rectangles are the use cases.

If you came here for UML ovals inside a system boundary, this is the stand-in I actually keep in a repo, and I will not pretend it is the standard. It will not import into a UML tool as a use case model. It will not draw <<include>> or <<extend>> as real relationships. It will answer “who may start which action” in a file your docs already render. That is the question I get in review. The oval is optional. The actor and the action are not.

What the circles and rectangles are doing

A circle points at a rectangle. The arrow means the actor initiates that use case. It does not mean a data flow, and it does not mean the actor performs every internal step. “Reader leaves a comment” hides whatever moderation happens later. The later part is either another use case with another actor, or it stays off this picture. If I draw the moderation steps inside the reader’s rectangle, I have switched to a process flowchart and mislabeled it.

I leave out the system boundary box. Mermaid can draw a subgraph around the rectangles, and a subgraph is not a UML boundary with the semantics a textbook promised. I tried that version. Reviewers asked whether the box was a service. It was a caption. Captions that look like containers start design arguments I didn’t schedule. I put one sentence above the figure instead: “Actions this product actually offers.”

Include and extend are the other textbook pieces I refuse to fake. A dotted arrow labeled include looks enough like UML that someone will implement a shared “authenticate” use case as a service call in the wrong layer. If two use cases both need a logged-in actor, say that in prose, or split the actor into guest and member. Don’t invent a relationship the renderer doesn’t have. The flowchart syntax page shows circles and rectangles. It will not grow a use case dialect because we wished for one.

The generator how-to is a different page. That one is about producing a picture from a description. This one is the pack. If you needed a blog, a shop, and a support desk drawn the same way, paste these, rename the nouns, and delete the use case you don’t offer.

A blog, with the jobs kept apart

Three actors. A reader who doesn’t write. An author who doesn’t moderate other people’s posts. An editor who can pull a post down. I split them because a diagram with one actor called User cannot explain why a reader saw an Unpublish button. I have shipped that button. The diagram was “simplified.” The role was not.

flowchart LR
    Reader((Reader)) --> ReadPost[Read a post]
    Reader --> Comment[Leave a comment]
    Author((Author)) --> Draft[Draft a post]
    Author --> Publish[Publish a post]
    Editor((Editor)) --> Unpublish[Unpublish a post]
    Editor --> Moderate[Remove a comment]

Reader points at reading and commenting. Author points at draft and publish. Editor points at unpublish and comment removal. There is no arrow from Reader to Publish. That missing arrow is the access rule. When someone redraws this with User in the middle and arrows to everything, they have deleted the rule and kept the boxes. The boxes were never the point.

Draft and Publish stay separate. Collapse them into “write” only if a draft cannot exist without going live. Our blog lets a draft sit, so one rectangle would hide that. This picture still does not show states. It shows who may start the action. If the argument is “what are the states of a post,” you wanted a state diagram, and this pack will not stretch. I once added Drafting, In review, and Live as extra rectangles and called them use cases. They were states. A reader does not “do” In review. The arrows became nonsense, and we argued about the arrows for a week before anyone said the word state.

Comment removal belongs to the editor, not the author. You might hate that choice. Change the arrow’s source if authors clean up their own threads. Don’t add both arrows “to be safe.” Both arrows means both roles can do it, and someone will build both, then ask why the audit log has two doors.

A shop, including the person who is not the shopper

Shop diagrams rot when they only contain the shopper. Refunds and price changes are use cases. They have actors who do not hold the cart. Leave them off and the chart is a brochure for the storefront.

flowchart TB
    Shopper((Shopper)) --> Browse[Browse the catalog]
    Shopper --> AddCart[Add to cart]
    Shopper --> Checkout[Check out]
    Clerk((Clerk)) --> Refund[Refund an order]
    Admin((Admin)) --> EditPrice[Edit a price]

Browse, cart, and checkout belong to the shopper. I did not draw Pay as a fourth shopper use case. Checkout includes the charge, unless your shop lets someone check out without paying. That second product is a quote flow, and it deserves its own rectangle with its own name. I folded pay in because the last shop I drew treated Pay as a separate oval, and the team built a page that could create an order in a half-paid state nobody handled. The oval felt precise. The oval was also a spec. One rectangle called Checkout forced the argument: does checkout finish the charge? We decided it does. The rectangle stayed singular.

The clerk refunds. The shopper does not point at Refund. If a shopper may ask for money back, that is a different use case, and the verb should say Request, not Refund. I mixed those once. Support read the diagram as a promise of a self-serve button. The diagram had meant a clerk action. The rectangle just said Refund, which was sloppy. Name the initiator’s verb. The extra word is cheaper than the wrong button.

Admin edits a price. The label is not “manage the catalog.” Wide labels are how five more actions sneak in without a review. Edit a price was the fight, because it bypassed a second person. If you also need “add a product,” add a rectangle. Don’t widen this one until it means the whole admin site.

A template on this site is often a process flowchart, with decisions and retries. Don’t rename its boxes into actors and call it a use case. A process answers what happens. This shop picture answers who starts checkout. Both can live in the doc. They are not substitutes, and I have watched a team replace the actor map with a login flowchart because the login one “looked more finished.” It was finished for a different question. The flowchart examples and shapes page is where I’d send someone who actually wanted diamonds. Stay here if the diamonds would hide the actor.

A support tool, where the lead is not just a senior agent

Support tools collapse everyone into Agent, and then the reopen rule has nowhere to live. I want the customer, the agent, and a lead. The lead is the person allowed to undo a resolve. If your product lets any agent reopen, delete the lead and point Reopen at Agent. Don’t keep the lead “because hierarchy.”

flowchart LR
    Customer((Customer)) --> OpenTicket[Open a ticket]
    Customer --> Reply[Reply on a ticket]
    Agent((Agent)) --> Take[Take a ticket]
    Agent --> Resolve[Resolve a ticket]
    Lead((Lead)) --> Reopen[Reopen a ticket]

The customer opens and replies. The agent takes and resolves. The lead reopens. There is no arrow from Customer to Resolve, and there is no arrow from Agent to Reopen. Those absences are the policy. A ticket tool I used let the customer click Resolved because a diagram somewhere said “anyone involved can close.” Anyone involved is not an actor. It’s a shrug. Draw the shrug and you will implement the shrug.

Reply is one use case even though people reply many times. A use case is not a loop count. If you need the loop, you wanted a sequence diagram, and the sequence examples are the gallery for login, a single request, and a payment. Don’t add a second Reply rectangle called Reply again. You’ll start numbering them, and the picture becomes a transcript.

Take and Resolve stay split. Some desks auto-assign, and Take is a lie. Delete Take if the product doesn’t have it. I left a Take rectangle on a board for a team that assigned in a queue, and a new hire built a claim button nobody wanted. The rectangle was more persuasive than the standup where we said “ignore that box.” Delete the box.

Rename every noun before this leaves your branch

These three pictures are examples of shape, not of your product. If your blog calls the editor a “producer,” write Producer on the circle. If your shop calls checkout “place order,” write that on the rectangle. Leaving my words in is how a doc describes a product you don’t sell. I copied a shop diagram into a wholesale tool once and left “cart” on it. Wholesale didn’t have a cart. It had a purchase order. The word cart survived two quarters because the picture parsed and the preview looked calm.

Delete use cases you don’t offer before you add new ones. Addition is the fun part, and it’s how the chart becomes a sitemap. A sitemap of every screen is not a use case diagram, even in this flowchart costume. If the rectangle is a page name (“settings screen”), you’ve slipped. Settings is a place. “Change a notification preference” is a use case, and only if someone is arguing about who may do it. If nobody is arguing, you don’t need the rectangle. I would rather have four arrows that are true than fifteen that are a tour.

Guests and members are the split people avoid. A reader who can comment only when logged in is not the same actor as a reader who can only read. Two circles, Reader and Member, or Guest and Member. One circle with a note in the margin will be ignored. The margin is where we put rules we hope someone else enforces. Put the rule on the arrow by choosing the actor.

The how to make a diagram guide is the page about choosing flowchart versus sequence versus ER before you write. This pack assumes you already chose “who initiates what,” and you accepted a flowchart because Mermaid will not give you a use case keyword. If you haven’t chosen, go there first. A use case stand-in is the wrong picture for a failed charge. The failed charge is a decision or a message. It is not an actor.

A journey is the other picture people confuse with this

Actors and use cases don’t say whether the step felt bad. A user journey scores the steps for a person. I use one when the review is “checkout is miserable,” not “who is allowed to refund.” Mixing them produces a flowchart with numbers on the rectangles and no agreement about what the number means. Priority? Happiness? Step order? Pick the diagram whose wrongness you can point at.

I also don’t turn this pack into a sequence diagram by writing the messages on the arrows. “Leave a comment” does not need POST /comments on the edge. The route belongs on a sequence diagram if the route is the argument. Here the argument is permission to start. Stuffing the route into the rectangle label makes the label a sentence, and the circle layout falls apart. Short verbs. The route can live in the paragraph under the figure, where a reviewer can quote it without squinting at an arrow.

If you want the model to draft a fourth product, the flowchart generator will do it from a sentence that says flowchart, names the actors as circles, and names the use cases as rectangles. Say that Mermaid has no use case type, or you may get a class diagram with stick-figure energy and no arrows that mean initiation. Free AI is five uses total. Don’t spend one on “use case diagram of our app” with no actor list. You’ll get User, Admin, and a rectangle called Manage, and you will have documented nothing.

The arrow I keep deleting

The most common edit I make on these pictures is an arrow from every actor to a rectangle called Log in. Login is a step inside other use cases, or it is its own use case if the product’s argument is about sessions. As a rectangle that everyone points at, it becomes the center of the picture and the real actions slide to the edge. I delete it unless the review is specifically about who may start a session. The blog’s reader may be anonymous. Drawing Log in on that reader is a product change, not a decoration.

The second delete is a rectangle called View dashboard. Dashboards are homepages. They are not actions. “Export the monthly report” is an action, and it has an actor. If you can’t name the person who gets in trouble when the export is wrong, you don’t have a use case yet. You have a screen. Screens belong in a different doc, and this flowchart will not become a wireframe if you add more rectangles. I have tried to satisfy a designer that way. They were correctly unimpressed, and the file got worse.

Keep the three examples as a set only while you’re learning the costume. In a real doc, paste one, the one that matches the product, and throw the other two away. A doc that contains a blog, a shop, and a support desk is a tutorial. Yours isn’t. The costume is circles for actors and rectangles for use cases, in a flowchart, with the missing arrows doing as much work as the ones you drew.

Open the editor and paste the support picture if your desk is the one with a reopen argument. Change Lead to whatever your repo calls that role. If you don’t have the role, delete the circle before you invent the permission to match the example.