Visual models & analysis aids

A simple sequence diagram of activities and decisions, drawn with rectangles, diamonds, and arrows.

The original general-purpose process notation, standardised in ISO 5807. Activities are rectangles, decisions are diamonds, terminators are ovals, and flow is arrows. Flowcharts are atomic — one swimlane, one perspective — which makes them ideal for the first pass at understanding a procedure before deciding whether more rigour (BPMN, swimlanes) is warranted.

BA example: A new BA at an insurer maps the claim-intake call script as a flowchart on a single A4 to onboard themselves before joining the redesign workshop.

A flowchart split into horizontal or vertical lanes, one per actor, exposing every hand-off.

Sometimes called a cross-functional flowchart or Rummler-Brache diagram. Each lane belongs to a role, team, or system; activities sit in the lane responsible for performing them. The visual payoff is that hand-offs — the most common source of delay and error — appear as arrows crossing lane boundaries, and queues form at lane edges.

BA example: A BA mapping mortgage approval finds 11 hand-offs between Sales, Underwriting, Legal, and Operations in a process the business believed had three.

An ISO-19510 process notation maintained by OMG, with formal semantics for events, gateways, and pools.

Business Process Model and Notation. The descriptive subset — pools, lanes, tasks, sequence flow, exclusive/parallel gateways, start/end events — covers ≈80% of business analysis needs and is portable across modelling tools. Unlike a flowchart, BPMN has formal execution semantics: a process drawn in BPMN can in principle be simulated or executed.

BA example: A BA models the claims-payment process in BPMN, using a separate pool for the bank with a message flow for payment instructions, so Operations and the bank's integration team can agree the contract.

A one-page table that scopes a process by listing its Suppliers, Inputs, Process steps, Outputs, and Customers.

A Six Sigma framing tool. Five columns, ≈5–7 rows of high-level process steps in the middle, and the suppliers/inputs that feed them on the left, the outputs/customers they produce on the right. SIPOC exists to settle scope arguments before detailed modelling begins — it is intentionally too coarse to design with.

BA example: Before redesigning expense reimbursement, the BA runs a 30-minute SIPOC workshop and discovers Finance considered the process to start at submission while Operations considered it to start at receipt capture — a one-week scoping disagreement averted.

A Lean diagram of an end-to-end process annotated with cycle times, wait times, and value-add ratio.

Borrowed from Toyota Production System and codified by Rother & Shook. A horizontal sequence of process boxes, each with a data box (cycle time, change-over time, %-complete-and-accurate), connected by a sawtooth timeline showing process time vs. wait time. Two numbers usually emerge: total lead time and percentage value-add. The gap between them is where improvement lives.

BA example: A BA maps the loan-approval value stream and finds that of 13 days lead time, only 2 hours are value-add — every other minute is a queue between teams. The redesign focuses on collapsing the queues, not the work.

Paired diagrams of the current state and the future state of a process, with a delta annotation between them.

Not a notation in itself — a discipline for using the same notation (usually swimlanes or BPMN) twice: once for what happens today (as-is) and once for what should happen tomorrow (to-be). The difference between the two diagrams becomes the work backlog: removed steps, new steps, reassigned hand-offs, eliminated systems.

BA example: A BA uses paired swimlanes to show that the to-be procurement process eliminates two approval lanes, replaces three forms with one, and reassigns vendor onboarding from Finance to Procurement. The delta becomes the implementation roadmap.

A UML diagram showing actors (stick figures) and the use cases (ovals) they perform with the system.

Defined in UML 2.5. The diagram itself is intentionally sparse — actor, system boundary, oval per use case, lines for associations, plus «include» and «extend» relationships for shared behaviour. The richness is in the textual use case behind each oval (preconditions, main success scenario, alternate flows, postconditions). The diagram is the index; the text is the content.

BA example: A BA on a benefits-administration project produces a use case diagram with 14 use cases across 4 actors; the sponsor signs off on the scope picture in 30 minutes, and elicitation proceeds one use case at a time.

A two-dimensional layout of user activities (top), tasks (middle), and stories (bottom) sliced into release bands.

Coined by Jeff Patton. The horizontal axis is the user's narrative flow (the "backbone"); the vertical axis is depth of detail. Releases are drawn as horizontal bands across the map so each release contains a thin slice of every backbone step rather than a complete one. The result is a backlog you can see end-to-end at the same time.

