23.1.1 Similarities between Lifecycles

At a high level, UX and SE share the same objectives of understanding the customer’s and users’ wants and needs, translating these needs into system requirements, designing a system to satisfy these requirements, and testing to help ensure their realization in the final product. At the process level, both lifecycles have similar stages, such as identifying needs, designing, and evaluating, even though these stages entail different philosophies and practices, as discussed in the next section.

23.1.2 Differences between Lifecycles

As often mentioned in this book, UX practitioners iterate early and frequently with design scenarios, screen sketches, paper prototypes, and low-fidelity, roughly coded software prototypes before much, if any, software is committed to the user interface. Often this frequent and early iteration is done on a small scale and scope, primarily as a means to evaluate a part of an interaction design in the context of a small number of user tasks.

UX roles evaluate interaction designs in a number of ways, including early design walkthroughs, rapid evaluation techniques, and lab-based techniques. The primary goal is to find UX problems or flaws in the interaction design so that the design can be improved iteratively.

Even though there is iteration in traditional SE development lifecycles, more so in agile approaches than in the Waterfall approach, the iteration is still on a larger scale (coarser granularity) and scope. In the Waterfall approach, iteration takes place at the granularity of lifecycle stages, such as requirements or design. In agile approaches, while there is iteration at the code-module level, it is still coarser than most kinds of UX iteration because it includes both software code and interaction design.

Another difference between these two lifecycles has to do with terminology. Even though certain terms appear in both lifecycles, they often mean different things.

For example, scenarios in SE (called “use cases” in the object-oriented design paradigm) are used to “identify a thread of usage for the system to be constructed (and) provide a description of how the system will be used” (Pressman, 2009). Whereas in UX, a design usage scenario is “a narrative or story that describes the activities of one or more persons, including information about goals, expectations, actions, and reactions (of persons)” (Rosson & Carroll, 2002).

Overall, software engineers concentrate on the system whereas usability engineers concentrate on the users.

23.2.1 Scenario 1: SE as Primary Product Architects

In an organization with a predominantly high engineering or programming locus of influence, the project is biased toward code and technology concerns. The SE role, perhaps working with business, elicits requirements from customers and envisions the product design. These requirements tend to have a functional flavor rather than a user-centered one. The SE role translates the gathered requirements into functional design, which then gets implemented in code.

The emphasis of quality is on code and other software engineering concerns such as cohesion and coupling. Because an SE role’s job performance is judged in light of these concerns, it is natural that they work toward building the best functional core they can.

The interaction design concerns are not a big priority in such an organization, and people in the SE role probably do not have much training or expertise in designing for user experience. We know of many companies where, even today, SE roles create the interaction designs for the system. Even if there are specialist UX roles in this scenario, they are often brought in near the end of the lifecycle for “fixing” the experience and “making things pretty.” The UX role is a “priest in a parachute,” brought in at the end to bless the product by suggesting some quick, and mostly cosmetic, changes because it is too late to change anything major.

UX roles in this kind of a culture are constrained by SE decisions and state of progress. Because SE roles ultimately implement the interaction designs, there is no “cultural” force to ensure that the designs by the UX roles are adopted.

Any change proposed by the UX role can require a difficult and often protracted negotiation between SE and UX roles. The UX role is required to “prove” that their suggestions are better and legitimate. This scenario can be more extreme in organizations with legacy software infrastructure.

We know of organizations where SE roles are valued higher than any other role, even to the extent of limiting career advancement options to other roles. We have seen frustrated colleagues leave organizations because their contributions were not considered an important part of the overall project effort.

In summary, the scenario of having SE roles as primary product architects suffers from an implicit conflict of interest due to the fact that something that is easy to use is almost always not easy to implement. Cooper (2004) succinctly sums up this scenario via the title of his popular book: The Inmates Are Running the Asylum.

23.2.2 Scenario 2: UX as Primary Product Architects

