(If the title looks too much like alphabet soup for your liking, here's a legend: UCD = User Centered Design, RUP = Rational Unified Process, SIGCHI.NL = Special Interest Group for Computer-Human Interaction's Dutch chapter)
Last Thursday evening, at SIGCHI.NL's March meeting, I gave a 10-minute version of the presentation I gave at the IA Summit about integrating IA deliverables into a RUP-based software development methodology. The whole evening was dedicated to UCD and the Rational Unified Process and featured 5 other presenters (including my co-organizer Joris van Gaal) from Dutch companies that had integrated the two worlds. It was good to see the others' approaches, the similarities as well as the differences.
Some things I noticed:
- it's almost a rule that it is the techies who select the RUP as their favorite method and forced it upon the company. Not management, and definitely not the designers; designers are forced to adopt the chosen methods were possible. After the meeting we had a feeling it is time for a comprehensive, UCD-based method to arise that will turn this around (MWUHAHAH!).
- most companies took 18 months to 2 years to complete the process of standardizing and documenting their methods and promoting it to the rest of the company. Apparently that is how long it takes for a group to develop its standards and convince the stakeholders that it's worth changing the old methods.
- it is harder to connect business and design than it is to connect design and technology. Several attendees suggested to execute the entire UCD process before the RUP process kicks in, assumingly to be present when business people make decisions and shape solutions.
- early design deliverables might, or might not, speed up the specification process, the jury was out on this one. Some attendees were convinced that starting with sketches of screens makes it a lot easier to visualize the solution, while others insisted that technolgy-and-design-agnostic use cases should be written before any screens are designed. One promising solution that might settle this debate is a deliverable called "content maps"; they identify the information required to proceed to the next step in a use case and as such are valuable input for what information should be on the associated wireframe, without having to layout the screen.
- we need a common vocabulary and standardized names for our deliverables. Possibly this was due to the different backgrounds and experience of the attendees, but I was surprised that I had to sketch a wireframe to explain what a wireframe looks like, especially for this audience.
Update (April 6, 2005): The "content maps" mentioned above might also be used in conjunction with page desciption diagrams as identified by Keith Robinson. Both deliverables focus on the content of a page(type) and not on layout or visual design.