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

Definition: http://en.wikipedia.org/wiki/Agile_software_development

Principles: http://www.agilemanifesto.org/principles.html

I was very interested in Agile as a framework for project management when I heard about it.

For web developers, the key points of interest include:

1. Client involvement – it usually happens in the web business that a client approves designs and you barely see them until it’s time for them to QA. The bigger your projects, though, the less you can afford to have this happen. I’ve worked quite a lot with marcomms agencies and you find sometimes that the Account Manager has spec’d one thing and the client wants another. Or else it can happen in-house. Agile says that we should invest clients closely into the development process, which in turn I think gives the client a sense of responsibility.

2. Fixed cost, flexible deadlines – closely allied to the above, though less palatable from a business point of view. Nevertheless, the web industry needs to grow up and dictate standards – let clients and stakeholders know how things are done. With that sense of responsibility described above, the client (or its elected agency) can understand that it has to keep up with asset delivery and provide responses promptly.

Recently I outlined a proposal to firm up the project flow at the company for which I currently work.

It went like this:

SETUP

All new work should come in from clients to you

You decide to delegate smaller matters to me (typically those involving only a single person’s efforts).Larger ones will stay with you, or a future project manager

SIZING AND SPECIFICATION

The job is spec’d out.This would obviously be either you (or a PM) or I doing this process depending upon the size of the project.At this point we would tentatively assign people to the work based on an assessment at availiability, which later goes to the grey book*.It is vital this gets done correctly.We must not allow lazy clients to say “it should do this and that” and then walk off leaving us to figure out the small print, so to speak.

The spec returns to you for costing

You add the cost to the spec and remit it to the client.The spec includes:

Timeline – including PM, Planning and QA.Use the red book* to ensure you have all tasks accounted for.An entry is then made into the grey project book

Client requirements – this is the bit in Agile where we involve the client or the agency. Client’s involvement in the project process: PO remittance, payment, QA, design approval (e.g. we must move release dates to AFTER the client’s QA rather than what is now frequently before) – in most projects this should include progress meetings here; client gives regular feedback, we pick up on missing bits. Similar occasions with the client onsite were most productive and should be used again for other stuff.

A clear and unambiguous statement that the stakeholder’s satisfaction of these requirements will enable project completion as per the content of para. a above.The client is a very big part of the process of getting the work done and the spec assumes that the client acts at all times with due efficiency and accuracy.Act or omission otherwise may lead to delay and additional costs, to be submitted as an Addendum with a separate PO required.This statement, whatever form it takes, must be quite firm and very well drafted.

Once the client signals approval, we should only have to assess whether our people requirements are accurate.An entry is made into the black project book*.

A PO needs to be received

WORK PROCESS

Work begins. Where the work is delegated to me, it should be a small enough matter for me to have minimal supervision over the person.This supervision will loosely involve:

Point of contact for developer and for client where allowed for in the spec

QA

There should be no need to exhort people for completion and stand over them etc, as the specification process is failing if this becomes necessary.It should be seen that lateness is rarely the fault of, and never frequently an issue faced by the developer.Equally the developer MUST behave responsibly when addressing whether he / she can deliver the spec in the time, to the standard and using the technologies, discussed.

Where the work is not delegated, then you or the PM would manage the process, and also take on the additional matters such as progress meetings etc.However, you may choose to appoint certain tasks where there is a practical value – such as chasing assets and QA.Where you do delegate tasks, those tasks should be supported by concise documentation – at least allowing you to monitor the stuff not directly in your attention.Note that the delegation of some large scale project tasks should be motivated by a practical value rather than an absolute necessity and all such delegation should be pre-planned and accounted for in the spec.Use of the red book will be essential here!

CLIENT QA

Given that internal QA is part of the work process rather than an additional stage, the client needs then to QA using whatever method they usually employ.This is not part of the work process, so release dates are affected but not costs (Agile).If you want to deliver on a fixed release date, then the client MUST be part of the project by committing a fixed amount of time for QA to be added on to the work process.

Bugfixes – now this is quite an open part of the process, and in our history, it seems to be endless.Note this: the better our QA, the lesser the bugfixes.NOTHING that is not on the spec should be part of this item.If functionality didn’t get seen by the client in the spec, tough.We as professionals spec’d what was discussed.If we didn’t then we are idiots.

Client QA now is ONLY to check the bugfixes were done OK.NO new ones should be accepted.

RELEASE

A full release (with notes if handed over) should be accompanied by a short meeting to evaluate the successes and failure of the project process if the project was not delegated as a smaller matter during Sizing and Specification.This should also be accounted for in the spec so that it is still a profitable incentive to have this meeting.It should involve all who worked on the project.If there any specific notes of interest, they should be recorded in a memorandum and sent to you.That way, we can cement our good practice and address things that don’t work

Summary:

*red book – this is a list of all of the processes a project can go through. As components in an overall project engine, the processes can be allotted typical timeframes and help us to see projects as being made up of experiential objects. We use these components to plan a project properly so that we don’t miss bits in the overall time the project will take.

*grey book – this is a calendar of projected time use. It shows all projects currently underway and any future ones due to arrive. It gives an overview of the business and assists with future planning

*black book – this is the project plan once approved. It may be occasionally adjusted, but it is basically the timeline of the spec. It must be stuck to and relied upon, by both management and developers.