In an organization with a predominantly high design or user experience locus of influence, the project is biased toward users, usage, usability, and emotional impact. The UX role conducts contextual inquiry, analyzes and models the work practice, envisions an interaction design, and provides an experience for the user. This emphasis on usage-in-context ensures grounding in user concerns, goals, and aspirations, which in turn leads to a system with better usability.

As an aside, why is this scenario likely to produce a system that fosters a better user experience? Why will the outcome be any different when essentially the process is similar to that in scenario 1 where SE roles conduct requirements engineering activities with users and customers? Is not this essentially a similar activity conducted by different roles? Are UX roles better than SE roles when it comes to requirements? No. This is not about who is better. It is about each role’s innate tendencies, allegiances, foci, and training.

UX roles are naturally interested in users because they design for usage. SE roles are interested in system functionality because they implement that functionality. UX role instincts tend to be about workflows, barriers, and breakdowns in work practice, social aspects of work, and emotional impact of a system. SE role instincts tend to be about algorithms and data structures, separation of concerns among data and presentation layers, class hierarchies, and code reuse. UX roles, starting with their human–computer interaction (HCI) 101 classes, are trained in concepts such as contextual and task analysis. SE roles, starting with their SE 101 classes, are trained in requirements engineering via use-case modeling and functional decomposition.

Therefore, it is no surprise that, all other things being equal, a UX role will produce a more user-centered and user experience-oriented analysis of the work domain and what is needed in the envisioned system. Conversely, the SE role will produce a more system-centered and functionality-oriented analysis of the work domain and how it can be supported by the system.

Getting back to the scenario, the UX role, after analyzing the work practice, designs the envisioned interaction and hands it off to the SE role for implementation. In an organization like this, the designers have a free reign and usually tend to produce interaction designs that push the envelope with respect to innovation and complexity. This model puts pressure on the SE role to implement these sometimes blue-sky designs. This can become a coping scenario for SE if the technology of the target platform does not support what is needed in the UX designs or the SE role does not have the required skills or training to translate the UX designs into code.

There are two possible outcomes in this scenario: (1) the SE role works toward updating the underlying technology to support the new interaction design needs or (2) the SE role resorts to “hacking” the available infrastructure to implement the designs. Obviously the former is more advisable but requires significant effort—an unlikely option for systems with a considerable legacy code base. The latter delivers the envisioned user experience but results in a system with brittle code and maintenance challenges.

Another issue with this scenario has to do with the communication of constraints. The UX role does not know which aspects of its interaction designs are feasible and which are expensive or impossible to implement. This is because being easy to envision in a prototyping platform may not translate easily into being easy to implement in the actual target platform.

Emphasis on interaction in the prototype almost always leads to stubbing of computational functionality. The temptation is to stub the difficult parts of the computational design without first understanding their design requirements. Later, development of the stubbed functions can reveal basic problems that affect the system at many levels above the stub in question. The result is upheaval rather than a smooth progression toward an implementation.

In summary, the scenario of having UX roles as primary product architects tends to push the envelope when it comes to design, with SE playing a “support” role for the overall vision.

23.2.3 Scenario 3: SE and UX as Collaborators

It is not our intention in the previous two scenarios to take sides. We believe that both the SE team and the UX team are essential and complementary. This complementarity is the perspective of our third scenario, which occurs within organizations where the three factors of influence are about even. In an environment of collaboration between SE and UX roles—the two roles work as equal partners together and with the business role. Working together, they undertake early analysis activities. The UX roles conduct contextual inquiry and analysis while briefing the SE role periodically on findings and the emerging needs for the product. In other words, an UX role’s concerns and analyses for the user interface imply requirements for the SE role, because they have to implement the UI software component of the system. The two roles may also collaborate during this phase and conduct these activities together.

As the UX role undertakes ideation, sketching, and other early design activities, they keep the SE role updated. They ensure feasibility of their explorations and address potential constraints early on. The UX role prototypes the interaction and the SE role designs the backend. The UX role iteratively refines the interaction design via evaluation, while keeping the SE role informed of any surprises or findings with functional implications. The UX role delivers the final prototypes or other models as specification of the interaction design that the SE role implements along with the backend functionality.

