Chapter 3 Fundamentals of Corporate User Interface Specification
3.3. Bridging the Gaps for Model-Based Semi-Formal Specification
3.3.1 Integrating Interaction Design and Software Engineering
As discussed in Chapter 2, software engineers are generally trained in topics such as system architecture or database design, while interaction designers are concerned with ease of use, ease of learning, user performance, user satisfaction and aesthetics, for example. An interaction designer normally has a black-box view of the back-end system, while the software engineer has a deeper understanding of the architecture and code behind the UI (Campos 2004). SE considers how functional requirements are translated into a running system. Although both disciplines have reached a cer-tain degree of maturity, they are still practiced very independently (Pyla et al. 2003).
Consequently, software developers and interaction designers, end-users and business Differences of disciplines
ability to be primarily a property of the presentation of information, i.e. of the UI (Hix & Hartson 1993). A result of this assumption is that UI design is often post-poned until the later stages of development. (Folmer & Bosch 2004) identify two risks with this approach:
Assumptions may be built into the design of the architecture that may unwit-tingly affect the UI design.
Assumptions may be built into the UI that are not supported by the architec-ture, for example interaction issues (such as support for a wizard or an undo), information architecture issues (such as a separation of data from presenta-tion), and interface issues (such as visual consistency).
Software quality attributes such as performance or reliability are to a considerable extent defined by the software architecture. The software architecture also has a ma-jor impact on the interaction and information architecture. Designing a usable sys-tem is therefore more than simply ensuring a usable UI. On the one hand, a slow and buggy system architecture with a good UI is not considered usable. On the other hand, the most reliable and well-performing system architecture is not usable if the user cannot understand how to use the system. Designing a well-performing, reliable and flexible architecture that can support unforeseen usability requirements is quite a challenge. Software architecture is an important instrument for reaching high UI quality. In raising the awareness of this relationship, software engineers and interac-tion designers must recognize the need for a closer integrainterac-tion of practices and tech-niques (Folmer & Bosch 2005 ).
However, the behaviour of the system and the feel of the UI are very much de-pendent on each other. The more important the UI component becomes for a soft-ware application, the more significant is its impact on the back-end system. Hence, SE and IxD need to overlap at the interaction layer in order to develop usable sys-tems. If the collaboration at the interaction layer is well defined and working suc-cessfully, the time-to-market can be dramatically shortened by (having) well defined interaction points at which the teams can re-sync and communicate (Gunaratne et al.
2004). A better balancing of the different views of the system, and hence better us-ability, is achieved when software is designed in multi disciplinary teams (Folmer &
Bosch 2005 ). The specification methods and process employed have to take this into account accordingly.
As there is a need for both professions to talk the same language, both disciplines need to agree on how to describe components of the UI. Several conference work-shops highlighted major integration issues, which are summarized in Table 10. For each integration issue indicated by (Seffah et al. 2005b), we suggest methods of ap-plication in a cross-discipline engineering process.
Table 10: Integration issues for SE and UE, partly based on (Seffah et al. 2005b)
Integration issue (Seffah et al. 2005b) Method of application Mediate and improve the communication lines between
us-ers, usability experts and developers Use medium-weight artefacts, work with toolkits ap-propriate for collaborative design with all actors Extend artefacts for UI specification and conceptualization Use models known by both professions and adjust
their expressiveness
Enhance object-oriented SE notations and models Use interoperable notations understood by all actors Extend RE methods for collecting information about users
and usability Include principles, practice and adequate methods
from HCI into RE up-front.
Develop new processes for interactive systems design Reconsider methods, keeping in mind shorter time-to-market and business demands
Represent design artefacts including prototypes using
dif-ferent formalisms Enable all actors to model and test the UI without
cod-ing and too much need for formalism Convey user-centred design attitudes, not just tools and
methods, to support user-centred design activities Integrate tools that support all professions by trans-porting patterns, design knowledge, design principles
Software architecture and the UI
Interdependent parts of a whole
Integration issues
Very formal or complex models are an inappropriate base for communication, especially so for collaborative design processes with high user- and business-stakeholder participation. As an interdisciplinary modelling language for require-ments gathering, research suggests scenarios (Jarke 1999; Rosson & Carroll 2002;
Seffah et al. 2005a; Sutcliffe 2005) - known as user stories (light-weight scenarios) in agile development (Beck 1999) - and prototypes (Sutcliffe 2005) as bridging techniques for IxD, and SE. Choosing the right models in an interdisciplinary con-text is crucial to avoid misunderstandings (Constantine et al. 2003).
In SE, scenarios - as a sequence of events triggered by the user - are generally used for requirements gathering and for model checking. Such a use-case scenario is used to identify a thread of usage for the system to be constructed and provide a de-scription of how the system will be used (Pressman 1992). In contrast, IxD applies scenarios to describe software context, users, user roles, tasks and interaction (Ros-son & Carroll 2002). In all, scenarios can be used as a vision of the system by ex-plaining functionality and interactive behaviour, as well as being a description of us-ers and their tasks, as outlined in Chapter 4. Scenarios can support the design process and are well established in both disciplines. They can therefore form the common ground between the disciplines (Sutcliffe 2005).
Prototypes are also applied by both disciplines, although their role in SE was less important until agile approaches refocused attention on them as vehicles for inspec-tions and testing. Prototypes in SE can also be used to verify functional specifica-tions and models as well as for understanding problems by doing user inspecspecifica-tions.
Agile Modelling (AM) already recognizes prototypes as a type of small release, which can be continuously changed and fine-tuned (Blomkvist 2005). In SE, how-ever, prototypes are often used to assess whether requirements are adequately ad-dressed and satisfied. With regards to UI design, this can be especially problematic.
Just because a design idea satisfies a requirement does not necessarily mean that it does it the best way possible (Lim et al. 2008). There might be design alternatives that do so, but they might be missed if the team decides on a preliminarily design just based on very strict rules of fulfilment. IxD mainly recognizes them as an arte-fact for iterative UI design and distinguishes different dimensions of prototypes (Rudd et al. 1996). Here, prototypes are used to explore design spaces, including all possible design alternatives and the associated trade-offs. In spite of these differ-ences, prototypes are clearly one of the most compatible links between SE and UE.
Just as with prototyping and scenarios as common vehicles, IxD and (agile) SE can converge on other shared principles and practices by using more methods famil-iar to both professions and by speaking the same language. Faced with the demands of corporate project environments, a reliance on heavyweight methods such as for-mal models (SE), or massive documentation such as style guides (IxD) is far too ex-pensive for the design of interactive products. After all, greater cost-effectiveness and flexibility were among the main arguments for lighter, agile methods. The bot-tom line is that some informal methods of agile development are close to IxD prac-tice and are therefore the pathfinder for a common course of action.
We therefore believe that cross-discipline agile methods are the optimum, and workable, compromise. As agile approaches already exist in both SE (Beck 1999;
Cockburn 2001) and IxD (Constantine 1996; Constantine & Lockwood 1999a; Con-stantine & Lockwood 1999b; ConCon-stantine et al. 2003; ConCon-stantine & Lockwood 2003; Gundelsweiler et al. 2004; Memmel et al. 2007e; Memmel et al. 2007d;
Memmel et al. 2007f; Memmel et al. 2008a), they can be the interface for a common and balanced software lifecycle (Blomkvist 2005). Prototypes can include and con-vey the attitudes of both IxD and SE. Agile models can usually be generated and changed quickly, but still be sufficiently detailed to act as a medium of communica-Interdisciplinary modelling
methods begin coding at a very early stage while having a shorter up-front RE phase and less documentation. Following the paradigm of XP, implementation of code takes place in small increments and iterations, and the customer is supplied with small releases after each development cycle. During a short requirement analysis known as the exploration phase, the development team writes user stories in an at-tempt to describe user needs and roles; the people interviewed need not necessarily be the real users of the eventual software product. (Gundelsweiler et al. 2004;
Memmel et al. 2007e) explained that XP therefore often fails to collect real user data and starts coding based only on assumptions about user needs. Agile methods are less rigid than XP and take more care over initial requirements-gathering as they provide room for low-fidelity (essential) prototyping, activity diagrams or use-case diagrams (Cockburn 2001; Ambler & Jeffries 2002). Nevertheless, the analysis phase is finished as soon as requirements have been declared on a horizontal level, because the iterative process assumes that missing information will be filled in at later stages. Development in small increments may work properly as long as the software is not focused on the UI. When designing UIs, continual changes to the UI due to fast iterative design may give rise to conflicts with user expectations and learnability, cause inconsistency and finally lead to user dissatisfaction (Constantine 2004). Evaluation of small releases with stakeholder participation does not ensure that the whole system provides a consistent conceptual, navigational or content model (Gundelsweiler et al. 2004).
The discussions about agile approaches to UI design led to a movement in the IxD community, which began to reconsider its user-centred heavyweight lifecycles (Constantine & Lockwood 1999b; Gellner & Forbrig 2003; Holzinger & Slany 2006; Memmel et al. 2007e). Both SE and IxD have to cope with a shorter time-to-market, in which the quality of the delivered software must not suffer. The continu-ous shortening of development lifecycles is therefore a great challenge both for management and the methods and tools applied. Many experts, who are likely to have a home in both SE and IxD, consequently faced up to the issue by developing approaches to light-weight or so called agile human-computer interaction, e.g. eX-treme usability (Holzinger & Slany 2006).
What is required is a balanced hybrid process, which must be consistent with the principles and practices of both IxD and SE (Blomkvist 2005). In order to identify interfaces between agile SE and IxD, different approaches to UI design have to be discussed in respect of their agile potential and their different contributions to a cross-discipline process (see Table 11). The chosen UI specification approach must, however, be able to produce the quality of the UI and the software product as a whole as required (see Chapter 2).
Like XP, original user-centred design is a highly iterative process. It differs from agile methods, however, since real users are taken into account and the development team tries to understand user needs and tasks before any line of code is written. The lifecycles of UE processes such as Scenario-Based UE (Rosson & Carroll 2002) or the UE Lifecycle (Mayhew 1999) provide numerous methods and tools that should support the designer in gathering all of the required information. Most of these methods are rated as heavyweight, due to their claim to analyze and document as much as possible about users, workflows, context, etc. right from the beginning.
(Constantine 2004) argues that user-centred design produces design ideas and visual prototypes out of the assembled requirements data by a rather magical process in which the transformation from claims to design is neither comprehensible nor traceable. Such a black-box designer produces creative solutions without being able to explain or illustrate what goes on in the process. Furthermore, user-centred design tries to make the resulting, often diverse, design alternatives converge into a single solution, which is then continuously evaluated and refined. User-centred design may therefore take a long time, or even fail, if too many users are involved and narrow-ing the design space is difficult. Iteration may create the illusion of progress, al-though the design actually goes round in circles and solutions remain elusive. On the whole, a one-to-one integration of user-centred design processes and methods is, in general, inappropriate for an agile course of action.
Considering the weight of IxD
Table 11: Comparison of design approaches, adapted from (Constantine 2002); presented in (Memmel et al. 2007e)
User-Centred Design Usage-Centred Design Activity-Centred Design Thoughtful IxD Focus is on users: user
ex-perience and user satisfac-tion
Focus is on usage:
sup-porting task goals Focus is on activities Focus is set by designer, dependent on project situa-tion
Driven by user input Driven by models Driven by activities Driven by UI designer Substantial user
involve-ment Selective user involvement Authoritative user
in-volvement Thoughtful user
proto-typing Design by modelling &
abstract prototyping Design by understanding
activities Design by switching btw.
abstract and detail Very varied, informal, or
black-box process Systematic, fully specified
white-box process Unspecified, rule-breaking
black-box process Depends on guidance and authority
Design by trial-and-error Design by engineering Design by authority Design by visual thinking Constantine suggests a concentration on tasks instead of on users and presents methods for an adequate requirements analysis. His usage-centred design approach takes up the basic philosophy of AM and concentrates on essential and easy to un-derstand semi-formal models such as the role model, task model or content model.
With the application of these medium-weight (agile) methods IxD becomes more formal, but the simplicity of their syntax still enables collaborative design with stakeholders. The models of usage-centred design can be applied by both IxD and SE personnel. Their thoughtful and common application can be an effective com-mitment to a UI design by engineering rather than by trial and error (Constantine 2004). Constantine also suggests prototypes as a tool for requirements elicitation, but argues that filling in detail too early often leads to premature decisions. He rec-ommends abstract prototypes (Constantine 1998), which can be associated with low-fidelity prototyping.
Although the list of success stories for usage-centred design is creditable, the products praised tend to support user performance rather than user experience. Fol-lowing usage-centred design, the project can be considered as successful when users are able to achieve their task goals. This cannot be the only aspiration of a modern design approach, however. For a modern cross-discipline software lifecycle, IxD must take into account more topics than user performance alone.
This is where Donald Norman's recently proposed activity-centred design ap-proach (Norman 2005) comes in. Like Constantine, he argues that by concentrating on the user instead of on his tasks, user-centred design may be misleading and a time-consuming detour. But he also argues that task-completion time is probably not always the silver-bullet factor that causes software to be successful. Products caus-ing a high joy of use can attain great user acceptance even when they lack usability.
Norman therefore votes for the integration of emotional design issues and the stronger consideration of user satisfaction. Based on findings in the agile-usability group, Constantine is currently reworking his usage-centred design approach and is discussing the issue with Donald Norman:
Usage-centred design
User performance vs. user experi-ence
Activity-centred design
tive image and specification. If the designer is confronted with a design situation, an often sketchy and diffuse vision initially emerges. Frequently, several visions are promising and therefore compete to be implemented, eventually resulting in a chaos of conflicting visions. The initial version of the operative image is the first externali-zation of the vision, e.g. captured in mock-ups or elaborated interactive (high-fidelity) prototypes. It enables manipulation, stimulation, visualization and decision-making for the most promising design. The operative image is eventually trans-formed into a specification for the final design if it is sufficiently detailed. In con-trast to user-centred design or usage-centred design, (Löwgren & Stolterman 2004) describe design as neither a linear nor an iterative process. They identify no clear di-vision between design and construction, but rather a continuous interaction between vision, operative image and specification. The designer wants to learn as much about the design space as possible, keeping the number of possible solutions high and nar-rowing the design towards the best solution as late as possible.
Taking into account the concepts of the approaches to UI design that have been discussed, a clear tendency towards an increase in the importance of user experience can be identified. Classic user-centred processes are no longer capable of covering all aspects of UI development in modern interactive systems design. The following cornerstones for specifying interactive UIs can be deduced from the discussion of UI design approaches:
Focus. The focus is on both user performance and user experience. The proc-ess of UI specification therefore has to incorporate means that are able to take both aspects into account in equal measure.
Modelling. Some degree of (semi-)formality, such as in the model-based us-age-centred design approach, helps to turn UI specification into a transparent process. By an engineering-like approach to UI specification, the translation process from specific artefacts, i.e. models, into visual externalizations, i.e. UI prototypes, becomes more controllable.
Design. The informality of user-centred design continues to be important in terms of visual thinking and participatory design. UI prototyping in particular is therefore the right means for communicating with stakeholders that are not on the design team. Prototypes drive the UI specification process by forcing stakeholders to become more objective and look at the consequences of their modelled requirements.
Control: User experience is developed through a rule-breaking emotional de-sign process and requires thoughtful and experienced interaction dede-signers in control of the overall process. They are in charge of switching between user-input (user-centeredness), modelling (usage-centeredness) or authoritative de-cision-making.
The key aspects identified for UI specification now need to be structured in a way that makes sure that all important and relevant issues that determine usability and user experience are covered.
“The user-experience development process is all about ensuring that no aspect of the user‟s experience with your site happens without your conscious, explicit intent.
This means taking into account every possibility of every action the user is likely to take and understanding the user‟s expectations at every step of the way through that process. It sounds like a big job, and in some ways it is. But by breaking the job of
This means taking into account every possibility of every action the user is likely to take and understanding the user‟s expectations at every step of the way through that process. It sounds like a big job, and in some ways it is. But by breaking the job of