Service Desk: Resources

Use this when: Your organization is stuck optimizing what you already do, but you're not sure if what you're doing actually matters.

Phase 1: Reframe

Stop asking "what content should we make?" Start asking "what service could we provide?"

• Identify the actual job your audience needs done
• Surface and challenge your institutional assumptions
• Define the community problem you're solving and the outcome you're aiming for

Phase 2: Minimal viable intervention

Find the smallest thing you can test that would create real value.

• Design something you can try within weeks, not months
• Focus on learning quickly, not building comprehensively
• Choose interventions that are accessible and immediate

Phase 3: Measure what matters

Track whether you're actually solving the problem, not just whether people are clicking.

• Focus on outcomes and behavior change, not pageviews
• Set up simple measurement routines you can actually maintain
• Build feedback loops that help you improve

What you get: A clear service statement, a concrete first step, and a way to know if it's working.

Use this when: You're facing a specific challenge and need to cut through the noise fast. This is the structure we use in our 60-minute consulting sessions. You can use it yourself or with your team.

The process:

1. Frame the uncertainty

• What do you think the problem is?
• What evidence do you actually have?
• What are you assuming?
• What would change if you knew the answer?

2. Define the job-to-be-done

• What job is your audience hiring you to do?
• What are they trying to achieve in their lives?
• What alternatives exist?
• What makes you different?

3. Design minimal viable intervention

• What's the smallest thing you could test?
• What would you learn from it?
• What resources does it require?
• What's the timeline?

4. Set up measurements

• What would success look like?
• What signals would tell you you're on the right track?
• How will you collect this data?
• When do you evaluate?

What you get: A one-page summary with your problem clearly framed, a concrete intervention to test, and a plan for measuring results.

Use this when: You need to align your team on who you're serving and why; or you're planning something new and want to start from the right foundation.

This is a one-page canvas that helps you map out the real job your information does in people's lives.

• The situation: What's happening in your audience's life that makes them open to your service? What constraints are they facing?
• The job: What are they actually trying to accomplish? What progress are they trying to make? What does success look like to them?
• Current alternatives: What are they doing now? What other information sources exist? Why aren't those solutions sufficient?
• Your value proposition: What unique job does your information do? What makes you better suited than alternatives?
• Forces at play: What's pushing them away from current solutions? What's pulling them toward yours? What makes them hesitant? What keeps them stuck with what they're already doing?
• Outcomes & measures: How will you know they've made progress? What behaviors indicate the job is being done?
• What you get: A shared understanding across your team of who you serve and why. A foundation for making decisions.

Use this when: You're stuck, strategies aren't working, or you're about to launch something new.This is a sequence of questions that helps you break down problems and challenge assumptions.

