Corvus Consulting

Not too many businesses or software makers I know would choose to greet customers with that kind of statement, but in a cafe where I like to work sometimes, it happens a hundred times a day without anyone realizing it. What’s worse, we do this in software even more.

Now, nobody is actually saying ‘Welcome, Stupid’ as people walk through the door. Here’s what happens: the door into the cafe has a handle that is designed to be pulled from the outside, and a sign that says ‘push’. Nobody reads the sign, and the unitiated naturally give it a pull, only to be stoppped by a door that won’t open that way. The door rattles loudly, people look up from their newspapers and laptops.

I’ve watched this happen many times: there’s a moment of confusion – is the cafe closed? No there are people inside. Am I doing something wrong? 2 seconds later the customer is in the door, but a bit sheepish and embarrassed. It’s not a great way to greet a customer, but it’s not severe enough to make those customers give up because the problem is solved quickly, and we all want our coffee. It’s just a small touch that could improve the first-time visitor’s experience that much more.

What’s surprising is that this is exactly how software often greets people for the first time. It’s not uncommon t be greeted by a number of technical questions and speedbumps the first time you start some software. Sometimes the software wants to update itself right away, others it demands a number of configuration inputs to be made, and still other times it insists on holding your hand when you don’t need to be held at all.

What’s the key to the right kind of first impression? Knowing the people you are building for is a good start. The next step is to make getting into the software as smooth an experience as possible, and that often means getting out of the way and letting people start to click around and explore a bit. Be sensitive to indicators that the person might need some assistance, and step in with configuration questions only when really necessary to get something done. And your updates can probably wait for at least a few minutes after the software has started, rather than jumping all over someone at startup.

Cafes and software might not seem to have much in common, but both provide an experience that is nuanced and emotional. Designing software to work with that reality will not only create a good first impression, but will avoid one that makes your new customer feel dumb just for walking in the door.

Sometimes when I take in a new book or a nifty new application, I imagine that “my next project will be perfect now that I’ve read this.” Then I remember that there’s never a magic bullet, and things happen in every project to throw you off. That’s just life.

Though we might fantasize about projects where we can try out every method and produce the perfect set of design specs, some methods and deliverables just don’t fit into some projects. The trick is not to get caught up in shoehorning the process into the project.

Instead, we can think of the constraints, goals and context of each project as giving it a unique shape, and that shape requires a custom fitting of methods and specs. The question then turns from “how do I fit my process in” to “what process is right for this project”. And the answer to that is both in the traditional source material that information architects and designers work with, but it’s also in the people you’re working with.

Getting to know the backgrounds and personalities of the team will tell you the things they need more and less information about to make the right product. A team with a passion for gaming has to know less about making software entertaining than a team more experienced in financials. A team with more experience in financials will be better tuned to the needs of a money management website. We can use that insight to avoid revisiting what’s known, and focus more on discovering what’s unknown and explaining what’s unfamiliar.

There’s no checklist that can answer the question of what methods and deliverables a given project should have until you get in there and talk with the people involved. When you begin to probe in different directions, you’ll get that nod of understanding at different times, and you can use that to inform the choices you make about the process you put into play.