 |
|
|
Design Tidbits
Design Tools
- My Design Tools – Part I
- My Design Tools – Part II
- UI Toolbox: Capturing and Editing Screenshots – Part I
- UI Toolbox: Capturing and Editing Screenshots – Part II
Simplification
- What Does "Simple" Mean?
- Anti-Simplification – How to Make Life Harder for Users
- Reducing Complexity
- Error Prevention Comes First
- Don't Let Your Interface Lie
- Don't Let Users Suffer from System Weaknesses
Interaction Design
- Did You Make Your Selection? – Part I
- Did You Make Your Selection? – Part II
- Did You Make Your Selection? – Part III
- Did You Make Your Selection? – Part IV
- The Software Works The Way I Think: Beyond Point and Click
- A Layman's View on Interaction Styles – Part I
- A Layman's View on Interaction Styles – Part II
- Selecting Objects By Attributes – Part I new
- Selecting Objects By Attributes – Part II new
Screen Design
- The Art of Hiding – Part I
- The Art of Hiding – Part II
- Screen Layout – Part I: General Considerations
- Screen Layout – Part II: Layout Hierarchy
- Screen Layout – Part III: Examples
Hierarchies
- Hierarchies - Categories vs. Vectors
- Fighting
(with) Hierarchies –
Part I: Basics - Fighting
(with) Hierarchies –
Part II: Presentation - Appendix: Fighting (with) Hierarchies – Presentation Techniques I
- Appendix: Fighting (with) Hierarchies – Presentation Techniques II
Visual Design
- Some Color Mysteries
- Some Mysteries of Colored Text
- Animation – The Chili Pepper of the Web
- Appendix: Definitions of the Most Common Types of Animation on the Web
Design Process
- The Construction Cycle – Another Way to "Organize" the Design Process
- User Feedback
- What Does User Integration Mean for Software Design?
- Mapping a Conceptual Interface to a Physical Interface
Web, Web Applications, Web Design
- The Web – A Short Introduction
- An Introduction to Designing User Interface Controls at SAP
- From Dropdown Listboxes to Comboboxes
- List Box Tweaks (Part II)
- Concept Statements and Website Messages – Part I
- Concept Statements and Website Messages – Part II
Miscellany
- Adding Value to Your Interface by Using Simple Math and Matching
- How Much Documentation Do Applications Need? – A Simple Example
- Narrative User Interfaces
- Golden Rules
for Bad User Interfaces
- Universal Usability
- User Interface Controls and Interaction Techniques of Horror new
Links & More
 |
Print version |
Related Links |
|
 |