1. What do we think is true? (Surface your assumptions)
2. What evidence supports this? (Test whether your assumptions hold)
3. What would have to be true for this to work? (Identify what you're depending on)
4. What are we optimizing for? (Clarify your actual goals)
5. Who are we serving and why? (Return to fundamentals)
6. What's the simplest version of this? (Strip away complexity)

The key move: Getting from "how do we get more traffic?" to "what problem are we solving for whom?"

Use this when: You feel like you're running on a hamster wheel—busy but not sure if you're getting anywhere.

Warning signs you might be in the trap:

• Most conversations are about distribution, not purpose
• Success is measured only in clicks, opens, and time on site
• "Best practices" drive more decisions than audience research
• You adopt solutions because competitors use them
• Your team knows what to optimize but not what you're optimizing for
• Experiments change tactics, not underlying assumptions
• You talk about "engagement" without defining what it means
• You have growth goals without clarity on who you're growing for

The reset questions:

• Who are we serving?
• What job are we doing for them?
• How would we know if we're succeeding at that job?
• What would change if we had that clarity?

This is a companion to the Tactical Optimization Trap Audit. The optimization trap is being busy with tactics and losing the purpose. The purpose trap is the opposite failure: being full of purpose and still not useful to anyone.

Why we do this to build services: There is a failure mode that looks nothing like apathy. It looks like conviction. A team gathers around a compelling purpose, commits to making change, adopts the language of impact and care, and wins support from funders who find that story moving. Everyone feels the work matters. And the work can still be, in the lives of the people it claims to serve, beside the point.

This trap is harder to escape than the optimization trap, because everything about it feels virtuous. It is also more fundable, which removes the financial pressure that might otherwise force a correction. The result can be a team that is sincere, well-resourced, admired by peers, and not especially useful.

The trap rests on a few comfortable beliefs. Each one feels obviously true. Each one quietly substitutes something easier for the discipline of starting from need.

"Our intention to make change means we are centered on people." Deciding what change you want to bring about is an act of authorship, not service. It puts your goals at the center and casts the audience as the material your purpose works on. A service starts the other way around: the people you serve define what useful means, and you find that out before you decide what change is even on offer. Owning the change as your intent and centering people's needs are not the same move. They often point in opposite directions.

"Impact proves we are relevant." You define the impact you measure. That makes impact a measure of how well you executed your own theory, not a measure of whether anyone needed it. You can hit every impact target and remain irrelevant to people who never had the problem you set out to solve. Need-first measurement asks a harder question: did a specific person get to do something they were trying to do, because of us?

"Care and purpose restore trust." Trust is not produced by feeling concern for people, or by declaring that you do. It is earned, slowly, by reliably meeting a need the person actually has. A team can be full of genuine care and earn no trust at all, because care that is not aimed at a real need reads, from the outside, as being about the team's own sense of virtue.

"What funders will support is what people need." Sometimes it is. But a framework pitched as much to donors as to audiences trains a team to optimize for what is legible and moving to a funder: a clean theory of change, a story of care, a narrative of impact. Those are not the same as what is quietly useful to someone with a problem. The test is simple. Would you still build this exact thing if no funder ever heard the story? If the honest answer is no, you are designing for the grant, not the person.

"Journalism is valuable, so our job is to make it matter." This starts from the institution and works outward. It asks how to make the thing you already do feel significant. A needs-first approach is willing to reach an uncomfortable conclusion: that the most useful response to a given need might not be more journalism, or might not be you. Skipping that question is how a team secures its own relevance on paper while missing it in practice.

Warning signs:

• You can describe your purpose and your desired impact in detail, but cannot name one concrete need you verified with people outside the building.
• Your strongest evidence of value is praise from peers and funders, not changed behavior among the people you serve.
• The words doing the most work in your strategy are about the producer: intention, purpose, care, mission, voice.
• You measure the change you hoped to cause, and never check for the needs you might have missed.
• Removing the funder from the room would change what you build.

The reset questions:

• What does someone we serve need to do? How do we either remove their barriers to doing it or give them an aid in doing it? How do we know it is true for them and not just for us?
• If we achieved all our impact goals, who exactly would be better off, and would they agree they needed what we built?
• What would we build differently if only people who had the problems we try to solve were our audience, and no funder or peer ever saw it?
• Is our work the right response to this need? How do we know?

The point is not that purpose, care, or impact are wrong. They are necessary. The trap is one of sequence and source. When purpose comes first and need comes later, if at all, purpose becomes a story a team tells itself about why its existing work matters. When need comes first, purpose stops being a claim and becomes a consequence: you are useful, so you matter, and you can prove it by pointing at someone other than yourself.

Use this when: You're making decisions and want to understand how solid your reasoning actually is. Not all evidence is equal. This hierarchy helps you evaluate what you're basing decisions on.

From strongest to weakest evidence:

• Strongest: Direct audience research: Interviews about specific jobs-to-be-done, observation of actual behavior
• Strong: Observational signals: Qualitative feedback or quantitative consumption data; community conversations about your work, patterns in behavioral data
• Moderate: Proxy indicators: Analogies from similar contexts, academic research on information behavior, trends in adjacent fields
• Weak: Secondhand claims: What worked for someone else in a different context, vendor promises, "best practices" without validation, institutional preferences
• Weakest: No evidence: "We've always done it this way," "Everyone does this," assumptions about what people need

Make decisions based on the best evidence you can access. When you can't get strong evidence, at least know you're working with weak evidence.

Why we do this to build services: Most teams place themselves at the center of a map they have never drawn. Before you can serve a need, you need to see where you actually sit in the landscape people already use, and who else is already meeting that need in ways you may not have considered.

An ecosystem map flips the usual framing. Instead of placing your organization at the center with the audience as a single block on the outside, you put the person and their need at the center, then map everyone and everything that already shapes how that need gets met.

How to run it: Draw two circles, one inside the other. In the inner circle, place your core audience and the people closest to them: family, neighbors, the WhatsApp group, the local Facebook admin, the trusted barber or pharmacist. In the outer circle, place the wider forces: other publishers, platforms, and algorithms, the library, local government, schools, mutual-aid networks, search, and AI assistants.

Then draw the relationships. Who do people actually turn to first when they need to know something? Where does your work sit in that flow, and where is it absent?

Don’t forget about actors that are not people: algorithms, group chats, notice boards, and government portals are all part of the ecosystem, and all shape whether a need gets met.

Media example: A local outlet mapping parents of school-age children in a certain town found that the most trusted source for school-closure information was not any newsroom. It was a single parent who ran the class WhatsApp group and reposted official notices faster than anyone. That insight reframed the project: instead of competing with her, the outlet built a service that provided her with reliable information she could pass along.

What you get: A clear-eyed picture of where you already have a role, where you are missing, and who you might serve or partner with instead of duplicating.

Why we do this to build services: People are unreliable narrators of their own information behavior. They tell you they read carefully; you watch them skim a headline and move on. Observation collects the tacit evidence that interviews miss by watching real behavior in real context.

How to run it: Find a real setting where your information need plays out: someone checking the weather before work, a commuter scanning their phone, a community meeting where people share what they have heard. You can stand back, or participate and observe as you go.

Capture four things as you watch:

• What did you see and hear? include direct quotes.
• What surprised you, or did not match what people had told you.
• What problems or friction you noticed.
• What new ideas came to mind at the moment.

The richest material is the mismatch between stated and actual behavior. 

Media example: A team building a transit newsletter sat at a bus stop for a morning. They learned that nobody opened an app or a newsletter while waiting. People asked each other. The useful intervention was not a better newsletter but a way to make accurate, real-time information shareable by word of mouth.

What you get: Evidence about behavior, not self-report, which is some of the strongest evidence on your evidence hierarchy.

Why we do this to build services: Needs surface at moments you will never be present for. A probe gives you access to everyday behavior over days and weeks without an observer standing over it, so you can design for the real rhythm of people's lives rather than the controlled conditions of an interview.

A probe is a small kit you hand to a few people so they document their own lives over a set window. It might be a short daily diary, a prompt to photograph every place they got news that day, or a few "I wish" and "I like" cards to fill in.

How to run it: Give five to ten people a simple kit and a clear, light task. For example: "For one week, screenshot or note every time you went looking for information and could not find a good answer."

Keep the daily effort under five minutes so people actually do it. Provide prompts: what did you need, where did you look, what did you find, how did you feel.

At the end, sit with each person and walk through their entries together. The diary is the conversation starter, it is never the finding!

Media example: A health outlet asked new parents to keep a one-week "questions diary" of everything they wanted to know but were unsure who to ask. The diaries surfaced a cluster of overnight, time-sensitive worries that no daytime article or hotline addressed. That cluster became the brief for a new service.

What you get: A view of need as it actually occurs in people's days, including the moments you would never be present for.

Why we do this to build services: Needs live in stories, not in survey responses. A well-run interview surfaces activities, motivations, and frustrations in people's own words, which is the raw material you design from. This is the workhorse method. Plan to talk to five to ten people.

A good interview is not a survey read aloud. It is a guided conversation that lets people tell you stories, from which you extract needs and read between the lines. Structure it in three movements.

Beginning: Put the person at ease. Introduce yourself, then explain clearly what you want to talk about and why. Start with easy, concrete questions. If you are recording, get clear consent first.

Middle: Keep the story moving and probe deeper. This is where you understand the person's hopes, fears, and ambitions. Useful moves:

• Tell me what happened next.
• How did that make you feel.
• Can you tell me a little more about that.
• What could have made that better.
• What do you mean by that.

End: Ask what you might have missed. Ask if they have suggestions, and if there is anything else they want to add.

Some advice we learned the hard way:

• Find a quiet, comfortable place where both of you can relax.
• Begin with easy questions to warm up the storyteller.
• Really listen. People can tell when you are not, and they say less.
• Ask open questions ("What do you do?") rather than yes-or-no questions ("Do you like it here?").
• Have a plan, but do not march through a rigid list.
• Avoid double-barreled questions ("What is the best and worst part of doing x?").
• Avoid leading questions that smuggle in your preferred answer.

Media example: Instead of asking "would you pay for a local news subscription," which invites a polite, useless answer, ask "walk me through the last time you really needed to know something about your area and tell me what you did." The second question produces a story full of real needs, dead ends, and workarounds you can design around.

What you get: First-person accounts of real needs and frustrations, the foundation on which everything else is built.

Why we do this to build services: Memory degrades within minutes of an interview. If you do not capture what mattered while it is fresh, the surprising detail that could redirect your whole project is the first thing to go. Story hooks are how you preserve the raw material before it fades into a vague "that was interesting."

Capture, immediately:

• Who did you meet: Age, location, role, situation.
• What key things stood out as memorable or surprising?
• What did this person care about most?
• What motivated them? What frustrated them?
• A few exact quotes and comments.
• Ideas for change that came out of their story.

Media example: After ten interviews, a team had ten one-page story hooks pinned to a wall. The surprises clustered: again and again, people described being overwhelmed not by a lack of information but by an inability to tell what was trustworthy. That pattern, visible only because each conversation was captured fresh, set the direction for the whole project.

What you get: Comparable, vivid records across many interviews, so patterns become visible when you lay them side by side.

Why we do this to build services: A team designing for "the audience" is designing for no one. Personas and archetypes make your research findings concrete enough to hold a whole team to the same reference point, so design decisions are grounded in evidence rather than each person's private idea of who they are serving.

These are two different ways to make research concrete, and the difference matters.

Personas

A persona is a composite character built from your research data, not invented from thin air. It summarizes findings into a single tangible figure your team can picture.

A persona includes:

• Name and a photo or sketch.
• Age and a short background about their life.
• Needs and expectations.
• Preferences and motivations: what they care about, what drives them.
• Frustrations: what worries or annoys them.
• A quote that sums up their attitude or need in their own voice.

The discipline that matters: every element should trace back to something you actually heard or saw. A persona built on assumptions is just your bias with a stock photo attached.

Media example: "Marwa, 34, runs a small business and gets all her news in the ten minutes between closing the shop and picking up her kids. She does not want an analysis. She wants to know what changed today that affects her week." A persona like that can kill a planned long-form analysis product and instead point to other opportunities, saving a team’s resources.

Archetypes

An archetype describes a pattern of need or behavior rather than a person. Instead of "Marwa, 34, shop owner," an archetype is "the time-poor catch-up reader who needs to know what changed and why it matters to their week." It strips away name, face, age, and demographics, and keeps the part you actually design for: what the person is trying to do and the state they are in when they need you.

An archetype usually captures:

• The core need or job: what this person is trying to accomplish.
• The situation or mindset that triggers it: when and why this mode kicks in.
• Behavior: how they currently try to meet the need.
• What "done" looks like for them.
• What gets in their way.

You typically end up with three to six archetypes that, between them, cover the range of needs you saw in your research.

Media example: A newsroom mapped four archetypes instead of personas: the catch-up reader who wants to know what changed, the decision-maker who needs to act on something specific (vote, apply, attend, avoid), the deep diver who wants to understand a story fully, and the worried checker who needs to know whether something they heard is true. Each one implies a different format, length, and tone. One person can be all four in a single day.

Why archetypes are often more useful

Personas are vivid and good for empathy, but they have real failure modes, and archetypes avoid most of them.

A persona fixes one person in place. It quietly encodes demographics (age, gender, a face) that often have little to do with the actual need and a lot to do with stereotypes. Teams start designing for "a 34-year-old woman" instead of for "someone with ten minutes and a specific question." Archetypes keep the focus on need and context, which is where design decisions actually get made.

The same real person moves between archetypes depending on the moment. Marwa is a catch-up reader at 6pm, a worried checker when a rumor hits the class WhatsApp group, and a decision-maker the week before an election. A single persona cannot hold that. Archetypes can, because they describe modes, not identities. This maps directly onto jobs-to-be-done: you are designing for the job someone is hiring you for right now, not for who they are in general.

Archetypes are also more durable than personas. Demographics shift and date quickly, but need-states tend to be more stable. Because archetypes do not carry a photo and an age, they are far less likely to smuggle bias into your design.

When to still use personas: They earn their place when you need to build empathy fast, when you are onboarding people who have not met the audience, or when a vivid human face helps a room care. Many teams use both: archetypes to drive design decisions, one or two personas to keep the work human. A practical sequence is to define the archetypes first, then, if useful, write a persona that embodies one of them.

What you get: A shared, evidence-based reference point. Personas keep the work human; archetypes keep it focused on the need, and tend to hold up better as the people you serve, and their situations, change.

Why we do this to build services: Vague problems produce vague work. If you cannot state in one paragraph who you serve, what they need, and what you have learned that changes the picture, you are not ready to build. This paragraph is a test of whether your understanding is sharp enough to design from.

Write it as a single, concrete story about one person, real or archetype:

Meet [name or archetype], a [role or situation], trying to [immediate goal]. What they really want is [deeper aspiration], because they want to feel [why it matters to them]. It is [time of day], and they are [place or context], when they need to [job to be done]. But they hit a wall: [the blocker], which keeps them from making progress. They have tried [current options], but those fall short because [the limitation]. What most people miss, but we have realized, is that what they actually need is [your insight].

Two disciplines make this work:

First, every blank comes from research, not imagination. If you cannot fill a blank from evidence, you have just found your next interview.

Second, the last line carries a lot of weight. The insight should be a genuine reframe, the surprising thing you learned that opens a new approach. If your "insight" is something everyone in the field already says, keep digging until you have one that is yours.

This is also where you make yourself name the alternatives honestly. "Current options" is rarely a rival publication. It is usually a search, a group chat, a friend, an AI assistant, or doing nothing. Stating what people already do, and why it disappoints them, is what tells you whether there is a real opening.

Media example: "Meet the worried checker, a parent who saw an alarming claim about a school in the class group chat, trying to find out fast whether it is true. What they really want is to stop the spiral of worry, because they want to feel like a competent parent who is on top of things. It is 9pm, and they are scrolling in bed, when they need a trustworthy yes or no. But they hit a wall: the official site is unreadable and the newsroom's article is three days old. They have tried searching and asking the group, but that just produced more rumor. What we have realized is that what they actually need is not more reporting, it is a fast, sourced answer to a single question at the moment the worry hits."

What you get: A one-paragraph problem statement the whole team can repeat, and a sharp test of whether you understand the need well enough to design for it.

Why we do this to build services: Insights become valuable only when you can act on them. A well-framed question opens up possibilities without jumping to a premature solution. This is the step that turns "we learned something" into "now we can generate ideas worth testing."

Turn each insight into a generative question that opens up ideas rather than closing them down. Start with "How might we..." or "What if...".

Make each question:

• Broad enough to inspire ideas, and free of an implied solution.
• Narrow enough to feel manageable.
• Clearly grounded in something you found in your research.

Write several. Each will address only a slice of your challenge, so a set of questions covers more ground than one big one. Then prioritize the few you will actually brainstorm against.

Media example: The insight "people distrust information when they cannot tell who is behind it" became "How might we make the source and reasoning behind every answer obvious at a glance?" That is a question a team can generate ten ideas against. "We should add bylines" is a solution that skips the thinking.

What you get: A handful of well-framed questions that serve as the launchpad for generating and testing ideas.

Why we do this to build services: Unstructured brainstorms default to the loudest voice and the safest idea. Rules level the room and increase the range of what gets proposed, so you end up with more ideas and better ones.

Adapted from IDEO’s Design Kit:

• Defer judgment. No bad ideas at this stage. There is time to narrow later.
• Encourage wild ideas. An unrealistic idea can spark a great one in someone else.
• Build on others. Think "and," not "but."
• Stay focused on the question. Keep your brainstorm question in sight.
• One conversation at a time. Every idea needs to be heard so it can be built on.
• Be visual. Sketch ideas. A stick figure says more than a paragraph.
• Go for quantity. Set an unreasonable target and beat it. The way to one good idea is many ideas.

If you get stuck, change the constraints: what if this had to ship in one minute, or take five years; what if it were only for older, less confident users, or only for teenagers. Shifting scope and extreme users unsticks a room fast.

Things to avoid: letting the most senior person speak first (HiPPO 🦛), writing everything in exhaustive detail as you go, and banning the silly stuff that often leads somewhere.

Media example: A team brainstorming "How might we help people verify what they hear before they share it?" set a target of 50 ideas in 20 minutes. Idea 41, half a joke that would have never been pitched as a main idea, became the prototype that worked.

What you get: A large, varied pool of ideas to develop, generated in a way that surfaces more than the obvious.

Why we do this to build services: An idea that sounds good in a brainstorm can fall apart the moment you ask who does the work. Cards force the specificity that reveals weak ideas before you invest in building them.

Make one card per idea you want to take further. The card forces you to be specific, which is where weak ideas reveal themselves.

On each card:

• The idea in one sentence.
• What needs and opportunities it addresses. Tie it back to your research.
• Who benefits, and what value they gain.
• How it works, with a small sketch.
• Who needs to be involved, and what resources and support it requires.

Media example: "A weekly text that tells parents the three things happening at the school this week" fit on one card. Writing "who needs to be involved" exposed that it depended on a school secretary who had no time to supply the information. Better to learn that on a card than after launch.

What you get: A small set of developed, comparable concepts, each tested against need and feasibility before you invest.

Why we do this to build services: A pile of notes is not insight. You can do excellent research and still fail to act on it if you never sit down and name what you found. Synthesis turns raw material into a small set of findings you can design around.

P.O.I.N.T. is a simple way to synthesize. Get everything onto sticky notes or a shared board, then sort under five headings:

• Problems you observed.
• Opportunities you can see.
• Insights you gathered. These are the "aha" moments and unexpected learnings, not just facts.
• Needs people have.
• Themes that stand out across everything.

Do this on a wall or large shared surface so the whole team can see it and move things around together. Synthesis is a group act of pattern-finding, not a solo write-up.

Media example: A newsroom's board of sticky notes kept clustering around one theme: people did not distrust journalism in the abstract, they distrusted not knowing who was behind a given piece of information. That theme, named explicitly, became the spine of a transparency-focused service.

What you get: A structured bridge from raw research to a small set of insights you can actually act on.

Why we do this to build services: Paper plans hide problems that surface the moment you try to walk through an experience. These are cheap, fast ways to feel how a service would play out before you build any of it, so you find the obstacles while they are still free to fix.

Storytelling. The simplest version. You need three people: a storyteller describes their most amazing version of the service experience to a friend; the friend encourages and asks for detail; an observer captures every idea embedded in the story. Swap roles and perspectives. Tell it through the eyes of the audience member, then a staff member, then a manager.

Roleplay and bodystorming. Put the story on its feet. With a rough stage and stand-in props, the team acts out the service scenario. Obstacles surface that you never see on paper, and emotional moments become obvious. The user starts on stage and calls in the other actors they would expect. Play a scene, stop, take notes, adjust, and play it again until it feels right. Walking through a journey in someone else's role uncovers problems and opportunities a discussion never will.

Storyboarding. Draw the service as a short comic from the audience member's point of view: the actors, the setting, the props, the key moments. It can be rough pencil sketches or detailed frames. Early on, use it to imagine alternative scenarios. Later, use it to bring a chosen concept to life so others can picture it.

Media example: A team roleplayed their proposed call-in radio segment with one person as host and one as a nervous first-time caller. Within two minutes, they discovered the caller had no idea what they were allowed to ask. They added a simple framing line at the top of the segment. That fix came from acting, not planning.

What you get: A felt, tested sense of the experience, and a list of problems found while they are still free to fix.

Why we do this to build services: Most plans assume people are waiting for what you will build. Spoiler alert: they rarely are.

They already have ways of meeting the need, and your job is to be clearly better than those for a specific job. This step forces honesty about whether there is a real opening, before you commit resources.

Work through five questions:

• What are the real alternatives, including substitutes. Your competition is rarely another newsroom. It is the class WhatsApp group, a search, a friend, an AI assistant, or doing nothing. Force-rank what people actually turn to now.
• Why do those fall short, from the person's point of view, not yours. If the honest answer is "they do not," you may not have a real opening.
• What is your differentiation, in one line. What do you offer that the alternatives do not, framed so you are the obvious choice for this specific need. Drawing a simple 2x2 on two axes that matter to the person can help you find the space where you stand alone.
• What is your durable edge. What keeps this defensible as you grow. A brand is weak on its own. Earned trust, a relationship no one else has, a community that compounds, or a genuine habit are stronger.
• What is moving in your favor, and what could sink you. Name one or two shifts (technological, social, economic, political) that make now the right moment, then name your top two or three risks and what you must be good at to survive them.

Media example: A team planning a neighborhood newsletter force-ranked the real alternatives and found the strongest was a long-running Facebook group run by a retiree. It was free, trusted, and immediate. Competing head-on was hopeless. Their differentiation became verification and follow-up, the two things the group could not reliably do, and their durable edge was a working relationship with local officials. That honesty reshaped the product before real, scarce money was spent.

What you get: An honest map of why someone would choose you over what they already do, and a clear view of where your advantage actually lasts.

Why we do this to build services: A good idea and a durable service are not the same thing. A canvas forces you to see, on one page, whether the model holds before the audience comes to depend on something you cannot sustain.

A business model canvas lays a whole model on one page so you can see how the pieces fit. Adapt the standard blocks to an information service:

• Value proposition: what value you deliver to the people you serve, and the job it does for them.
• Audience segments: who you are creating value for.
• Relationships: what kind of ongoing relationship each segment expects.
• Channels: how the people you serve want to be reached.
• Key activities, resources, and partners: what it takes to deliver, what you need, and who you depend on.
• Cost structure and revenue or support streams: what this costs, and what sustains it, whether that is revenue, grants, membership, or institutional backing.

For mission-driven work, it is worth also asking the questions from the common-good version of the canvas: who else does this affect, what is its contribution to a good life in your community, and what social and environmental costs and benefits come with it.

Media example: A promising daily SMS service looked viable until the canvas exposed that its only "key resource" was one reporter's unpaid evening hours. Naming that on the canvas forced the real question: fund the role, or do not launch. Better answered before the audience comes to depend on it.

What you get: A clear-eyed view of whether a good idea can become a durable service, and where the model is fragile.

Why we do this to build services: A service that does not become a habit is a one-off, and one-offs do not sustain themselves. Designing a retention loop means designing for durability: people come back because you keep being useful, not because you keep asking them to.

A single helpful act is good. A service survives when people come back without being chased. That requires designing a loop, not just a moment. Map the six steps a person moves through as a useful thing becomes an essential one:

• Discovery. The moment someone first meets what you offer, tied to a real moment in their day. This should connect to how you actually plan to reach people, not a hope that they stumble in.
• First use. The first experience. Keep it light. A rough version is often better than a polished one, because it shows you what matters before you over-build. What does the person do, and how does it feel.
• The immediate payoff. The concrete thing that gets solved, and the feeling that comes with it. Name the emotional payoff, not just the functional one.
• The trigger to return. What brings it back into their life: a send at a fixed time, a recurring need, a prompt, a reason. Without a deliberate trigger, even a useful thing is forgotten.
• The habit. The repeat behavior, and how it gradually changes how the person sees themselves. "I am someone who knows what is going on in my area."
• Investment and sharing. How people put something in over time (attention, input, membership, money) that makes you harder to replace, and the moment they recommend you to someone else, including why being associated with you signals something they care about.

The business point, stated plainly: "sustainable" should first mean people keep choosing you because you keep being useful, not that a funder keeps paying for you. A relationship people return to on their own is the most honest revenue and the most honest evidence of impact you can have. Build that loop first, and the funding conversation gets easier and more truthful.

Media example: A daily local briefing landed at the same minute each morning, timed to the commute (discovery and trigger). The first issue answered one question people actually had that day (first use and payoff). Within two weeks, readers reported feeling "caught up" before work (habit and identity), started forwarding it to a neighbor (sharing), and a portion opted into a small monthly contribution to keep it going (investment). None of that came from a grant. It came from a loop designed on purpose.

What you get: A retention loop that turns a useful thing into an essential one, and a sustainability story grounded in real behavior rather than the next grant cycle.

Why we do this to build services: "The experience is bad" does not tell you where to intervene. A journey map locates the exact step where things break down, from the perspective of the person going through it, so you can fix the specific failure instead of guessing.

A journey map follows a persona or archetype through the phases of meeting a need, and tracks their experience at each step.

Map these rows across the phases (for example: realizing the need, searching, finding, using, acting):

• Action. What does the person do at this step.
• Needs and pain. What are they trying to achieve or avoid.
• Touchpoint. What part of your service, or someone else's, do they interact with.
• Feeling. What do they feel here. Emojis or a simple curve work well.
• Opportunities. What could you improve or introduce at this step.

Media example: Mapping how someone tries to find out whether a local road closure affects their commute, a team found five separate touchpoints (a search, a council site, a Facebook group, a news article, a phone call to a friend) and a trough of frustration right in the middle, where official information existed but was unreadable. The opportunity was not more reporting but translation at that exact step.

What you get: A precise diagnosis of where experience fails and where a small intervention would create the most value.

Why we do this to build services: Most services fail not at the idea but in the backstage. A blueprint makes the hidden work visible and assigns accountability to every step, so you find the gaps before your audience does. It is the difference between knowing what you want people to experience and knowing exactly who does what, when, and on which system, to deliver that experience.

A journey map shows the person's experience. A blueprint shows your whole operation underneath it, lined up step by step against that experience.

The layers, from top to bottom: A blueprint reads as horizontal rows, with the steps of the journey running left to right across the top.

• Physical and digital evidence. The tangible things the audience encounters at each step: the email in the inbox, the homepage, the reply, the printed card, the event room.
• Audience actions. What the person actually does at each step, taken straight from your journey map.
• Line of interaction. The line the audience crosses every time they make contact with you.
• Frontstage actions. What your people and interfaces do that the audience can see: the published answer, the host's welcome, the visible reply from a reporter.
• Line of visibility. The crucial line. Everything above it the audience sees. Everything below it they never do.
• Backstage actions. The work the audience never sees but depends on: an editor verifying a claim, someone triaging incoming questions, a reporter chasing a source.
• Support processes and systems. The infrastructure that has to exist for the backstage to function: the CMS, the database, the SMS platform, the legal check, the partner feeding you data, the moderation policy.
• Line of internal interaction. Where backstage staff hand off to internal systems and support functions.

Two more rows make a blueprint genuinely useful for delivery: owner (who is responsible for each backstage action, by role, so nothing is "someone will do it") and pain points and opportunities at each step.

How to build it:

1. Lay your journey map across the top as the spine. The audience steps are your columns.
2. Working one column at a time, fill the rows downward. For each audience action, ask what has to happen frontstage to support it, then what has to happen backstage, then what system or process that depends on.
3. Draw the lines of visibility and internal interaction explicitly. Teams skip this, and it is exactly where accountability gets lost.
4. At each step, mark the failure points: where a handoff could drop, where a step depends on one unbacked person, where there is no plan for the unexpected case.
5. Assign an owner to every backstage action. If you cannot name a role, you have found a gap.

Where to focus your attention. The most dangerous spots on a blueprint are the vertical handoffs (where a frontstage promise depends on a backstage action that no one owns) and the single points of failure (where one person's spare time is the entire support process). Circle those. They are where a service quietly dies three weeks after launch.

Media example: A text-message answer service looked trivial frontstage: ask a question, get a reliable answer. The blueprint told a different story. Below the line of visibility sat a chain nobody had planned: someone has to triage incoming questions and sort the answerable from the unanswerable, someone has to verify each answer against a source, there has to be a documented escalation path for questions no one on staff can answer, and all of it has to happen fast enough that the reply still feels useful. The blueprint also showed that the entire "verify" step rested on one reporter checking messages between other duties. Naming that as a single point of failure, with no owner and no backup, is what turned a nice idea into a service that could actually survive contact with real demand.

As a deliverable. A finished blueprint is one of the strongest artifacts in service design. It doubles as a briefing document: hand it to whoever builds the thing, an editor, a developer, a product person, and they can see the full specification, the dependencies, and who owns what. It is also a living document. Revisit it when the service changes, because a new frontstage feature almost always creates new backstage work.

What you get: A delivery plan, an accountability map, and a briefing document in one. It makes the hidden work visible, which is precisely the work that determines whether a service lasts.

The most basic test. A working service enables a specific action, decision, or understanding that was previously blocked or unreliable. If you cannot point to what changed in someone's life, you have not yet proved you are useful. "People are more informed" is not specific enough. "Parents can confirm whether a school closure is real within two minutes of hearing about it" is.

The service addresses something you heard from people, not something you decided they should care about. You can trace your core value proposition back to specific evidence from research: interviews, observation, diaries, not just internal conviction. A service built on an assumed need can run for years without anyone noticing it is not working, because the team measures its own output instead of the audience's outcome.

Retention is the most honest signal. If people come back on their own, your service is doing its job. If you have to promote, trick or guilt them into returning, something about the value or the delivery is off. Track organic return behavior, not just reach or sign-ups. This shows that people trust you because you consistently deliver on the specific thing you promised, not because you told them you are trustworthy.

You can state in one line why someone would choose you over what they already do (a group chat, a search, a friend, doing nothing) for the specific job they are trying to get done, and that differentiation holds up when tested against real behavior. If you cannot, you are duplicating something that already works well enough.

Every promise you make to your audience depends on behind-the-scenes work and systems they never see. The service does not rest on one person's spare time, a single unowned process, or a grant cycle. You can name who is responsible for every critical backstage step, and what happens when they are unavailable.

You are building from gaps’ in peoples lives, not hopes or desires from the journalism ecosystem. You would build this even if no grant, donor, or other journalist ever saw it, because the people you serve need it. This does not mean funding or support does not matter. It means the service's reason to exist comes from the need, not from the funding story. When those two things diverge, the need should win.

Output metrics (articles published, messages sent, events held) tell you what you made. Outcome metrics (questions answered, actions taken, problems resolved, return visits) tell you whether it mattered. Both have a place, but if you only track the first kind, you cannot tell whether your service is working.

Nothing here is entirely new. We're building on decades of work from practitioners across journalism, service design, product development, and adjacent fields. The methods we've documented here reflect patterns we've identified and formalized through our work, but they draw heavily from established practices.

These methods are inspired by the great work of the SDN Academy and the wider service design canon, including Birgit Mager's foundational definitions and the work collected in This Is Service Design Doing by Stickdorn, Hormess, Lawrence, and Schneider, and others.

We did not invent them. Our contribution is the translation into journalism and media, refined through work with information producers. If these methods help your work, please credit Service Desk, which helps us keep developing and sharing them.

If you find these methods helpful and use them in your work, please credit Service Desk. This helps us continue developing and sharing these resources.

Contact: servicedesk@gazzetta.xyz

Organizations interested in adopting and teaching our Service Design for media methods can pursue this through:

• Multi-day training workshops
• Co-facilitation experiences
• Case study development
• Ongoing advisory relationship

We've worked with more than a hundred newsrooms since 2025. Interested? Get in touch at servicedesk@gazzetta.xyz.