This kind of an organizational environment plays to the strengths and expertise of the different roles. When there are discussions, debates, or disagreements, all opinions are heard and the final decision is left to the role responsible for that area. For example, final interaction design decisions are left to the UX role and final technology decisions to SE roles.

The implicit requirement for this scenario to work is intimate communication and coordination between SE and UX roles. We discuss this further later.

Once this kind of synchronization is established, we have known such organizations to be very productive with high throughput. These organizations tend to produce quality products—the best user experience within the technology constraints—even if they tend to be more evolutionary than revolutionary in terms of innovation.

In summary, the scenario of having UX and SE roles collaboratively driving a product direction tends to result in productive work environments, which generally produce optimal design solutions given technology constraints. However, there is no overt push to break out of existing constraints and innovate beyond normal progression of the product evolution.

23.4.1 Communication

Although SE and UX roles can successfully do much of their work independently and in parallel, because of the tight coupling between the backend and the user interface, a successful project requires that the two roles communicate so that each knows generally what the other is doing and how that might affect its own activities and work products.

The two roles cannot collaborate without communication, and the longer they work without knowing about the other’s progress and insights, the more their work is likely to diverge, and the harder it becomes to bring the two lifecycle products together at the end. Communication is important between SE and UX roles to have activity awareness about how the other group’s design is progressing, what process activity they are currently performing, what features are being focused on, what insights and concerns they have for the project, what directions they are taking, and so on.

Especially during the early requirements and design activities, each group needs to be “light on its feet” and able to inform and respond to events and activities occurring in the counterpart lifecycle. However, in many organizations, such necessary communication does not take place because the two lifecycles operate independently; that is, there is no structured development framework to facilitate communication between these two lifecycles, leaving cross-domain (especially) communication dependent on individual whim or chance.

Based on our experience, ad hoc communication processes have proven to be inadequate and often result in nasty surprises that are revealed only at the end when serious communication finally does occur. This usually happens too late in the overall process.

There is a need for a role or a system to ensure that the necessary information is being communicated to all relevant parties in the system development effort. Usually, that role is a “project manager” who keeps track of the overall status of each role, work products, and bottlenecks or constraints. For larger organizations with more complex projects, there is a need for communication systems to automate and help the project manager manage some of these responsibilities.

23.4.2 Coordination

When the two lifecycle concepts are applied in isolation, the resulting lack of understanding between the two roles, combined with an urgency to get their own work done, often leads to working without collaboration and coordination. This often results in not getting the UX needs of the system represented in the software design.

Without coordination, the two roles duplicate their efforts in UX and SE activities when they could be working together. For example, both SE and UX roles conduct separate field visits and client interviews for systems analysis and requirements gathering during the early stages of the project. Without collaboration, each project group reports its results in documentation not usually seen by people in the other lifecycle. Each uses those results to drive only their part of the system design and finally merge at the implementation stage. However, because these specifications were created without coordination and communication, when they are now considered together in detail, developers typically discover that the two design parts do not fit with one another because of large differences and incompatibilities.

Moreover, this lack of coordinated activities presents the appearance of a disjointed development team to the client. It is likely to cause confusion in the clients: “why are we being asked similar questions by two different groups from the same development team?”

Coordination will help in team building, communication, and in each lifecycle role recognizing the value, and problems, of the other, in addition to early agreement on goals and requirements. In addition, working together on early lifecycle activities is a chance for each role to learn about the value, objectives, and problems of the other.

23.4.3 Synchronization

Eventually the two lifecycle roles must synchronize the work products for implementation and testing. However, waiting until one absolutely must synchronize creates problems. Synchronization of the design work products of the two lifecycle roles is usually put off until the implementation and testing phases near the end of the development effort, which creates big surprises that are often too costly to address.

