jan korbel

I wanted to share five paragraphs of customer support conversation I’ve had with the rest of the team (two other guys). As I’ve IMed with one of the guys few minutes ago, I automatically went for the IM window. But first thing that stopped me was I remembered that sometimes the IM does not send longer messages. So I am thinking: “OK, there has to be some better way.”

Then it clicked: “Oh, wait, this is the sort of thing we have Basecamp account for!” And that led me to realizing one obvious disadvantage of abstract software.

Abstract software, for the purpose of this article, is the kind of software, that intentionally approaches complex problem with simple structure that provides sort of lowest common denominator functionality, that gets done the job you think your target market wants done. Typical example include Basecamp, Things or Evernote.

Take Basecamp, a “project” could be anything complex enough, you are willing to invest time documenting it, presumably because it will save you time or headaches later. That’s a wide spectrum of jobs for which 37signals made apparently successful software based on simple mental model of project being virtual sheet of paper onto which you can add notes, todo lists, share it etc.

But what’s not so visible, is that this puts a lot of work on users. You may have experienced it yourself. You have to learn how to bend the features to your workflow and/or vice versa. Sometimes the hardest part is to even think about the software when you come across something it might help you with.

Many times I failed. I just lacked the perseverance, I didn’t “get” the software, I haven’t tried hard enough.

Of course, viewed from another angle, the software failed because it required that effort from me in the first place. That’s the disadvantage of abstract solutions. Your experience with it will result from interplay of specifics of the job you want to get done, your mental model of the solution and mental model of software creator.

We are developing Fakturoid, an invoicing web app. In context of all the above, it is relatively easier to create user interface for invoicing. Much more narrowly specified problem gets us better chance that our mental model as creators will not be that far from our target audience. Our clients will therefore have easier time learning how our app works. Last but not least, they won’t have to remember to use our app when there’s a job we may help them with if only they think of it – as in “I want invoice, so I better log into my invoicing web app.”

I think, it’s good to be aware of how much abstract your software is, how much the workflows of individual clients may vary and take appropriate actions to smooth the path. Provide them with help that shows them how their particular job gets done in your app, hint how else the app could be useful to them in context they may have not thought of etc.

I’m not sure if I manage to get my point across so comments a welcomed.