What is an Application Design? |
|
User Feedback |
|
What Does User Integration Mean for Software Design? |
Background Links |
|
|
SAP's Design Process (offers links to the design process stages) |
The Construction Cycle – Another Way to "Organize" the Design Process
By Gerd Waloszek, SAP AG, Product Design Center – from the original SAP Design Guild, updated 10/08/2003
The Resources section of the SAP Design Guild Website provides all the resources needed to develop user-centered applications for the SAP software world. This article takes a look at the phases of the software design cycle and how they relate to the different parts of the Resources section. I will point out that these phases are better conceived of as "views" that user interface designers can take on throughout the design process and that these views are closely interconnected. In the end, I emphasize the importance of scenarios and prototypical users as a "correcting" element that can be used all along the development process to ensure that the design is still "on track."
The Construction Cycle vs. the "Four Views"
The Resources section of the SAP Design Guild provides the resources and guidelines for a user-centered design process – both for the visual and the interaction design. The information in this section can be organized following the typical "construction cycle" of software design:
Figure 1: The four phases of the software development cycle act as organizers of the Resources section
The cycle starts with analyzing the task and the users and specifying the requirements for the software. The next phase establishes the design based on the data collected during the analysis phase. Thus, the design phase creates the "plan" for the construction of the software, while the implementation phase "materializes" this plan into real software. The cycle closes with verifying whether the software comes up to the specification and whether it fulfills its goals with respect to the task requirements and the users' needs.
However, the idea of a cycle or a sequence of phases is misleading. I use the cycle and its phases as an organizing means, because these and their implications are well known to user interface designers and developers; I do not propose it as a model for "real" software development. The circle might imply that one phase strictly follows the other without any interaction between the phases – like in the classical "waterfall" model of software design. But software design is a highly interactive process, which undergoes many iterations and loops: It resembles more a helicoid (squiggle) than a cycle. Others also call it the "spiral" model of software design.
Figure 2: A more realistic model of the software development process – the helicoid (squiggle); to the right figure shows the worse case where you have to go back several steps
Feedback from user tests and workshops as well as technical requirements and restrictions may call for revisions of the design or the code. They require user interface designers and developers to step back and start over – hopefully not from the beginning (like in figure 2 right).
While the helicoid (squiggle) is a model that more closely corresponds to the reality of software development than the cycle, I would like to propose yet another view of the cycle: Its four elements analyze, design, implement, and verify can be regarded as four different points of views or sets of "glasses" that user interface designers can take on. Thus, at one point in time a user interface designer may have the "design" glasses on and creates prototypes, at another the "verify" glasses to check whether the design ideas are valid, and at yet another the "analyze" glasses and questions whether the initial assumptions about task and users are adequate.
Figure 3: Another view of the phases – the four glasses that a user interface designer can take on
In the following, I take a short look at the four phases analyze, design, implement and verify in order to provide an overview of user-centered software development and to clarify the roles of the phases in this process. As I do not want to reiterate what can be found in the papers, cookbooks and guidelines of the Resources section, I take the perspective of viewing the software development cycle as a "construction" process.
Figure 4: User-centered design assures that users can say, "The software works the way I do!"
Analyze
Proper understanding of a software project's scope begins by defining the goals, audience, and the market or opportunities for the product. In this phase, intense brainstorming sessions, user scenarios are developed and endusers are visited in their work environments. These activities lay the foundation for the design and its implementation, that is, for the final software product. As with building houses, a solid foundation is the prerequisite for an application meeting the users' needs and fulfilling its intended goals.
Figure 5: Brainstorming is a method to clarify user roles and scenarios, that preferably should be complemented with site visits
Figure 6: Site visits provide a wealth of data not only about the use of an application itself, but also about the work environment and the communication structures within companies
The Design Process part of the Resources section comprises information that supports user interface designers in conducting site visits and brainstorming sessions for finding scenarios and user roles.
Design
Having set the goals for an application, the design phase establishes the "floor plan" for the software to be built. This plan should suffice to implement the application with respect to the most important aspects of the user interface – not every detail needs already to be specified.
The design process involves both, visual design (i.e. aesthetic renderings) and interaction design (i.e. usability design). Design, however, is not a solitary process; for quality assurance, there is a back-and-forth interaction between design and implementation.
According to the Holtzblatt methodology, the design builds on users and scenarios and starts with envisioning how an "ideal" software would solve the problem that the application is supposed to solve. These visions may be far removed from what is technically feasible, but open the mind for new ideas. Of course, such high-flying visions soon clash with reality and have to be adapted to the technical framework and restrictions within which the software is to be developed. This may be disappointing for the team, but technical restrictions can be overcome and are no excuse for software that is hard to use and does not meet the users' needs. Any technology allows to adapt software to its users and their tasks, even though one technology may allow for a more elegant solution than another.
Figure 7: Team meetings are the stage for developing visions, "floor plans", and prototypes
Like an architect who creates a "floor plan" from the needs, wishes and visions of its customers, user interface designers in conjunction with development teams create a "floor plan" for the user interface. Prototypes, especially paper prototypes, bring the "floor plan" to life so that it can be discussed, tested with users and revised with minimal effort. As soon as the coding starts, the design will be much harder to change.
Figure 8: Building paper prototypes is a team effort
The Visual Design and Design Process parts of the Resources area comprises contributions from both visual design and interaction design. Here the more general design issues are covered. Tools and information for the detailed design and implementation are found in the parts General, Web & Portals, R/3, and Mobile & Others.
Implement
The implementation phase is the "real" construction phase – it is basically coding and results in the final product. Accurate implementation of a product involves strict attention to design guidelines. During implementation, deficiencies and errors in design and specification show up and may force the developers and user interface designers to go back to the "drawing board" and start over. In some cases they may even be forced to step back to the analysis phase and, for example, do additional site visits in order to get more data. Of course, such stepping back is costly and may delay the shipment of the product. Another reason for loops are technical restrictions that had not been considered and require a redesign of parts of the application.
Regrettably, it is unrealistic to expect that the user interface designers can hand over the "floor plan" to the developers for coding, and everything else will go smoothly and automatically. But the effort invested in the analysis and design phase pays: Far less stepping back is necessary and a higher product quality results as if no effort had been invested or if these phases were conducted carelessly. In addition, repeatedly conducting workshops and informal prototype tests with users (this method of permanent user feedback is called user day) allows for timely corrections and thus ensures that the application design and code stay "on track".
Figure 9: Implementation "solidifies" the design into lines of code
The parts General, Web & Portals, R/3, Mobile & Others, and Visual Design of the Resources section comprise all the guidelines, tools and resources for building a product that meets the requirement of the SAP visual design guidelines as well as the SAP guidelines for user interaction. Adhering to these guidelines does not ensure that an application is user-centered and comes up to the the users' needs. But it is a basis on which such applications can be built – applications that are also clearly recognizable as applications of the SAP software family and its associated "universe."
Verify
The verification phase corresponds to the "inspection" of the final product by the customers. But while there may be such a thing as a "final" inspection, people who build houses usually do their inspections during the whole construction period. Otherwise they do not feel sure that the new house will be the one they want to live in. This is the same with software development. While the phases analyze, design and implement form a fairly logical sequence of steps, that of course can be interrupted by backward loops, verification is by no means restricted to the "finals" of the development process. In every stage of the construction cycle, verification is an important instrument to ensure usability, quality of design, and the proper implementation of the design within the product. The two basic approaches to this are asking users, as is done in user days, and asking experts, as is done in usability reviews.
Figure 10: Laboratory tests are a more formal way of testing an application before its final shipment
Reuse the Scenarios!
Let me illustrate this point in order to emphasize the importance of scenarios and users roles; you will also see that the activities of the four "views" are closely knit together.
Often, developers question the effort that has to be invested into the analysis and their typical outcomes scenarios and user roles (or personas). So, what are these good for? Scenarios and prototypical users are not just a starting point for the design, they can be reused throughout the whole development cycle. They are indeed an effective means for checking, whether the design, be it a prototype or the application itself, is "on track" and usable. Scenarios can be used for deriving typical user tasks in order to
- discuss design ideas as well as the specification with customers (for example, on user workshops)
- test early prototypes like paper or HTML prototypes with users, colleagues, consultants, etc.
- conduct lab or field tests with the final application
In our helicoid (squiggle) picture above, these events that confront the design and its implementation with users comprise the most important triggers for the "feedback loops" that form the "helicoid": Here, the views analyze, design, implement, and verify meet and can be made consistent. If done adequately, these tests allow for timely corrections, that is, short feedback loops that are not too costly. If done too late, the loops go far back, are very costly, and delay the development process. If never done, the product may be out in time, but it will be a product that is probably useless, cumbersome to use, and missing the users' needs – in short, a product that nobody wants to work with.
Figure 11: The results of lab tests or usability reviews are discussed with the development team, in order to overcome usability problems and to improve product quality
The verify part of the construction section offers papers on conducting user days as well as on reviews done by usability experts.
Conclusion
The Resources section of the SAP Design Guild provides a wealth of information for supporting a user-centered software development process. It can be organized according to the views analyze, design, implement and verify, which I discussed from the perspective of a "real" construction process. As with building a house, a good foundation and a well thought-out construction plan are the prerequisites for a product that meets the users' and customers' expectations and needs. But this does not guarantee that a useful product will emerge. It is important to repeatedly check the current design and implementation to see, whether it is still "on track" to ensure that the product is useful and fulfills its intended purpose.
Therefore, the SAP Design Guild not only provides guidelines and resources for the implementation phase, such as visual guidelines and cookbooks as well as interaction guidelines but covers all aspects of the software development process, beginning from analysis, to design methods, and continuing to the many ways how users can participate in the design process.
Addendum
Recently, I visited a conference where a user interface designer presented a similar organization of the design process, though in slightly different words: analyze, design, build, and evaluate.