For example, it is not uncommon to find UX roles being brought into the project late in the development process, even after the SE implementation stage (scenario 1 above). They are asked to test and/or “fix” the usability of an already implemented system, and then, of course, many changes proposed by the UX roles that require significant modifications must be ignored due to budget and time constraints. Those few changes that actually do get included require a significant investment in terms of time and effort because they must be retrofitted (Boehm, 1981).

Therefore, it is better to have many synchronization points, earlier and throughout the two project lifecycles. These timely synchronization points would allow earlier, more frequent, and less costly “calibration” to keep both design parts on track for a more harmonious final synchronization with fewer harmful surprises.

The idea is for each role to have timely readiness of work products when the other project role needs them. This prevents situations where one project role must wait for the other one to complete a particular work product. However, the more each team works without communication and collaboration, the less likely they will be able to schedule their project activities to arrive simultaneously at common checkpoints.

23.4.4 Dependency and Constraint Enforcement

Because each part of an interactive system must operate with the other, many system requirements have both SE and UX components. If an SE component or feature is first to be considered, the SE role should inform the UX role that an interaction design counterpart is needed, and vice versa.

When the two roles gather requirements separately and without communication, it is easy to capture requirements that are conflicting, incompatible, or one-sided. Even if there is some ad hoc form of communication between the two groups, it is inevitable that some parts of the requirements or design will be forgotten or will “fall through the cracks.”

The lack of understanding of the constraints and dependencies between the two lifecycles’ timelines and work products often create serious problems, such as inconsistencies in the work products of the SE and UX design. As an example, software engineers perform a detailed functional analysis from the requirements of the system to be built. Interaction designers perform a hierarchical task analysis, with usage scenarios to guide design for each task, based on their requirements. These requirements and designs are maintained separately and not necessarily shared. However, each view of the requirements and design has elements that reflect constraints or dependencies in elements of the counterpart view.

For example, each task in the task analysis on the UX side implies the need for corresponding functions in the SE specifications. Similarly, each function in the software design may reflect the need for access to this functionality through one or more user tasks in the user interface. Without the knowledge of such dependencies, when tasks are missing in the user interface or functions are missing in the software because of changes on either lifecycle, the respective sets of designs have a high probability of becoming inconsistent.

In our experience, we often encounter situations that illustrate the fact that design choices made in one lifecycle constrain the design options in the other. For example, we see situations where user interfaces to software systems were designed from a functional point of view and the code was factored to minimize duplication on the backend core. The resulting systems had user interfaces that did not have proper interaction cues to help the user in a smooth task transition. Instead, a task-oriented approach would have supported users with screen transitions specific to each task, even though this would have resulted in a possibly “less efficient” composition for the backend.

Another case in our experience was about integrating a group of individually designed Web-based systems through a single portal. Each of these systems was designed for separate tasks and functionalities. These systems were integrated on the basis of functionality and not on the way the tasks would flow in the new system. The users of this new system had to go through awkward screen transitions when their tasks referenced functions from the different existing systems.

Constraints, dependencies, and relationships exist not only among activities and work products that cross over between the two lifecycles, but they also exist within each of the lifecycles. For example, on the UX side, a key task identified in task analysis should be considered and matched later for a design scenario and a benchmark task.

23.4.5 Anticipating Change within the Overall Project Effort

In the development of interactive systems, each phase and each iteration have a potential for change. In fact, at least the early part of the UX process is intended to change the design iteratively. This change can manifest itself during the requirements phase (growing and evolving understanding of the emerging system by project team members and users), design stage (evaluation identifies that the interaction metaphor was not easily understood by users), and so on. Such changes often affect both lifecycles because of the various dependencies that exist between and within the two processes.

Therefore, change can be visualized conceptually as a design perturbation that has a ripple effect on all stages in which previous work has been done. For example, during the UX evaluation, the UX role may recognize the need for a new task to be supported by the system. This new task requires updating the previously generated hierarchical task inventory (HTI) document and generation of new usage scenarios to reflect the new addition (along with the rationale).

On the SE side, this change to the HTI generates the need to change the functional decomposition (for example, by adding new functions to the functional core to support this task on the user interface). These new functions, in turn, mandate a change to the design, schedules, and, in some cases, even the architecture of the entire system.

Thus, one of the most important requirements for system development is to identify the possible implications and effects of each kind of change and to account for them in the design accordingly.

One particular kind of dependency between lifecycle parts represents a kind of “feed forward,” giving insight to future lifecycle activities. For example, during the early design stages in the UX lifecycle, usage scenarios provide insights as to how the layout and design of the user interface might look like. In other words, for project activities that are connected to one another (in this case, the initial screen design is dependent on or connected to the usage scenarios), there is a possibility that the designers can forecast or derive insights from a particular design activity.

Sometimes the feed-forward is in the form of a note: “when you get to screen design, do not forget to consider such and such.” Therefore, when the project team member encounters such premonitions or ideas about potential effects on later stages (on the screen design in this example), there is a need to document them when the process is still in the initial stages (usage scenario phase). When the team member reaches the initial screen design stage, previously documented insights are then readily available to aid the screen design activity.

23.5.1 User Interaction Design, Software, and Implementation

In Figure 23-2 we show software design and implementation for just UI software (middle and bottom boxes). While this separation of UI software from non-user-interface (functional core) software is an acceptable abstraction, it is actually an oversimplification.

The current state of the art in software engineering embodies a well-developed lifecycle concept and well-developed process for producing requirements and design specifications for the whole software system. But they do not have a process for developing UI software separately from the functional (non-UI) software.

Furthermore, there are currently no major software development lifecycle concepts that adequately support including the UX lifecycle as a serious part of the overall system development process. Most software engineering textbooks (Pressman, 2009; Sommerville, 2006) just mention the UI design without saying anything about how it happens. Most software engineering courses in colleges and universities describe a software development lifecycle without any reference to the UI. Students are taught about the different stages of developing interactive software and, as they finish the implementation stages in the lifecycle, the UI somehow appears automagically. Important questions about how the UI is designed, by whom, and how the two corresponding SE and UX lifecycles are connected are barely mentioned (Pyla et al., 2004).

So, in practice, most software requirements specifications include little about the interaction design. If they do get input from UX people, they include use cases and screen sketches as part of their requirements, or they might sketch these up themselves, but that is about the extent of it. However, in reality there is a need for UX people to produce interaction design specifications and for SE people to make a connection with them in their lifecycle. And this is best done in the long run within a broader, connected lifecycle model embracing both lifecycle processes and facilitating communication across and within both development domains.

23.5.2 The Promise of Agile Development

In Chapter 19, we attempted such an integrated model in an agile development context. Even though traditional agile methods (such as XP) do not explicitly mention UX processes, we believe that the underlying philosophy of these methodologies to be flexible, ready for change, and evaluation-centered has the potential to bridge the gap between SE and UX if they are extended to include UI components and techniques. As we mentioned in Chapter 19, this requires compromises and adjustments on both sides to respect the core tenets of each lifecycle.

23.5.3 The Pipedream of Completely Separate Lifecycles

Although we have separated out the UX lifecycle for discussion in most of this book for the convenience of not having to worry too much about the SE counterpart, we realize that because the two worlds of development cannot exist in isolation, we do try to face our connection to the SE world in this chapter.

23.5.4 How about Lifecycles in Series?

Consider the make-believe scenario, very similar to the one discussed earlier, in which timing means nothing and SE people sit around waiting for a complete and final interaction design to be ready. Then a series connection of the two lifecycles, as shown in Figure 23-3, might work.

The UX people work until they achieved a stable interaction design and have decided (by whatever criterion) to stop iterating. Then they hand off that finished version of the interaction design and agree that it will not be changed by further iteration in this version of the system.

The output of the UX lifecycle used as input to the SE lifecycle is labeled “interaction design specifications as UI software requirements inputs” to emphasize that the interaction design specifications are not yet software requirements but inputs to requirements because only SE people can make software requirements and those requirements are for the entire system. We, the HCI folks, provide the inputs to only part of that requirements process.

There are, of course, at least two things very wrong about the assumptions behind this series connection of lifecycles. First, and most obvious, the timing just will not work. The absolute lack of parallelism leads to terrible inefficiencies, wasted time, and an unduly long overall product lifecycle.

Once the project is started, the SE people could and would, in fact, work in parallel on compiling their own software requirements, deferring interaction design requirements in anticipation of those to come from the UX people. However, if they must wait until the UX people have gotten through their entire iterative lifecycle, they will not get the interaction design specifications to use in specifying UI software requirements until far into the project schedule.

The second fatal flaw of the series lifecycle connection is that the SE side cannot accommodate UI changes that inevitably will occur after the interaction design “handoff.” There is never a time this early in the overall process when the UX people can declare their interaction design as “done.” UX people are constantly iterating and, even after the last usability testing session, design changes continue to occur for many reasons, for example, platform constraints do not allow certain UI features.

23.5.5 Can We Make an Iterative Version of the Serial Connection?

To get information about the evolving interaction design to SE people earlier and to accommodate changes due to iteration, perhaps we can change the configuration in Figure 23-3 slightly so that each iteration of the interaction design, instead of just the final interaction design, also goes through the software lifecycle; see Figure 23-4.

While this would help alleviate the timing problem by keeping SE people informed much earlier of what is going on in the UX cycle, it could be confusing and frustrating to have the UX requirements inputs changing so often. Each UX iteration feeds an SE iteration, but the existing SE lifecycle concepts are not equipped for iteration this finely grained; they cannot afford to keep starting over with changing requirements.

23.5.6 It Needs to Be More Collaborative and Parallel

So variations of a series lifecycle connection are fraught with practical challenges. We need parallelism between these two lifecycles. As shown in Figure 23-5, there is a need for something in-between to anchor this parallelism.

As we mentioned earlier, however, this parallel configuration has the strongest need for collaboration and coordination, represented by the connecting box with the question mark in Figure 23-5. Without such communication parallel lifecycles cannot work. However, traditional SE and UX lifecycles do not have mechanisms for that kind of communication. So in the interest of a realistic UX/SE development collaboration without undue timing constraints, we propose some kind of parallel lifecycle connection, with a communication layer in-between, such as that of Figure 23-6.

Conceptually, the two lifecycles are used to develop two views of the same overall system. Therefore, the different activities within these two lifecycles have deep relationships among them. Consequently, it is important that the two development roles communicate after each major activity to ensure that they share the insights from their counterpart lifecycle and to maintain situational awareness about their progress.

The box in the middle of Figure 23-6 is a mechanism for communication, collaboration, constraint checking, and change management discussed earlier. This communication mechanism allows (or forces) the two development domains to keep each other informed about activities, work products, and (especially) design changes. Each stage of each lifecycle engages in work product flow and communication potentially with each stage of the other lifecycle but the connection is not one to one between the corresponding stages.

Because SE people face many changes to their own requirements, change is certainly not a foreign concept to them, either. It is all about how you handle change. In an ideal world, SE people can just plug in the new interaction design, change the requirements that are affected, and move forward. In the practical world, they need situational awareness from constant feedback from UX people to prepare SE people to answer two important questions: Can our current design accommodate the existing UX inputs? Second, based on the trajectory of UX design evolution, can we foresee any major problems?

Having the two lifecycles parallel has the advantage that it retains the two lifecycles as independent, thereby protecting their individual and inherent interests, foci, emphases, and philosophies. It also ensures that the influence and the expertise of each lifecycle are felt throughout the entire process, not just during the early parts of development.

This is especially important for the UX lifecycle because, if the interaction design were to be handed over to the SE role early on, any changes necessary due to constraints arising later in the process will be decided by the SE role alone without consultation with the UX role and without understanding of the original design rationale. Moreover, having the UX role as part of the overall team during the later parts of the development allows for catching any misrepresentations or misinterpretations of UI specifications by the SE role.

23.5.7 Risk Management through Communication, Collaboration, Constraint Checking, and Change Management

Taking a risk management perspective, the box in the middle of Figure 23-6 allows each lifecycle to say to the other “show me your risks” so that they can anticipate the impact on their own risks and allocate resources accordingly. Identifying and understanding risks are legitimate arguments for getting project resources as an investment in reducing overall project risks.

If a challenge is encountered in a stage of one lifecycle, it can create a large overall risk for parallel but non-communicating lifecycles because of a lack of timely awareness of the problem in the other lifecycle. Such risks are minimal in a series configuration, but that is unrealistic for other reasons. For example, a problem that stretches the timeline on the UX side can eventually skew the timeline on the SE side.

In Figure 23-6, the risk can be better contained because early awareness affords a more agile response in addressing it. In cases where the UX design is not compatible with the SE implementation constraints, Figure 23-3 represents a very high risk because neither group is aware of the incompatibility until late in the game. Figure 23-4 represents only a medium risk because the feedback loop can help developers catch major problems. Figure 23-6, however, will minimize risk by fostering earlier communication throughout the two lifecycles; risks are more distributed.

23.6.1 The Ripple Project Definition Subsystem

Using a project manager interface, a project manager accesses the Ripple project definition subsystem to specify the component parts of a project, including SE and UX lifecycle types, work activities to be conducted as part of the two lifecycles, roles, and work products.

23.6.2 The Ripple Constraint Subsystem

The job of the constraint subsystem is to represent, monitor, and enforce various dependency relationships among different entities between the two lifecycles during development. Through these constraints, different time-based events in the development space can trigger other events that need to be performed to maintain stability in the design.

Using the Ripple Mappings Description Component, the project manager can declare the different relationships that exist among various entities within the development space. For example, consider the relationship between the SE role’s functional decomposition work product and the UX role’s hierarchical task list work product: a mapping element must be declared so that a change to one of these work products requires at least a consideration of change to the other.

A project manager can declare a mapping between these two work activities to be dependent on the source work activity (e.g., HTI, by UX role), a trigger event that perturbs the design space (e.g., new task description added to HTI by UX role), a related work activity elsewhere in the design space (e.g., functional analysis by SE role), or the type of relationship (e.g., every task in UX role’s HTI must have one or more corresponding functions to support the task on the backend).

The Trigger Event Listener is a software agent that monitors the event queue for trigger events to enforce a relationship. For each event arriving at the event queue, the trigger event listener checks the mappings description to identify the corresponding relationship and delegates the enforcement of that relationship to the Relationship Enforcement Component by passing to it the event and its corresponding relationship. For example, in the case of the UX role creating a new task in the HTI, the module upon verifying the existence of a relationship, wherein the SE role is required to update their functional decomposition work product, informs the relationship enforcement component to notify the SE role about this change.

23.6.3 The Ripple Repository Subsystem

Various work products of the combined design process are stored as a shared design representation in a single repository called the Work Product Repository with each of the SE and UX roles having two separate views to this dataset. Developers are required to post new work products created at the end of each work activity here, creating “posting” trigger events.

The Ripple implementation of this repository has mechanisms to detect any queue events as and when time-based events for work products, such as work product created or is being modified, occur. Once detected, these events are sent to the event queue to be acted upon by the trigger event listener.

23.7.1 You Need a True Separate Role for Interaction Design

Although we have seen remarkable exceptions where software engineering people are also very good at interaction design, we generally stand by our conclusion that the UX process generally should not be done by a software engineering person. We need a true separate role for interaction designer.

In past years, this role has blossomed into a major career niche, going under many appellations, including user experience specialist, usability engineer, UX practitioner, UX designer, and information architect. While people entered this field from human factors, psychology, computer science, or engineering, now there are academic programs tailored specifically to train people to meet the demand for these skills.

People in all roles in both domains must work together and share in the design and development not just of the user interface, but of the whole interactive system. While these roles correspond to distinguishable activities, they are mutually dependent aspects of the same whole effort. These roles represent essential ingredients in the development process, and trade-offs concerning any one of them must be considered with regard to its impact on the other roles. Ever since we started working in this field, we have believed that cooperating and complementary roles, coming from both software and UX domains, are essential to the design of high-quality user interfaces. The roles require a lot of communication during interaction design and development as they work across the software, interaction, and work domain boundaries within a team of closely coordinated peers.