BA example: A BA story-maps a citizen-permit application with 6 backbone steps; release 1 takes the thinnest viable story from each step, so a citizen can submit and track end-to-end on day one rather than receiving a deep but stalled "submission" feature.

A low-fidelity sketch of a screen showing layout, content blocks, and interaction without visual design.

Greyscale, no real images, placeholder copy, no brand. The point is to direct attention to structure (what is on the screen, where, in what hierarchy) rather than aesthetics. Wireframes are deliberately ugly so reviewers comment on the right things.

BA example: A BA wireframes the new claim-status page; the sponsor immediately notices that the document upload was missing — caught in 10 minutes, not 10 weeks.

An interactive mock-up — clickable, navigable, sometimes data-driven — that lets users behave with the proposed solution.

Anywhere on the spectrum from a clickable Figma flow to a working slice of code with a fake back-end. The defining property is interaction: a user can attempt a task and either succeed or get stuck, producing evidence about the design. Prototypes range from throwaway (paper, click-through) to evolutionary (becomes the eventual solution).

BA example: A BA hands a clickable prototype of the new appointment-booking flow to five patients in a 45-minute test; three get stuck on the confirmation screen, leading to a redesign before a single line of production code is written.

A level-0 data flow diagram showing the system as a single circle and every external entity it exchanges data with.

One bubble for the system in the middle, one box for each external entity (people, organisations, other systems) around it, and arrows labelled with the data exchanged. Nothing inside the system is shown. It is the cheapest possible artefact for nailing down system boundary and external interfaces.

BA example: A BA produces a one-page context diagram for a new claims platform; it surfaces an unexpected interface to the regulator that no one had budgeted for, two months before kick-off.

Any of several visual frames (in/out lists, scope tree, feature/exclusion table) that explicitly enumerate what the project will and will not deliver.

BABOK groups several techniques under "Scope Modeling". The simplest — a two-column in/out list — is often enough; richer variants include a hierarchical scope tree (capabilities → features → stories) and an inclusion/exclusion matrix. The deliverable is always two things: what is in, and (more importantly) what is explicitly out.

BA example: A BA captures "customer self-service portal" with an explicit out: "agent-facing back-office UI — phase 2". Three months later, when an executive asks for the agent UI, the scope model resolves the conversation in two minutes.

A branching diagram in which each node is a question and each branch is an answer leading to a decision or further question.

Reads top-to-bottom: root question, branches per possible answer, intermediate nodes for follow-up questions, and leaves for decisions or actions. Useful when the order of questions matters (you can stop early) and when the tree shape itself communicates priority. Compact for ≤ ~20 leaves; collapses under its own weight beyond that — switch to a decision table.

BA example: A BA documents the call-routing tree for a help-desk: customer type → product → severity → routing decision. The visual exposes that two branches both end at "escalate to L2", which becomes a candidate for consolidation.

A grid where each row (or column) is one rule: a combination of input conditions and the action it produces.

Conditions across the top, actions down one side, and one row per complete combination of condition values. Decision tables are the canonical form for capturing rules — every combination is enumerated, contradictions are visible at a glance, and missing rules show up as gaps. Formalised in DMN as a first-class artefact.

BA example: A BA replaces 14 paragraphs of mortgage-eligibility prose with a 9-row decision table. Two contradictory rules surface immediately and are resolved with the policy team before development begins.

A planning visual mapping inputs → activities → outputs → outcomes → impact, used to reason about cause and effect.

Originating in evaluation research (United Way, Kellogg Foundation), the logic model lays out a programme's theory of change as a horizontal chain. Each arrow is a hypothesis: if we put these inputs in, and run these activities, we expect these outputs, which should produce these outcomes, contributing to this impact. It surfaces unstated assumptions ruthlessly.

BA example: A BA on a digital-inclusion programme draws a logic model that exposes a missing link between "laptops distributed" (output) and "jobseekers find work" (impact); the gap becomes a training workstream the programme had forgotten.

A two-dimensional grid mapping a domain entity (rows) against a condition or actor (columns), with the cell carrying the rule.

Less formal than a DMN decision table; useful when the rule set is best read by domain (one row per product, transaction type, or customer segment) rather than by combination. Common variants include the entitlement matrix (role × capability) and the pricing matrix (segment × tier × discount).

BA example: A BA produces a 7×9 entitlements matrix (roles × actions) for the new case-management system; two roles turn out to have identical rights and are merged before development.

