LispCast

Conceptual Models

DOET showed me that there is an order -- a process -- for making things easy to use, intuitive, and enjoyable. I want to apply that process to developing software. If I could only learn to apply the ideas of design, maybe I could make my libraries easier on the user. We've all used libraries that are easy to use. They feel intuitive, natural -- like they "just work".

There is no magic bullet to make that happen. It takes a lot of thought and hard work. But I can't help but feel that the insights into design I gained from DOET can help me create libraries that are a joy to use.

The first insight? Enjoyment of a library is not based on it's technical merits. It's not about what algorithm is used. It's not the efficiency or the number of features. In fact, it doesn't happen in the computer at all.

The most important usability aspect happens in the brain of the user.

It's about how the user thinks the library works. It's about how well the user's ideas about the system match with how the system actually works. Those ideas the user has are called the user's Conceptual Model. A good conceptual model can mean the difference between a frustrating programming experience and a delightful one.

Your main task as an API designer is to communicate a correct conceptual model to the user.

An incorrect or incomplete conceptual model will make using the library confusing. The user will think an action will do one thing but it does another. It may even make it impossible to use.

Good question. And it's pretty tough to do because the designer cannot communicate directly with the user. He/she instead must communicate through the documentation, comments, self-documenting code, and examples. All of those things the system presents to the user are collectively called the "System Image". It's the first and most important way to develop a correct conceptual model.

So improve your system image and you'll improve your usability. That's not to say that it's all superficial. The system image needs to communicate how to use the library clearly and correctly. If you can't find a clear, simple, and correct explanation for how to use it, it could be a sign that your library needs to be reworked from the bottom up. I'll explore doing that in the next articles in the series.

Here's a big diagram showing some of my ideas for ways I can communicate better to my user.

I'm looking forward to applying these to my libraries. I'm sure my users will thank me.

So, that's just the first of the principles. It won't solve all of your design issues, but it's an important concept to have before we more forward. Now that the idea is there, we can tackle the idea of feedback, which is important for the programmer and the client code using your library.