The “Just Do It” (with users) methodology!

Stephen Collins has written an interesting commentary on iterative IT project methodologies with an interesting and heated discussion following.

In my experience, the approach Stephen talks about has a lot of advantages over traditional methods of handing systems design and development. While traditional approaches can lack innovation and be slow to progress change, an iterative approach can reduce risk by being more responsive to change and result in quicker time to launch. Dominic Campbell even suggests that the eternal beta should be embraced, iterating and improving system design once released to users.

I was recently involved in a project where we used an iterative design and analysis phase. It certainly worked better than some of the slower-moving approaches I’ve been involved with before — it freed the team to try new things and new approaches to difficult problems see if they worked. If they worked, then they were handed over to the developers. If they didn’t work, they were discarded with minimal time lost.

Of importance throughout this process, though, was a user-centred design methodology. So as to not overwhelm users, we only exposed them to things that were improvements to what they had seen earlier, or things that would directly affect them and their work. We showed them storyboards and prototypes (both wireframes and high-fidelity HTML mockups) and involved them in helping to improve the concepts. This was great for change management as it helped to set expectations about what they were getting and how it would look and feel. It also meant, given they were involved in design, they had greater ownership of the final product. And once they were happy with what ever iteration we had collectively come up with (in this design phase and not in production), we then folded it into the development cycle.

Ultimately, this meant that we could really only move as fast as users could consume new information. The result, though, was a final product was tailored to their wants and needs and not the whims of developers who want to try out something new on an ignorant public.

M

A match made in heaven

Today a colleague asked me, “what is the relationship between the prototypes and the process maps?”

Process maps are an excellent articulation of the functional requirements of an IT system. Together with process notes that elaborate on the inputs and outputs they can be a powerful indication of what people do when they do their work and, therefore, what a system needs to do to support that work.

All too often, though, analysts jump into discussions with the data analysts, systems developers and designers, to create functional- and non-functional specifications and data models … but what about the people who’ll use the system? Is the discussion with them now complete?

On a recent project I worked on, we actually had no large tomes of functional and non-functional requirements, nor use-cases. Instead, we just used process maps and prototypes, and involved the users in their development. We held weekly workshops with the users to help us come closer and closer to understanding how people currently worked, how they wanted to work, how we could improve their processes and how we could develop a system that would support their wants and needs. With each pass we improved our process maps and notes and iterated our prototypes that articulated how the system would support the people using it.

Our first pass was at a rather high-level, creating storyboards to illustrate the flow of action and information. This helped us understand where:

• there were gaps in process
• the flow of processes weren’t logical, and
• systems could help people get the job done

On subsequent peels of this proverbial onion, we developed more detailed prototypes, starting with wireframes and finishing with high-fidelity interactive HTML prototypes that brought the functional requirements to life and demonstrated the non-functional requirements of accessibility, usability, and navigability.

This combination of process maps and prototypes proved very powerful — a match made in heaven. Rather than hand system users tomes of specifications they would not read, we were able to involve them in the evolution of artefacts they could see, understand, relate to, and immediately give feedback on. They could easily say “no we don’t do it that way” and “no, we don’t want to do it that way” (which they often did) so that we could develop a system that would support them in the way they wanted their work to be supported — user-centred design in action. And because we used an agile methodology, and iterated our prototypes, we could come back to them the next week with improvements to our prototypes and demonstrate that understanding. We could then take these improvements to the developers and show the intent of the system, show them how the users wanted it to work.

This way of working has obvious benefits for change management — the end result is a system with no surprises because its users have participated in its development. This approach also means you create artefacts that people will actually use and can be easily referenced by the developers to see the ‘how’ of the system as well as its ‘what’.

… try it some time. It works.

M

User-centred design and prototyping

Last night I presented to the Australian Business Analysis Association (ABAA) on a topic that is close to my heart — user-centred design and prototyping.

As business analysts, we’re often focussed on eliciting business requirements for systems, managing the relationships between the business owners and the vendors and developers of the technology. Unfortunately, we sometimes forget that what we’re doing is delivering a system that is for users. This results in us delivering the ‘what’ in terms of requirements, but forgetting that there’s a very strong need to find out from the people who will use systems the ‘how’ it will work for them. If you’ve worked with an Information Architect before, this is exactly the head-space that drives their activities to determine navigation paradigms that are truly usable and accessible and systems that are designed to meet people’s needs in an intuitive way, rather than systems by developers that you have to ‘learn’ how to use.

User-centred design seeks to change all that by putting the user as the focus of all project activities, from scoping, to analysis and requirements gathering, all the way through design and delivery.

Starting with prototying in the scoping and planning phase is a great way to swing things back to the a focus on users — storyboarding and interactive prototypes are two of my favourite tools to achieve this goal.

If movie-makers like Pixar and Peter Jackson can use these tools to make movies that people will go to see and enjoy, then BAs can also make use of them to design systems that people will want to use.

M