Archived Posts from January 2008
Because of the immaturity of their UI development processes, industrial clients determined on a shift of responsibility. In my research I found the following sticking points that tend to change current UI specification practice:
- Due to the strategic impact of many software products, clients want to increase their UI-related competency in order to reflect corporate values by high UI quality
- Whereas conceptual modelling, prototyping or evaluation have always been undertaken by suppliers, the client himself now wants to work in the solution space and therefore needs to develop the UI specification in-house
- The role of the supplier becomes limited to programming the final system. The client can identify a timetable advantage from this change, and an important gain in flexibility in choosing his suppliers. Having an in-house competency in UI-related topics, the client becomes more independent and can avoid costly and time-consuming iterations with external suppliers
- It is nearly impossible to specify a UI with Office-like applications. The existing actors, who are nevertheless accustomed to text-based artefacts, now require new approaches. The task of learning the required modelling languages and understanding how to apply these new tools must not be an unreasonably difficult one.
This cultural change must be supported by an integrating UI tool that allows the translation of needs into requirements and subsequently into good UI design. In the following table I present a condensed overview of relevant UI tool requirements:
|
Tool Requirement
|
Purpose/Added Value
|
|
Switching back and forth between different (levels of) models
|
Traceability of design rationale; transparency of translation of models into UI design
|
|
Smooth progression between abstract and detailed representations
|
Smooth transition from problem-space concepts to solution space
|
|
Designing different versions of a UI is easy and quick, as is making changes to it
|
HCI experts can build abstract and detailed prototypes rapidly
|
|
Concentration on a specific subset of modelling artefacts, which can be a UML-like notation or one that best leverages collaboration
|
Provide support for design assistance and creative thinking for everybody; all kinds of actors can proactively take part in the UI specification
|
|
Allowing an up-front usability evaluation of look and feel; providing feedback easily
|
The early detection of usability issues prevents costly late-cycle changes
|
My work is focused on both a set of models and a corresponding tool named INSPECTOR, still under development, which are designed to support interdisciplinary teams in gathering user needs, translating them into UI-related requirements, designing prototypes of different fidelity and linking the resulting artefacts to an interactive UI specification. Learn more at the INSPECTOR website.