Karl-Based Software Design

User-Facing Software is increasingly the interface between your customers and your business. Remembering that this role used to be performed by humans we consider how this interface should embody the characteristics of your best possible employee, who should, in turn, embody your brand.

For the purposes of design we anthropomorphize - Your ideal employee. An amazing person… (The Simpsons’) Karl, for example.

Karl is Homer's Personal Assistant, who first appeared in Season Two’s ‘Simpson and Delilah’. If you haven’t seen it, go watch it now. We’ll wait.

Us waiting,,,

Us waiting,,,


Karl is the ultimate embodiment of great CX (Customer Experience). He is allocentric, charming, aware of his capabilities, knowledgeable, humble, proactive, and has a great memory without being creepy. He provides Great Experience.

Great Experience delights the customer, often improves their day by exceeding their expectations. This matters for two reasons:

  1. Making people happy is good. (According to Humanism!)

  2. People talk to each other about things that diverge from expectation (in both good and bad ways). Delighting customers is some of the most effective, best-value marketing.

“Any business with delighted customers has a sales force they won’t have to pay; You don’t see them, but they are talking to people all the time.” - Warren Buffett

So why am I telling you about Karl?

Because Karl is going to help us understand that this strong anthropomorphism of your user-facing software, is an excellent way to build it. I’m serious. Work out who your ‘Karl’ is, (may vary according to your brand) and use them in your design process. You can start with, and keep coming back to - your new fundamental design mantra…

WWKD?

Part of the Karl-Based Software Design Process involves role-playing User Stories. Yes, I mean actually role-playing. Someone gets to stand up and act out being Karl (your app).

Example: Let’s say you’re a Bank, and a customer, Waylon, wants to make a transfer:

User-software interactions, paraphrased.

User-software interactions, paraphrased.

And so on, you get the idea… [the above is a mercifully-abbreviated version of how this story often plays out in software interfaces]

Now let’s imagine the best-informed, most helpful Karl-type interaction. Remember, Karl already knows everything he can know (without being creepy), and why wouldn’t he... he works for you! (Side note: It's fun to get team members from other domains in the room and brainstorm everything Karl could possibly know.... (say it with me) without being creepy!)

waylon2.png

*Karl keeps your original goal in mind, makes proactive decisions and will even remember you experienced this minor inconvenience because Karl plans to knock your socks off by apologizing for it, and maybe even compensating you for it, next time you interact.

Karl is DELIGHTFUL! and he’s humble about it! Users LOVE him.

karl2.gif

Yes, it does imply greater complexity to WWKD your software. A few more parts of your stack have to talk to each other. But I bet you a dozen Krispy-Kremes it's worth it.

Every time you improve your WWKD software, those gains are applied to every customer interaction. It’s like you’re improving all your staff, by training one staff member.

Role-playing your User Stories, where someone in your team assumes the ‘character’ of the software interface, embodying your brand, and the whole team brainstorms solutions to customer needs, and edge cases, is a very effective step in the design process.

build_flow.png
James Flynn