Interface Analysis Realisation
What
A tool for the developer to transfer the User Interface Analysis documents to a detailed interface description for the implementation.
The Interface Analysis is divided into two parts: User Interface Analysis and System Interface Analysis.
How 'User Interface Analysis'
The dish
The User Interface description
Ingredients
- Results from Behavioural Analysis
- Results from Use Case Analysis
- Results from the Functions Analysis
- Storytelling
- Other artefacts produced
Process
The following guidelines should be used when implementing the user interface. Often, it is not possible to follow all the guidelines due to project time and money. However, try to include as many as possible.
The main focus should be on the user. Information about the user will help you choose the guidelines.
- Keep it simple - less is more
- Do not give the user fancy features; the idea is to minimise the user interface task. Only show the operational features which are relevant in the specific situation.
- User feedback and systems status
- The user should receive an immediate response (<50 ms), and status information should be kept up to date. If hardware buttons are used, there should be a tactile feedback, whereas software buttons could be accompanied by a sound.
- User control
- Never take the control from the user. The user should never be a slave of the system; in other words, the user should feel secure and in control all the time.
- User flexibility
- If the system should be operated by both expert users and less experienced users, the expert user must have a way to speed up the interaction..
- Consistency
- The user feels secure, if the same operation principles are used no matter where in the system the user operates.
- Analogue thinking
- In the software world, everything is possible, including aspects which are not feasible in the real world. This might confuse the user who thinks in an analogue way. Interaction should only take place, if it can be done in the real world.
- Error prevention and forgiving interfaces (reversible actions)
- Design the user interface in such a way that errors do not occur, and always provide the user with a back/cancel option. Never force the user to make a damaging decision, when s/he only wants to leave quietly.
A good idea would be to conduct iterations of usability tests with real users. Given the fact that a user interface is the visible interface between the user and the system, keep an aesthetic design.
How 'System Interface Analysis'
The dish
Refinement of the System Interface description
Ingredients
- Block or module diagrams
- Sequence diagrams
- Communication diagrams
Process
When it has been decided which parts of the system-to-be to work on for the current iteration, it is time to refine the description of the interfaces for the external systems communicating with these parts. Here is a list of examples of things to consider:
- If, for instance, the system communicates through a relational database, construction of a more detailed model of the database is needed: specifying tables, columns, datatypes, foreign keys, etc.
- If it is decided that the system-to-be will connect to some server on the internet, the protocol needed for the communication shall be specified either by defining it or by referring to standards. A Sequence Diagram is a good tool to illustrate the dialogue with another system.
- If sharing a resource with another system is in question, potential concurrency problems must be addressed in order to avoid race conditions.
- If it is not possible to refer to a public recognised standard (e.g. Ethernet, IEEE 802.11g, etc.), describe electrical interfaces.
Why
From the User Interface Analysis in the Launch Phase, there exists a rough picture of the user interface, i.e. the visible interface between the user and the system. A prototype of the user interface may also be available, and knowledge of what kind of user interface elements (displays, buttons, microphone, loudspeakers, web-interfaces, etc.) are required by the user.
In order to implement the user interface, a more detailed description of the specific displays, buttons or web-interfaces the system should implement, is needed. Hence, detailed specifications should be written.
It is essential that all the effort conducted in this task focuses on the user. A Danish psychologist once said that the user interface could be perceived as a piece of glass between the user and the system. If the glass is completely clean, the user can obtain full use of the system without really thinking of the process taking place. But if the glass is dirty or scratched, "noise" in the user interface arises, leading the user's attention to the glass and not to the system.
Often industrial products are made in such a way that the functionality has been hidden from the user due to a poor user interface; in fact, 80% of all functionality in consumer products are never used. The worst case scenario is that functions and even systems are not used due to a poor user interface.
Therefore, it is of vital importance that the user interface descriptions are prepared, and prepared in a way that makes the system transparent for the user. Thereby, a strong incentive for the user to use the system is created.
For Systems Interfaces it is essential to specify the interface, the electrical characteristics, and the protocols, the logical commands and data formats, used while exchanging information.
