Lecture Ergonomical Design @ UTwente

Don’t get fooled by Architects

Posted by mschmettow on 22. February 2010

Managing complexity

Working as an HCI specialist in a development team is working in a different culture having it’s own history, language, beliefs, powers and so on. Modern software systems are the most complex artefacts mankind is able to build. Accordingly, dealing with complexity has ever been a major issue in Software Engineering.

A central idea in software development is modularization, in general: How can we divide the total project into pieces that are manageable by small teams, but can be easily integrated again later on. This basically is what software engineers mean when they talk about architecture: dividing the system into components.

For independent development it is required that the components are loosely coupled, this means: Changing the internals of one component does not affect the development of any other component.

Three-tier architecture

A famous example of such an architecture is the three-tier architecture. It divides the system into the following components:

  1. Data layer: Responsible for proper delivery and storage of data

  2. Application layer: Here resides the functional part of the system. Real world processes are represented by software functions.

  3. Presentation layer: This is where functions and data objects are finally presented to the user.

Such an architecture makes it much easier to handle complexity. It also adds a great deal of flexibility. For example, new user devices can be supported by replacing the current presentation layer with a different one, which may for example make the application accessible on smartphones. Also, the data layer can support different applications. For example, a webshop may (and typically does) use the same data layer for handling the incoming orders and for managing the warehouse.

Architecture and usability

You may ask: If architectures are so marvellous, why shouldn’t we get fooled? Here it goes: Remember the quote:

The product is nearly finished, except for the usability”
anonymous developer

In user-centered design it is common sense to do usability first, for example: Know your users, know their tasks. But, if the presentation layer can be developed independent of the other components, why not doing usability last?

The answer is: Independent development, i.e. coding, does not mean that the components are independent wrt. requirements. The presentation layer can only display, what is supported by the application layer and the data layer. One may be able to quickly change colors, fonts, type of charts or even the device on which data is represented, but, if a data object is not available in the lower layer, there’s no way to display it.

Not so obvious: Several functions that are demanded by well-known usability guidelines need serious implementation on the two lower layers. Just to name a three:

Speak the user’s language

Imagine you have a nicely designed, successful website and want to make it available in a second language. This requires every data object to be held in more than one language instance. If this hasn’t been foreseen in the data model, you’ll have a hard time.

User control and freedom – Undo

Enabling the user to make every action undone is sth. we would ever demand for virtually any application. It helps so much, to safely explore the system and to recover from errors. But, an Undo function imposes serious requirements on the application and data layers: The application layer has to keep a record of every action the user has done and also has to “know” the reverse of each action.The data layer has to make sure that any “historical” state of the data is kept in order to recover it.

User control and freedom – Cancel

Setting the user in control also means to be able to cancel any long-running process at any time. Here, application and data layer together have to make sure that every incomplete (i.e. cancelled) action leaves the system in a well-defined state. This is often referred to as a rollback, and it is far from trivial.


Architectures are a wonderful thing and developers usually present them with pride. But, as long as some software developers think of usability as a skin-deep property, the three-tier architecture is harmful. Whenever you hear a software developer say something like:

We have a three-tier architecture, we can make the user interface look as we want at any time.

Ask him oder her:

  • Can we make this website multilingual, once it has become a success?

  • Do we have an Undo function for every filter the user applies to the image?

  • Can the user at any time cancel the defragmentation of his hard disk?


5 Responses to “Don’t get fooled by Architects”

  1. Ivor said

    The part that I was missing in the above piece of architecture is the position that usability has to this three-tier architecture. The problem of usability is that it is applicable to two layers of this model, namely the application layer and the presentation layer. The usability aspects in these two layers are associated and should be treated as such. So doing research beforehand for the usability, will make it possible to define possible usability problems for both layers, and thus make sure the three-tier architecture can still function, but WITH improved usability.

    Of course, this would be a utopia. The usability paper that we had to read for the lecture and assignment clearly shows that usability isn’t high on a companies list. But still, if usability experts show the fruits of their labor (as Martin showed in the last lecture, you can save a lot of money by doing usability research), companies should be eager to have a usability expert (in regard to the paper: I hated the name “usability champion”, because it would indicate superiority, which isn’t a good way to present yourself if you’re an outsider. Research on group processes has shown that much).

  2. mschmettow said

    Agree, I don’t like the term “usability champion” either. Moreover, these discussions often have an impetus of evangelism and even separatism. In my opinion usability experts should strive for being supportive and contributing to problem solving in the development cycle.

    For example, the paper is very negative about use case modeling. But, this is a widely used and standardized methodology. Instead of insisting on their own methodologies for task modeling, usability experts should first adopt this method and improve it. In fact, there already is such an usability-oriented adaption of the use case method introduced by Constantine & Lockwood called essential use cases.

    • Ivor said

      Do you think that this evangelism and separatism is the reason why usability experts aren’t liked that much? Did you have similar experiences as described in the article? And do you have advice on how to prevent this?

      In the course Interface and Interaction Design, we did learn and use the use cases. They looked very useful and I don’t think they should be passed by. It also bridges a gap between the programmers and the usability experts/users. But of course, there isn’t one method that is the best, so combining the use cases with ‘good ol’ fashioned’ user studies would be the best (giving the usability expert a better inside into user behavior, and thus a better basis for making use cases).

      • mschmettow said

        To your question: I had bad and good experiences. Good experiences were almost always when I could make detailed and feasible suggestions on how to improve the user interaction. As I said: Focus on problem-solving, not on values. Be the one who learns the foreign language.

        User studies and use cases are quite different things: Use cases are a document standard for requirements being somehow neurtral on how the requirements were obtained. You can write them with or without usability requirements. Thus, the problem is: Use cases don’t *prompt* for usability requirements. User studies are more in the evaluation/testing part of the design cycle.

      • Ivor said

        With user study do you mean a study with use of a mock-up/prototype? In the course Interface and Interaction Design, we already did some user study at the beginning of the project. This was to gather information on what the user does and what is is capable of. With this information, we would make the user requirements. So this is outside the evaluation/testing part of the design cycle. Would you consider this to be a user study?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: