Why?

Designers are pretty dang good at asking that one tiny infuriating question. In my experience, the question is often taken as a challenge to an idea or even insulting, but the reality of why we ask is a bit different. We want to understand the problem as you understand it. We want to understand where you are coming from and how you arrived at the conclusion presented.

Unfortunately, we are not always the greatest at explaining ourselves when we make decisions that impact others with the choices made in the design of a product.

For example, I recently led a project to reorganize and align the settings in both Jetpack and Calypso. Calypso is the code name for the Javascript-based interface we built for use on WordPress.com. The initial idea for it was during one of our team meetups last year where we sketched out how to make the settings align in a way that will be faster to navigate and make the options clearer for the people using our products.

After months of hard work getting around 300 pull requests were merged in followed by a few weeks of beta testing, we were eager to get what this improvement out to the public. We finally launched it in Jetpack 4.8 aaaand… it was almost unnoticed because of a bug in the sitemaps module that started crashing sites on older versions of PHP (which was resolved shortly after).

We did eventually start getting more and more feedback accumulating, but the feedback was peculiar. It largely came from a group of people I have dubbed Jetpack Experts. These are folks who have become intimately familiar with Jetpack and its inner workings. They are not primarily developers. These users have been using Jetpack for years now, have grown with it, and have certain expectation of what Jetpack is.

The feedback we got was largely centered around the fact that we shifted from an interface exposing each and every module in a large list to an interface that is an attempt to make the settings clearer for newer users and a bit more focused. The problem here was twofold: We didn’t do a great job explaining why we made these decisions and we didn’t realize the extent to which our Jetpack Experts relied on the module list. These folks primarily use it for debugging and occasionally disabling features.

When I was at WordCamp Europe, I ran into several of these Jetpack Experts in person (for those of you I talked to, thank you for your questions) and they all asked that dreaded and wonderful question: “Why?” I answered them to the best of my ability explaining the motivations behind the change and where we’re going with Jetpack. They quickly changed from feeling disenfranchised to being excited about the future of the product. I realized that even where we explained some of the exciting bits about the new settings, we didn’t do a great job assuring our experts we’re bringing them along for the ride.

We all need to do a better job explaining the why’s of our decisions to the folks that rely on our products. There are plenty of benefits of explaining ourselves.

When you explain why to the people using your product:

• You will help set their expectations of the product and where it is going.
• You will build user trust rather than destroy it.
• You will understand your decisions better from the viewpoint of those using it.
• You might even reduce some of the load on your support staff.

Slack does a pretty good job of this in a few places. It has always had delightful change logs in the app store update box. It also features a What’s New section that gives us a heads up when something interesting or useful is available.

I recently got an update to one of my backpacks in the mail from WANDRD that included a safety camera strap and a note explaining how it will ensure your camera never hits the floor, even if the main camera strap fails. If physical products can make that kind of effort, so can we.

What interesting ways have you seen products explain changes or additions?