Too much information

When working with users, spare the gory details.

The thing about being an internal software team is that you don’t have potential users.

You just have users.

If you’re lucky, they’ll tell you what they need.

More often, it’s up to you to figure it out, and ask for confirmation.

We were trying this for a particular project recently, and having zero success: Circular conversations, frustrating miscommunication, confusion all around.

(I’m leaving out details to protect the innocent.)

The goal was to get sign-off on a quick MVP and a longer-term design.

But something wasn’t working.

Finally we decided to try a new tactic: We stripped away all the details about how the information would be structured and shared, leaving only what the users would actually see.

A mock-up of the MVP.

A couple sentences about the intent of the longer-term project.

We narrowed the presentation to the immediacy of the user’s context, leaving out the generality of our own.

Within 20 minutes of a half-hour meeting they got it.

Approved. Done. Get to work.

We share the details because they’re important to us and we want our users to understand the bigger picture.

But sometimes that’s not what they need.

The user’s context is very different from the developer’s view of the whole system.

And sometimes the developer’s view is just too much information.