23.7.2 Sometimes Team Members Need to Wear Multiple Hats

Small organizations or resource-constrained teams sometimes force a situation where both interaction design and software design are, in fact, done by the same person, but that person must be aware of taking on both roles, roles that differ in about every way, requiring different skills, approaches, methods, and mind-sets. So, one individual person can take on two or more roles, a person wearing multiple hats. As anyone who has had multiple roles living in one head under the hats will tell you, the key is in maintaining the role distinction, keeping the roles separated, and being aware of which activity one is doing at any given time.

Failure to keep the roles separate will subject the hat wearer to a fundamental conflict of interest between the two roles. What is best for users is almost always not easiest for programmers. When push comes to shove, it is far too easy to resolve this conflict of interest in favor of easier programming, at the cost of the user experience. We have seen it far too often and far too blatantly. Cooper (2004, p. 16) puts it well:

 The process of programming subverts the process of making easy-to-use products for the simple reason that the goals of the programmer and the goals of the user are dramatically different. The programmer wants the construction process to be smooth and easy. The user wants the interaction with the program to be smooth and easy. These two objectives almost never result in the same program. In the computer industry today, the programmers are given the responsibility for creating interaction that makes the user happy, but in the unrelenting grip of this conflict of interest, they simply cannot do so.

So, wearing multiple hats requires the wearer to be faithful to the needs and goals of each hat. While you are reading this book, you should be wearing your interaction designer hat.

23.7.3 Interaction Design Needs Specialized Expertise and Training

Significant training and educational prerequisites for the software engineer’s role are obvious, but how hard can it be to make an interaction design? Do you really need a whole different role just to do interaction design? It definitely does not take a rocket scientist.¹ Is not it just common sense, something most anyone on the development team can do if they put their minds to it? If it were just common sense, we would have to wonder why good sense is not more common in the designs we use.

It is especially easy for software people to think that they can do interaction design with the best of them. Talk with many programmers about user interfaces and you will hear about widgets, interaction styles, callbacks, and everything you will need to build a user interface. You may sense a feeling of confidence—a feeling that helpful style guides and new interface software programming tools have catapulted this programmer into a real user interface expert.

Anyone, in fact, can produce some user interaction design. However, just because a programmer has an interface software toolkit does not mean that he or she can design a highly usable interaction design, and it does not mean that they necessarily know a good user interaction design when they see one. In our experience, we have actually encountered junior software folks smiling broadly as they wave the standards or guidelines manual and proclaim that not only can they now create the interaction design, but there “will not be any need for UX testing if I just follow the guidelines.”

As we now know, there is a significant prerequisite for the interaction designer’s role, too, including psychology, human factors, industrial design, systems engineering, and everything in this book! But computer science and software engineering are not among those prerequisites. Sure, design guidelines are important, but what is less well understood is the absolute necessity for a good UX lifecycle process, including lifecycle concepts, and process activities and techniques. Additionally, there is the song we played in the Preface: a requisite mind-set for truly appreciating the plight of the user.

23.7.4 Success Criteria for Developing Interactive Systems

Although we have talked much about processes, the bottom line is that the success of an interactive system development project is, at its base, all about the people. If team members in each role have respect for the other roles, and each team member has the requisite capabilities to carry out the assigned roles, the project will find a way to succeed.

Experienced developers already appreciate the importance of communication but, in the fog of battle, people get busy and people get consumed with their own responsibilities. So, the project needs to be infused with reminders to maintain communication about activities and progress, especially about problems and changes.

Finally, because resources are always limited, the team must act in ways to take utmost advantage of what resources they have. Among the issues this translates into are the staggering of the two corresponding lifecycles so that one does not constrain the productivity of the others and constantly ensuring situational awareness of overall process and the design.