Tailoring RUP for web applications – part 1 (in case I think of more stuff later)

Traditional RUP practices greatly undervalue – if not completely ignore – the concept of User Centered Design (UCD). For me, UCD is a critical factor in developing any application, doubly so in web applications. According to “The Rational Unified Process Made Easy” by Per Kroll and Philippe Kruchten it is only in Transition – the last of the 4 RUP phases – that you should “Beta test to validate user expectations are met”. Leaving aside the question of where the user expectations came from in the first place, the Transition stage is too late to significantly rework a developed application. It may come down to a choice of leaving out the changes or postponing go live and having to do some serious rework. So much for addressing the risks earlier. As with other aspects of RUP, UCD should work iteratively and be present in each phase of the software development project. In fact, it should be a discipline within RUP in its own right.

Performing some basic UCD activities do not need to cost a lot of money or involve a lot of people. For example, you could do paper prototyping. Hang up some Wireframes (screen schematics) in a specific flow and ask potential users if they understand what is happening on each screen, ask them what they would do to complete a particular task. Another good way is to find someone not involved with the project and ask them to look at the first developed application, again ask them to perform one of the key tasks of the application. If they cannot work out how, then there is a problem. Arguably, this is already too late to begin thinking about the usability of the application.

In an ideal world, an Information Architect and/or Interaction Design involved from day 1 on the project (think roles not people) and as well as use cases being prioritised in terms of their Architectural Significance, they would also be prioritised according to the User Experience Significance. These two elements would be used in tandem to decide which use cases to tackle first (Inception) and also to drive any phase planning done on the basis of use cases. I think it fair to mention here that I assume that the Business Significance of the use cases is an automatic consideration.

Another Transition activity recommended by RUP is preparation of training material. One snag with this one, with a web application you do not get the chance to train the user group. Anyone get use the site (within security restrictions etc..) – it is on the web. A website that is OK technically can be more successfully than the best coded site in the world if it has significantly better usability. Think of the websites you have been to and have given up what you were doing. Now, why did you give up? How did you use the site? Did you read every options? Did you spend 5 minutes looking at pages other than the welcome page?

Kevin Costner once made a film called “Field of Dreams”, when thinking about usability I am reminded of a quote from that film:

If you build it, they will come.

That may work for a baseball diamond in a corn field, it does not work for the web. A better quote would be:

If you build it and they can find their way to it, they will come.

Someone finding their way is down to how usable, and sometimes how Accessible a web site or application is.

Time for a mass generalisation, a typical user will Google what they are looking for select the first link, scan the page, they will then select the first thing they see that they think may be what they are looking for (even if what they are actually looking for is 2 cms further down the page). They will scan the new page, if it is not what they are looking for they will head back to Google and select the next link. If you are lucky, they may scan the first page one more time. Is this how you picture users/customers using your website? Do you build it with them in mind? If not, then you have a problem/opportunity depending on which management guru is flavour of the month. A problem in that a lot of people who come to your site may only see the first page, even if the website is doing its job. An opportunity in that by improving the website, you could increase new customers, user retention, sales revenue, charitable donations….

How do I know?

In the past I have worked on designing government web applications that allow UK citizens to complete their income tax return. User base from 16 to 65, various skills and educational levels, various comfort and skill levels with internet use, etc…etc… and yet the application was instinctively usable and now has a user base of 2 million people who come back each year.

Best tool I know for communicating UI design: SWIPR - truly excellent, easy to use tool. You do need to have Visio 2003 though.

The Nirvana Method - aka my first mental scribblings

The following is something I wrote - the first thing actually - to vent my frustrations of tenory versus practice.

I’ve decided to come up with a methodology for developing software. Now before I get in to it I should warn you that I am not a techie, and do not (and have never) written code for a living. I have worked (in no particular order) as a systems analyst, business analyst, requirements analyst, information architect, and interaction designer. The Nirvana Method is my take on an ideal methodology. For me, this would combine the theoretical elements of RUP and the practical guidance offered by AGILE methods.

RUP out of the box is a giant beast of a thing, to even begin to use it you need to throw a good chunk away as your organization does not use/want/need* all of the roles/artifacts/activities* that comes as standard (* delete as needed). RUP then needs to be tweaked, which leads me to the conclusion that it is mostly a theoretical approach to software development.

AGILE methodologies are in essence a backlash against waterfall methodology and crushing documentation and processes that leave countless projects stuck in the mud. When looking at the AGILE Alliance site, especially the article “An Introduction to Agile Methods” that uses XP as an example, that the AGILE approach is aimed at getting the job done. AGILE deals with the more practical approach to developing software, for example pair programming and promoting single location teams (XP).

What are the common points of RUP and an AGILE method?
Iterative Development;
Deliver working software at the end of each iteration;
Highest Risks First (technical, business, usability);

OK then, what is specific to an AGILE methodology?
Define functionality as stories;
Programming in pairs;
Test Driven Development;

What is specific to RUP?
Model the business domain;
Define functionality as use cases;
Use Case Driven Development;
Work with components;

And what is just Common Sense (never to be underestimated)?
Communication as a key success factor;
Individuals as a key success factor;
Customer and end user involvement;
Requirements will change;
Planning will change;
Learn as you go, write better code (refactor);
It costs less to fix a requirement than an application.

So my big question is why cannot all of the above elements be combined? It can, the Nirvana Method. The Nirvana Method:

An iterative development methodology that delivers working software at the end of each iteration, attacking the highest risks functionality first based on a sound understand of a specific business goal(s) and environment.

The Nirvana Method believes that communication, individuals, customer involvement, and user centered design are critical success factors that are needed to combat the reality of changing requirements, priorities and planning.


OK, so it is not really a method; more like a statement of how I would like projects I am involved with to work.

First past the post

Welcome!

So here it is, the first post. Exciting stuff. For me at least.

So, why did I create this blog?

Well, I have recently changed jobs and have been spending a lot of time looking at improving software development processes for my new employer and their customers. The main idea is to take RUP and customise it based on experience (mine and others). Along the way I have been diving in to the theory to check my practice, and this resulted in a lot of frustration, so I decided to start a blog to vent. If you find a couple of useful ideas amongst my venting, excellent.

“In theory, there is no difference between theory and practice, but in practice, there is.” Yogi Berra