Software with a point of view

By

A software maker's taste shows up in defaults, empty states, and ordinary interactions. Give your app character through decisions that help people use it.

~~~

You can tell something about a software maker from the decisions their app makes for you.

A writing app opens straight into a document. A task manager asks for a project before you can save a task. A photo app keeps the original file where you put it, or imports everything into its own library.

Each choice says what the maker expects you to do, and what they want to make convenient.

That is the kind of personality I care about in software. A funny loading message can be pleasant, but I spend more time living with the defaults.

Someone has to choose

Suppose we’re building a small app for saving links.

We can ask people for a folder, tags, a description, and a rating whenever they save something. Or we can save the link immediately and let them organize it later.

Both approaches have a reason to exist. Someone maintaining a reference library may appreciate the structure. Someone saving a page between meetings may abandon the form.

Giving everyone a setting for every possible preference doesn’t remove the decision. We still need to choose the initial behavior, explain the settings, and deal with the combinations.

I would choose a specific person and situation first. For someone collecting pages to read later, saving immediately seems like the better starting point. I would add organization when the collection becomes difficult to use.

Fig 1 · 1/3What does saving a link require?
Choose a default

The drawing follows the same saved link through two possible defaults. Both reach storage, but one asks the person to organize before returning to what they were doing.

Character can help the ordinary task

A small detail feels considered when it fits the work.

After saving a link, the app could keep the page title visible and offer Undo. If the link already exists, it could show the saved copy. Those choices make the app feel like someone thought about what happens during an ordinary day.

An easter egg can fit too. I like the idea that a maker enjoyed building something enough to leave a small surprise. But I would keep it away from tasks where surprise creates confusion.

A payment result should tell you whether the payment happened. An error message should explain what you can do next. Making either one mysterious to express a personality would cost the person using it time.

The same applies to animation. A playful transition can be enjoyable when it doesn’t delay the action, and people who reduce motion should still get a clear result.

An opinion can be wrong

Having a point of view doesn’t excuse refusing feedback.

If people keep losing their saved links, I would investigate the behavior before defending the design. Perhaps the labels are unclear. Perhaps the app assumes a way of organizing that its users don’t share.

That doesn’t mean adding every requested feature. It means understanding which problem the request describes. A request for folders could mean someone needs to separate work from personal reading. There might be a smaller way to provide that distinction.

When choosing a default, I would ask whether it suits someone I know, and whether I could explain why.

Try that on your app’s first screen. Follow the default path without changing a setting. Notice what it assumes about the person using it. If those assumptions don’t match the person you’re building for, start by changing one of them.

Tagged: Essays · All topics

Want me to talk about your product? You can sponsor this site.

~~~

Related posts about essay: