Four Service Design Principles
1. Require Minimum Viable Initiative.
You’ve heard of Minimum Viable Product (getting your product to a testable place as soon as possible in order to start collecting valuable feedback) but how about Minimum Viable Initiative? MVI is a phrase I invented to help me remember that it’s generally best to require the LEAST amount of initiative possible from your user.
Don’t make them think, don’t make them spend 15 minutes filling out another damn profile page. Whatever your request is, get it down to just one or two basic, basic actions.
Examples: Google search bar, Amazon one-click, Tinder’s extremely minimal profile requirements, Peerby’s demand-based system for requesting goods, single sign-on account creation.
2. Minimize map shock.
Map shock is a phrase I first heard from information designer Tom Wujec. It’s the feeling of being overwhelmed when looking at a complex visual. Unless you have a strategic reason for inducing a feeling of shock in your user, always reduce map shock (visual clutter) where possible.
You’ll have to ask others whether your design induces map shock. This is because the more you work on a visual design, the more you will adjust to it, making you less and less able to perceive your own map shock.
3. Fail fabulously.
Service failures are inevitable—wait times, outages, broken stuff. The question is, how do you handle those failures?
A poorly designed service has blunt failures. A well-designed service has graceful failures.
An extraordinary service has fabulous failures. For example:
Fail: The planetarium had a broken screen, so the 3 o’clock show was cancelled.
Fail Gracefully: The planetarium had a broken screen, so ticket-holders for the 3 o’clock show got free admission to the special exhibit on dark matter.
Fail Fabulously: The planetarium had a broken screen, so ticket-holders for the 3 o’clock show were invited to look through the telescopes in the astronomy lab upstairs, which typically has limited access for astrophysicists only.
4. Be strategically scrappy.
Pixel-polishing should almost always wait for later. Rough prototypes are not only quicker and cheaper than high-fidelity simulations, but they have the added benefit of keeping conversations focused on content and not aesthetics. A cheap notebook or crappy flip-chart paper help the focus to be on quality of ideas and not the aesthetic characteristics of your storyboard/mockup/blueprint itself.