1. The requirements challenge How can we analyze and understand future users, their current way of working, and the context of use? How can we base design decisions on that understanding? What are the relevant characteristics of users, tasks, and the context of use? To be able to adapt interactive systems to future users and the context of use, we need to know who the users are and what the context of use will be. It is amazing to see how many interactive systems are being developed with a complete lack of understanding of the users and the way they currently go about their business. I have been asked why we even need to analyze the way people currently work: "Our system will change everything anyway." But how can you know your system will improve the life, work, or business of people if you don't know the current situation? In contrast to engineers, who often love their tools because of their inherent qualities, users will ask themselves at some point how their life, work or business will benefit from using the tool. Quite often that point coincides with having to pay for it. If you're the one who's selling the tool, you will want to have a valid answer ready. 2. The specification challenge How can we define and describe the scope and the specifications of interactive systems in such a way that they can be understood, evaluated, corrected, and approved by all stakeholders? Research from the Standish Group shows that an important reason why IT projects go wrong (and 84% of them do go wrong) is that the specifications are incomplete or unclear. In other words, when you invest in the development of an interactive system, more often than not, you have no idea what you will get. Some development projects still start without specifications, only with some vague requirements. Imagine starting laying foundations and bricks for a house without knowing where the walls will be, the number of floors or the position of the doors and windows. More often, there are specifications in the form of a long, complex and very technical document. But these specification documents fail to stabilize the functional scope of the project. Because none of the stakeholders have the time to read 500-page documents. And those who try, give up after 20 pages because they cannot understand it, let alone imagine what it would be like to use the interactive system. To answer this challenge, development teams have started experimenting with other specification formats, such as use scenarios and use cases. 3. The design challenge How can we design interactive systems in such a way that they are optimally adapted to future users and their context of use? Designing interactive systems is not so much an inspirational challenge but rather one of translating requirements and specifications into design solutions that work. There are a million ways to design an e-commerce web site, but only two or three of those fit the product you want to sell, the clients you want to sell it to and the way these clients want to buy it from you. Without clear requirements and specifications, you're picking one out of a million instead of one out of three. The design challenge is also one of elimination. It's easy to make it hard. Designing complex and hard-to-use systems comes naturally. But it's hard to make it easy. We often design a complex first try and then continue with the hard work of eliminating everything that is not absolutely necessary. And last but not least, designing interactive systems is a political and collaborative challenge. You don't design interactive systems on your own. A lot of parties want to have their say and expect to see their opinions and interests reflected in the resulting design. 4. The evaluation challenge How can we test the validity of our design decisions and evaluate the usability and usefulness of interactive systems before they are implemented and deployed? According to research by Forrester, usability testing was conducted on only 24% of large web sites. For Jacob Nielsen this means that 3 out of 4 large sites are essentially poking blindly into the design space. No control, no conclusion. Even design gurus don't know whether they've done a good job until they do the ultimate reality check: let a user use the system. Too often this reality check only occurs after the product has been deployed, sometimes with dramatic results. Of course you want to know sooner whether your system matches the user's expectations and demands. In fact, you prefer to know before you even make expensive implementation investments. One way of doing that is to develop user interface mockups and let users work with them as if they were the real thing.

Read more about Sim's current activities: Copywriting by Kwintessens | Information architecture by Kwintessens (in Dutch)