A visual register of stakeholders showing their relationships to the change, often clustered by group or proximity.

An umbrella term for any visual that organises stakeholders. Common forms include the onion (sponsor at the centre, expanding outward), the ecosystem map (organisations and their relationships), and the persona-grouped chart. The form follows the question being asked.

BA example: A BA on a regulatory reporting programme produces an onion map and surfaces three external stakeholder groups (auditor, regulator, industry body) that the programme charter had treated as a single line.

A grid mapping activities (rows) to roles (columns), with each cell marked R, A, C, or I.

Responsible (does the work), Accountable (single point of approval — exactly one per row), Consulted (two-way input), Informed (one-way notification). RACI exists to expose two failure modes: activities with no A (no one approves) and activities with multiple As (no one approves, in practice).

BA example: A BA's RACI for incident response shows three As on "declare major incident" — Operations, Engineering, and Security all believed they owned it, explaining a series of slow declarations. One A is assigned and the response time drops by 40%.

A 2×2 plotting each stakeholder by their power to affect the change (y) and their interest in it (x).

Mendelow's matrix. The four quadrants imply different engagement strategies: high power / high interest (manage closely), high power / low interest (keep satisfied), low power / high interest (keep informed), low power / low interest (monitor). The grid is most useful when stakeholders disagree about who matters.

BA example: A BA's grid puts the head of Compliance in the high-power / low-interest quadrant; the engagement plan changes from monthly demos (which she ignored) to quarterly executive briefings (which she attended).

A 2×2 matrix capturing internal Strengths and Weaknesses against external Opportunities and Threats.

A strategic framing exercise. Internal vs external on one axis, helpful vs harmful on the other. The output is rarely the four lists themselves — it is the cross-quadrant strategies (S–O: pursue, W–O: improve, S–T: defend, W–T: avoid) that emerge when the team is forced to compare quadrants.

BA example: A BA running a SWOT for a new SME-banking entrant identifies a Weakness (no branch network) intersecting an Opportunity (rising remote-work) → strategy: lead with mobile-first onboarding, defer branches.

A nine-block one-page visual of how an organisation creates, delivers, and captures value.

Created by Alexander Osterwalder. Nine blocks: Customer Segments, Value Propositions, Channels, Customer Relationships, Revenue Streams, Key Resources, Key Activities, Key Partners, Cost Structure. The canvas exists to make a business model visible enough to challenge — every block is an assumption to test.

BA example: A BA on a digital-bank initiative canvases two competing business models — fee-based vs interchange-based; revenue-stream and partner blocks make the trade-offs visible to the steering committee in one meeting.

A single screen of curated metrics and charts giving a role-specific view of what to monitor and act on.

A dashboard is not a report — it is an at-a-glance answer to "is anything wrong, and what should I do?". Stephen Few's principle: every chart on a dashboard must earn its place by enabling a decision the user can take. Designed in BA work alongside stakeholders, never sourced from a tool's default templates.

BA example: A BA designs the operations dashboard for a contact centre: four tiles (calls in queue, longest wait, agents available, abandonment rate). The previous 28-tile dashboard had been ignored.

A focused chart for a single key performance indicator, usually showing actual vs. target over time.

Often a line or bar chart with the target as a reference line and a coloured indicator (status badge) for current state. The visual carries three signals at once: where we are, where we should be, and the trajectory between them. KPIs without a target are just metrics.

BA example: A BA's KPI chart for first-call resolution shows the post-rollout dip and recovery; sponsors stop assuming the project failed when they see the trend.

Rectangular bars with length encoding a numeric value, used to compare discrete categories.

The workhorse of comparison. Bars share a baseline (almost always zero) so the eye can compare lengths accurately. Variants include grouped bars (compare categories within a group), stacked bars (composition within categories), and horizontal bars (long category labels read more easily).

BA example: A BA's bar chart of contact volumes by channel makes obvious that webchat now exceeds phone — leadership had assumed phone still dominated, and the staffing model is rebuilt around the chart.

A continuous line connecting data points along an ordered axis, used to show trend over time.

The default visualisation for time-series. The line implies continuity, so the x-axis must be ordered (usually time). Multiple lines on one chart compare trends; small multiples (one chart per series) compare patterns.

BA example: A BA's line chart of signup conversion over 12 weeks shows a clear inflection the week after the new onboarding launched — sufficient evidence to roll out to the second region.

A circle divided into slices, each proportional to a category's share of the whole.

