Toward a New Development Process by Dave Cronin
As an interaction designer, I spend considerable time and energy figuring out the best way to integrate the process of software design with the process of software construction. I advocate approaching design and construction as separate activities, with design being the one that occurs first.
About Interaction Design
Interaction design is the process of defining product behavior based on observed and analyzed user behavior. Interaction design methodologies such as Goal-Directed Design rely heavily on qualitative user research to create models of users, known as personas, that serve as design targets. The interaction designer creates scenarios, starring those personas, to drive needs and feature requirements. Next, the interaction designer applies design principles and design patterns to this list of user needs in order to create an interface structure that behaves in ways that are easy for the target users to learn and that provides them with appropriate power. Last, the interaction designer populates the structure with the specific layout of screens, tools, and widgets that users will use to get their work
(or play) done. Interaction designers document the design specification for developers, who use it as a blueprint during the construction phase.
About the Rational Unified Process® (RUP)
The Rational Unified Process® (RUP) is a rigorous and disciplined approach to the design and construction of software. I u se the term “design” to describe the activities related to the form and behavior of the product as experienced by the user. I use the term “construction” to describe the activities related to building the system and its internal mechanisms in its final form.
RUP is a productized process developed (and sold) by Rational Software, which is now a division of
IBM. RUP consists of a process, tools, and best practices designed to help development organizations achieve quality, predictability, efficiency, and productivity in the scary world of large and complex software projects. (For a good introduction to RUP, see http://www.rational.com/products/whitepapers/100420.jsp). I’ll talk more about the specific phases of
RUP at the end of the article and show where interaction design integrates with those phases and complements them.
Because RUP is rigorous and serves to bridge the gap between product- and requirements-definition
(i.e. design) and construction, there are some overlaps and apparent discontinuities between RUP and the Goal-Directed Design process (GDD). I find, however, that these discontinuities are not insurmountable and that there is potential for synergy between the two processes. In fact, I believe that the best way for development organizations to capitalize on the rigor of RUP is to marry it to Goal-
Directed interaction design methods.
Requirements
One of the most important aspects of RUP, in relation to the design of software, is its goal of managing and making sense of complex sets of product requirements. Developers the world over routinely get the short end of the stick when new requirements are “discovered” after a code freeze. An oft-cited study claims that of 8,000 large software projects, 40% of requirements arrived after development began. (Jones)
The way RUP (and other “agile” development philosophies) deals with this disturbing fact is to accept it (however unfortunate it may be) and to optimize development practices around managing and responding to change. This is an understandable approach, and makes a lot of sense when you think about what the development team has to work with, but I also think the attitude is defeatist. It is little different than throwing out your roadmaps before your cross-count ry trip because there’s really no telling how many flat tires, rain storms, and rude drivers you may encounter along the way.

Having determined requirements for a good number of large, complex software projects, I will assert that it isn’t impossible to determine product requirements up front. Rather, experience tells us that there is a hierarchy in the granularity of requirements and that while it is very difficult to define and catalog every low-level requirement (e.g. fields, attributes, parameters) before iterating the design, it is quite possible (and in fact preferable) to define the top-level functional requirements of a product at the outset of the design/construction process.
One problem in effectively defining high-level requirements up front is that many development organizations understand requirements as something to be “gathered.” This “gathering” activity often manifests itself as customers and users volleying “requirements” emails and phone calls to the help desk, salespeople, and engineers. Often, these are then translated into line items in requirements documents. There is little thought given to reconciling requirements from different sources, and this reconciliation is often done at construction time, which can have all sorts of dire consequences, ranging from confused developers (who rarely have enough information to make educated choices between two apparently reasonable requests) to a confused interface (that is not grounded in a coherent and cohesive product definition) to confused users (who wonder why a function they never use is front-and-center on the screen).
Goal-Directed Design calls on interaction designers to observe and talk to customers and users with the intent of understanding not only their “requirements” (what they think the product must do to make them happy), but also their motivations and workflow context. From these latter two, we are often able to imagine solutions to user problems that they never dreamed of. We often liken gathering functional requirements directly from users and customers to doctors gathering diagnoses and treatments directly from patients, rather than using their professional judgment to assess symptoms.
Use Cases and Scenarios
A common reference point between GDD and RUP is their reliance on scenarios, or Use Cases, to define the structure of the product.
In GDD, once the interaction designers have completed customer and user research, they synthesize their findings by identifying patterns, which they then distill into personas (archetypal users) and scenarios of personas using the product to achieve their goals. From these scenarios, we are able to define high-level product requirements and a cohesive product definition and interaction framework.
The Rational Unified Process® utilizes Use Cases in a similar manner. RUP defines a Use Case as “a sequence of actions a system performs that yields a valuable result for a particular actor.” These Use
Cases serve to determine functional requirements, to create and validate the design, and to create test plans and user documentation in ways similar to GoalDirected Design’s use of scenarios.
(“Introduction to Rational Unified Process”)
Despite the similarities between scenarios and Use Cases, differences arise as to whether top-level requirements can be determined without iteration. These differences can be resolved by examining the methods used to create them.
According to RUP, Use Cases come from customers and users, and subsequently require prototyping, iteration (of code), and repeated customer/user involvement to validate, reconcile, and consolidate the
Use Cases and the software defined by the Use Case. This process is predicated on the assumption that it is impossible to make sense of requirements until you’ve written some code and put it in front of users and customers, because there’s really no anticipating or accounting for what people will actually want.
Alternatively, GDD holds that anticipating and serving human needs can be achieved in advance, using personas and scenarios. By determining motivations (rather than simply tasks), we can anticipate and proactively serve needs and requirements our users and customers can’t yet identify.
This stems the flow of requirements delivered after design is completed. Also, GDD reconciles our diverse research findings by creating personas and scenarios to embody the patterns we observe in the field. These personas and scenarios serve as our evaluation criteria while we evolve and iterate the design (on paper).

Iteration
According to RUP, an iterative approach allows for an increasing understanding of the problem through successive refinements and incrementally grows an effective solution over multiple iterations. I couldn’t agree more with the objective implied here; however, in the name of successfully coordinating
RUP and GDD, there are a number of differences worth exploring with respect to iteration. (“Rational
Unified Process”)
RUP advocates iteration as a method to incorporate requirements that arrive after construction has begun. GDD, however, greatly ameliorates this need with specific methods of research and synthesis.
Also, and more importantly, RUP advocates iteration as a construction methodology that reduces risks that arise from a single development push. Put simply, when developing complex software, it is preferable to integrate and test on a regular basis to assess the soundness and fitness of the code, and to make fixes and modifications on a regular basis, rather than at the end of construction. This makes perfect sense, but this part of the iterative process is beyond the concern of interaction design methods.
There is a difference between RUP and GDD when it comes to the implementation of iteration. Both
RUP and GDD recommend iterating on high-level functional elements before getting down to nuts and bolts. RUP refers to this as the Elaboration phase. GDD, on the other hand, breaks this down into two steps: Requirements Definition and Framework Definition. While it’s beyond the scope of this article to discuss this matter indepth, it’s worth noting that in GDD it is crucial to first identify the needs the product must serve and then to identify the appropriate functional elements that satisfy these needs.
This is how interaction designers are able to create breakthrough solutions that anticipate the needs of your users and customers before they are able to articulate them.
The primary difference between iteration in RUP and iteration in GDD, in regard to defining high-level product functionality, is that GDD advocates that iteration occur on whiteboards, paper, and in bitmaps, whereas RUP advocates iteration through working prototypes. While iterating with a prototype can effectively serve to provide proof-of-concept for implementing functional elements and can result in a more stable code base through evolutionary iteration, my experience has shown that a working prototype is significantly expensive and has the highly undesirable effect of creating inertia in design activities. Despite the “agile” label given to iterative development processes, it is extremely difficult to rewrite, eliminate, or otherwise get over already-written and functioning code. Because there is a cost associated with functioning code in human resources and because it represents a portion of allocated budget, it is often perceived to have value, even if it doesn't adequately serve the needs of users or customers . Not only is this code not an asset, it is a liability, and it stands between you and a product that provides value to your customers.
GDD advocates performing the first several iterations on whiteboards and the next several iterations in bitmaps with accompanying text describing human interactions and software state changes. Changes to this kind of “prototype” are relatively inexpensive and can be performed rapidly and frequently. It is possible to get good feedback to designs articulated on paper, and, most importantly, these prototypes are concerned with the aspects of your product that touch your users and customers. Once the interaction designer has iterated to determine the ideal user experience for a product, it becomes appropriate to iteratively implement the design so that it best achieves this ideal experience.
My goal in exploring the di fferences between the Rational Unified Process® and Goal-Directed Design is not to suggest that software developers must choose between the two, but rather to point out that these differences are the critical inflection points in integrating the processes with the end goal of efficiently creating software products that satisfy user needs and provide value to customers.

RUP consists of four major phases: Inception, Elaboration, Construction, and Transition. I’ll talk about the first three phases and describe where integrating Goal-Directed design methods makes sense and strengthens the process.
Inception
The Inception phase is concerned with the business case for the project, the scope of the project, and initial definition of Use Cases and requirements. This phase of the process is primarily the responsibility of business decision-makers and can be thought of as the development of a hypothesis regarding a specific opportunity in the marketplace.
Similarly in GDD, interaction designers work with business decision-makers and other stakeholders to help articulate and consolidate the hypothesis or vision that is driving the inception of the project.
Elaboration
In RUP, the bulk of upfront, proactive design work occurs in the Elaboration phase, where the problem domain is analyzed, Use Cases are identified and fleshed-out, high-level requirements are defined, and system architecture is determined and prototyped. Here is where interaction designers working according to GDD methods would perform user and customer research, analyze research findings, define personas (similar to Actors in RUP) and scenarios (similar to Use Cases in RUP), determine high-level functional requirements, and design an interaction framework that would inform the architectural model and prototype.
It is worth noting that GDD research is primarily concerned with user-experience related information, and there is typically a need for additional research and analysis on the part of the engineering team to determine technical requirements (related to compatibility, interoperability, platforms, protocols, load, etc.) that will also inform the development of the architectural model.
Enhancing the normal RUP process with GDD would result in an additional and highly valuable outcome to the Elaboration phase —the definition of the Interaction Framework. The Interaction
Framework is a visual and textual description of major interactions and flows, illustrating how the proposed requirements and design satisfy the identified Use Cases. This helps ensure that the interaction designers have accounted for all high-level product requirements in a meaningful, cohesive, and compelling manner before spending time and effort working out all low-level details.
Construction
In RUP the Construction phase is primarily concerned with the development of the software; however, this phase is also where low-level requirements are defined. Here, through iteration of scenarios, interaction designers are able to define and design these details in order to usefully and coherently combine them to satisfy the needs of users and customers, as embodied in the personas. While working in bitmaps and on paper, it is possible to elicit and quickly respond to feedback while maintaining the integrity of the design vision and Interaction Framework.
Once lowlevel requirements are worked out to sufficient detail, it becomes the development team’s responsibility to code and iterate until the product is complete. Interaction designers should be involved on an ad hoc consulting basis later in the Construction phase to account for and incorporate new feedback and modifications to the design that arise from the development process.
The Rational Unified Process® and Goal-Directed Design are both time- and battle-tested tools designed to ensure success and predictability in large and complex development efforts. GDD’s strengths lie in its ability to define requirements upfront and to envision and develop a user experience that results in a successful product, whereas RUP’s strengths lie in its ability to manage risk and unpredictability in the construction and deployment of large, complex projects. These goals and strengths are highly complementary, and while there is clearly more discussion and work to be done around the integration and interoperation of the two methods, the result has the potential to be the rigorous, holistic process for which the increasingly complex world of large software projects has been begging.