De-shittification: What Error Messages are Actually Telling Us and How to Fix Them

"Why should I spend my time in this session when there are so many other awesome sessions to go to?" 

I get it. There's a ton of great, useful content at NEDCamp. AND. I'm willing to bet you work on a site that has errors or downtime, so I'm begging you to give me your precious attention. In exchange, I'll hand you a different way of thinking about your work's relationship to user experience and tools that help you make "de-shittification" changes you can ship Monday, no matter what your role is on a team.

"But why should *I* care about error messages?" 

Think of a bad error message like an X-ray. When a site leaves a user confused with no next step, that's a symptom of something even more broken: nobody owns the message, there's no incident plan, no one decided to think about what users need when things go wrong, etc.. The results are annoying at best and catastrophic at worst. Thing is, everyone (including you!) plays a part in this. I'll help you understand what your role is in "de-shittifying" the user experience using error messages as an example.

"Sure, but what makes you the expert, Kit?"

While this is my first time at NEDCamp, I've spent 20 years helping governments learn this lesson about "de-shittification" the hard way; I currently run an effort to error messages across an entire state that both is and is not using Drupal; and, I've taught a Harvard Kennedy School lecture called "Sh*tty Error Messages" for eleven semesters straight. If a thousand grad students and a horde of bureaucrats haven't broken this framework yet, your error page won't either. ;) 

"Okay, so what are we actually going to do for 45 minutes?"

• We get tactical   

  • I'll walk through how one of my teams is thinking about fixing this at a State government level: 

    • the pilot decisions, 

    • what testing with teams taught us, and 

    • what changed once we asked practitioners what they actually needed 

  • Spoiler: teams don't want "principles." They want templates! I'll share how and why to give them both. 

• We do live diagnosis

  • We'll use real-world examples, like: 

    • error messages

    • Drupal core validation errors 

    • a common contrib module's exception text 

    • maybe your webform's default failure message

  • Then, we'll diagnose them live using the same framework. Bring your own site's worst offender if you want it critiqued!

• You get a template! 

  • You'll leave with:

    • a way to read your own sites' error messages as a diagnostic tool (instead of an afterthought)

    • before-and-after rewrites you can reuse for your own purposes

    • a case for why this is worth your time and your team's time (even if you've never once thought about your 404 page!)

"Who should come to this session?"

***No Drupal or content-writing expertise required!***

Intended Audience: Literally anyone involved in making a decision or pushing code that means a user will eventually see something your team built. Includes, but not limited to: 

• developers

• sitebuilders

• UX and content folks

• and anyone who's ever owned the client relationship when a site broke