MikePadgett.com

RUP for user experience professionals

Here’s a quick introduction to the Rational Unified Process (RUP) – IBM’s software development process framework – and what’s in it for user experience professionals. Comments are welcome and encouraged.

An overview of the RUP is essential reading and you’ll find that elsewhere. Assuming that’s covered, let’s say that the RUP consists of three basic elements:

• Project lifecycle phases [1]
• Software development best practices [2]
• Definition of disciplines [3]

RUP basics

Crudely put, the RUP is simply common sense distilled into a set of principles and practices that form a business process. This common sense is the product of lessons learned over the course of many years’ software development experience, together with a healthy dose of theoretical steering.[4]

Rather than being a prescriptive, fixed software development process, RUP is object-oriented, customisable and modular. Thus to be implemented by an organisation, the RUP must first be designed.

A designed process consists of roles, the tasks these roles do (called “Artifacts”) and how the tasks should be done. These artifacts are informed by disciplines described in the RUP documentation.

RUP concepts familiar to UX professionals

Like many aspects of the most if not all of the disciplines identified by the RUP will already be familiar to most user experience professionals depending on their exposure to the whole development process.

What may be less evident is how their individual roles and highly specialised tasks fit in the scheme of a RUP business.

Of the best practices in the RUP, user experience professionals will recognise iterative development and probably already work iteratively. For example, prototyping and prototype testing are usually iterative processes as is visual design.

Component-based architecture is also analogous to pattern-based design and the Cooper methodology. Like user experience activities, the language of RUP is all about workflow and outcomes.

Finally, most RUP processes are described visually, having been modelled with UML. UX professionals will appreciate this and may find themselves very capable of getting involved with the design of the RUP itself.

How RUP addresses user experience design

User experience is expressly included in the Analysis and Design discipline and embodied in the role of the User Interface Designer, whose tasks are to design and prototype the user interface and whose outcomes are a Navigation Map (something like a taxonomy) and a User Interface Prototype.

Ostensibly however, the User Interface Designer has no prescribed involvement in the development of use cases, software design or testing. His/her role is limited simply to the prototype and design of the user interface.

This role, with its default set of inputs and outputs, might work well enough for simple software that perhaps relies heavily on established patterns (traditional desktop client interfaces, for example) but it seems rather archaic and inflexible among  today’s technologies.

Perceived friction between the RUP and user experience design

In my opinion, the “classic” RUP leaves an absurd amount of risk at the door of just a few individuals: the burden lies particularly heavily on software architects and system analysts.

In practice, the idea of a User Interface Designer à la RUP probably won’t fit so neatly into your organisation. You might for example separate such activities between visual or experience designers and information architects, or prescribe others not mentioned above.

Furthermore the user experience professional’s role has very little connectivity with the wider development process, whilst carte blanche is given to more “senior” figures to totally limit or ignore the influence of user experience on the finished product. There’s a risk therefore that the positive benefits of UX and user-centred design on requirements gathering, architecture and testing tend to go unrecognised.

In this way, the RUP apparently leaves very little room for innovation, not least because it strongly favours predictability over agility. And while much work has been done on this aspect – agile processes are now the subject of a high-profile plugin – newer, evolving UX disciplines such as information architecture do not fit comfortably in the RUP sphere.

At best, this seems uncompetitive, at worst and to acknowledge the horror stories of many user experience professionals, it is unwise.

So just as the RUP demands considerable (and uncommon) breadth and maturity from its architects and analysts, the same is also required from organisations as a whole.

Maturity means among other things not taking the RUP specifications too literally. There is a difference between RUP roles and real jobs. Just because a user experience professional does this or that task in the RUP, it does not follow that the organisation’s expectations of him/her should stop there.

From another angle, if UX professionals have other work to do that requires different skills and experience, it might be difficult to justify these in a narrow RUP implementation. Hence the requirement for maturity in the organisation.

There is an appreciable risk of commoditising and compartmentalising job roles, particularly if the organisation doesn’t already consider UX among the highest priorities. Indeed I have seen something similar done with ITIL transformations: one day the goalkeeper turns up for the match only to discover he’s been moved to centre forward.

Summary: shake well before use

• The RUP is a process library for software development and the technology function at large.
• A sensitive implementation of the RUP has the potential to considerably improve technology projects, functions and processes, as well as the lot of those who work on them.
• User experience professionals are given an expressly defined role and the benefits of their work is recognised and embodied by the RUP.
• The RUP does not however put user-centred design at the heart of its approach to software development and UX professionals should consider carefully how their contribution can be properly recognised in a typical RUP environment.

Notes

1. Consisting of Inception, Elaboration, Construction and Transition. ↑
2. Consisting of Iterative development, Requirements management, Component-based architecture, Visual modelling, Ongoing quality assurance, Change management ↑
3. Consisting of Business modelling, Requirements, Analysis and design, Implementation, Testing, Deployment, Configuration and Change Management, Project management, Environment ↑
4. For more on the history of RUP, see the Wikipedia article on the original, pre-IBM Rational software ↑

The images in this article are all of artworks by M C Escher.

Further reading

• UIDesign.net Editorial (2001) UI RUPture: can Rational Unified Process really facilitate a better experience?
• Phillips and Kemp (2002) In support of user interface design in the rational unified process
• Lif and Göransson (2008) Usability Design: A New Rational Unified Process Discipline