Useful for one specific question: "what share of the whole does category X represent?" The eye is poor at comparing angle and area, so pies fail when there are more than three or four slices, and they fail badly at comparing slices of similar size. A bar chart almost always reads more accurately.

BA example: A BA uses a pie chart on the cover page of a board pack to show that 70% of complaints originate from one channel — the simple visual carries the message faster than a bar chart.

A grid of points where each point's x and y position encodes two numeric variables, used to expose relationships.

The canonical visualisation for relationship and correlation. Each observation is one dot; clustering, trend, and outliers all jump out visually. Adding colour or size encodes additional dimensions. A trend line (regression) makes the relationship explicit when there is one.

BA example: A BA scatterplots cycle time vs. team size across 40 squads; the absence of correlation kills a proposal to scale teams as a route to faster delivery.

A grid where the colour intensity of each cell encodes a numeric value, exposing patterns across two dimensions.

Heat maps come in two flavours: matrix heat maps (categories on both axes, e.g., calls by hour-of-day × day-of-week) and geographic heat maps (intensity overlaid on a map). The visual strength is pattern recognition at scale — humans see hotspots faster in colour than in numbers.

BA example: A BA's hour×day heat map of contact-centre demand reveals a previously invisible Wednesday-lunchtime spike, leading to a targeted staffing change rather than a global increase.

A grid of rows and columns showing exact values, used when precise numbers matter more than visual pattern.

Underrated. Tables answer "what is the value for X?" precisely, support sort and filter, and remain readable when printed. A well-formatted table with right-aligned numbers, consistent decimals, and minimal grid lines is often the right answer when stakeholders ask for a chart.

BA example: A BA replaces a colourful but unreadable bar chart in the monthly finance pack with a 12-row table; the CFO can finally cite numbers in the meeting without flipping back to the appendix.

A four-bucket prioritisation model classifying each item as Must, Should, Could, or Won't have this time.

Originating in DSDM. The acronym deliberately separates Must (release-blocker) from Should (high-value but not blocking), Could (nice-to-have), and Won't this time (explicitly deferred — the most useful bucket). The discipline is to keep Must below ~60% of effort so the team has slack to absorb change.

BA example: A BA's MoSCoW for the launch release contains 7 Musts (60% of effort), 5 Shoulds, 8 Coulds, and 12 Won'ts. The Won't column kills three weeks of speculative work that would have been quietly funded otherwise.

A 2×2 plotting items by their expected impact (y) and the effort to deliver them (x).

Sometimes called a value/cost matrix. Four quadrants suggest decisions: high impact / low effort (do now — "quick wins"), high impact / high effort (plan), low impact / low effort (fillers), low impact / high effort (avoid). The matrix is most useful when the impact–effort ratios are unobvious; if everything is a quick win, the matrix is not the bottleneck.

BA example: A BA workshops 18 backlog items into an impact/effort matrix; three quick wins move into the next sprint, and two avoid-quadrant items are dropped from the roadmap entirely.

A grid (typically 5×5) plotting each risk by likelihood (one axis) and impact (the other), with colour for severity.

Standard in PMI/PRINCE2 risk management. Each risk is placed in a cell; cells are coloured red/amber/green by combined score. The matrix gives stakeholders a single picture of the risk landscape and surfaces which risks need active mitigation rather than monitoring.

BA example: A BA's risk matrix surfaces three red cells; one (regulator engagement) was missing from the project's mitigation plan entirely, and a workstream is added before the next sponsor review.

A horizontal time-banded view showing what will be delivered, when, by which team or workstream.

Most often shown as a Now / Next / Later format (theme-based, no committed dates beyond "Now") or as a Gantt-style timeline. The roadmap is the bridge between strategy and backlog — coarse enough to remain stable for a quarter or two, specific enough to set expectations.

BA example: A BA reframes a Gantt that nobody trusted into a Now / Next / Later roadmap by theme; sponsor conversations move from "will this date hold?" to "is this still the right priority?".

An ordered list (or Kanban-style board) of work items ranked top-to-bottom in execution order.

The lived artefact of prioritisation. The backlog priority view enforces a single rank — every item has a position relative to every other — so there is always a unanimous "what's next". Often visualised as a Kanban column for queued work, with WIP limits applied to columns to the right.

BA example: A BA pairing with the product owner enforces a single ordering on a 60-item backlog; the team's stand-up becomes a 10-minute pull from the top instead of a daily prioritisation argument.