Rules for prototyping government e-services

1. Start with the Experience, Not the Tech

  • Prototype the user journey first (what people see, feel, and do), not the back-end system.
  • Show interactions, touchpoints, and service flows—even if the tech is still “fake.”

2. Prototype the Whole Service, Not Just the Screen

  • Services are more than interfaces: include support channels (calls, emails, chat), physical elements, and human roles.
  • Use service blueprints to visualize both frontstage (what users see) and backstage (staff processes).

3. Make it Real Enough to Get Feedback

  • Low-fidelity is fine, but the prototype must allow users to experience the service.
  • For example: clickable mockups, role-play, or paper forms can work if they help people understand the flow.

4. Prototype at the Right Fidelity

  • Early stages: rough sketches, storyboards, role-play.
  • Later stages: clickable wireframes, wizard-of-oz simulations, or live “fake front ends.”
  • Don’t overinvest early—refine only after you validate assumptions.

5. Design for Iteration

  • Expect multiple rounds. Each prototype should answer a question or test a hypothesis.
  • Example: first test “Will users understand the service steps?” → then test “Is the language clear?” → then test “Does it integrate well into their real life?”

6. Test with Real Users in Realistic Contexts

  • Services often fail not in design, but in delivery.
  • Include real-life conditions: accessibility needs, time pressures, mobile devices, etc.

7. Involve All Stakeholders

  • Prototype with staff, policymakers, and back-office teams, not just end users.
  • Services fail when operations or policies can’t support the user-facing design.

8. Expose the Invisible

  • Services rely on backstage processes: databases, approvals, regulations.
  • Make these visible in prototypes (e.g., “Here a clerk approves the request within 3 days”) so gaps or delays can be spotted.

9. Keep it Disposable

  • A prototype is not the final system.
  • Build just enough to learn—then throw away or adapt. Don’t get attached.

10. Communicate the Story

  • Prototypes should tell a story of how the service works.
  • Use journey maps, storyboards, or short videos to help everyone grasp the “before and after” experience.

Summary:
Prototyping services means simulating the end-to-end experience—people, processes, and technology—at the right level of fidelity to learn quickly. Keep it cheap, user-centered, and iterative.

Leave a Reply

Your email address will not be published. Required fields are marked *