Participatory design: a user-centered approach

The tunnel still a reality

When developing software, implementing a method in Waterfall or V, the future users express what they would have, and then see at the end of a period shorter or longer (six months or over) software completed. Between these two steps, they saw nothing, have been informed and the result is often far from their expectations or their needs.

Then follows a "Waterfall" of complaints, requests for change to take into account the outcome of which will be the adaptation of software to user requirements. They start and a new waiting period imposed prior to and necessary phase of profits related to the use of their new product.

We now understand that it is important to integrate the users throughout the design process, development and validation of software to take their views into account.

An obviously not so obvious

If the solution seems obvious, its implementation is not necessarily. Indeed, we found that it is not easy for users to give their opinions constructively, partly because they do not necessarily know what their requirements are, or how to specify and other First, because they usually change their requirements when they see the deliverables. This finding is what Barry Boehm called the effect "IKIWISI" (I Know It When I See It - I know it when I see it).

The idea of "Descartes"

In the discourse on method (1637), Descartes makes us an interesting conclusion from "[...] divide each difficulty that I would look into as many parts as possible, and would be required for better solutions [...] ".

The combination of this principle (used in iterative models of software development) and the need to integrate the users throughout the design process, development and validation of software, has created a new concept called: iterative and participatory design incrementally.

The iterative and incremental participatory design can be summarized as a method of work where the emphasis is on the active role of users and whose main characteristic is the active involvement of users throughout the development of software to build and validate the produced as and when it was built.

1. The goal is to create value
2. The wheel evolves continuously towards the target.
3. The spacers are used to consolidate gains and prevent the wheel back down and revert back.
4. At the end of each cycle is a book element of the product to users (or client)

Basics of Agility are thrown

Based on its findings and its learning and having developed and tested several methods, some are listed below, seventeen of software development experts gathered in 2001 in the United States, to discuss the unifying theme their respective methods. This meeting was the emergence of the Agile Manifesto, regarded as the act of generalization of Agile development and its underlying principles. The Agile Manifesto consists of four values and founding 12 principles (available on the website dedicated to the Agile Manifesto).

Summary of some Agile methods

Some of the well-known agile software development methods:

• Agile Modeling
• Agile Unified Process (AUP)
• Dynamic Systems Development Method (DSDM)
• Essential Unified Process (EssUP)
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Open Unified Process (OpenUP)
• Scrum

Extract from the Agile Manifesto

We found a way improving software development by performing this work and helping others to do so. Thus we have deduced values:

1. Focus on interaction with people rather than processes and tools
2. Focus on product and operational rather than a bloated Documentation
3. Focus on collaboration with the client rather than negotiation of contract
4. Focus on responsiveness change rather than following a plan

The 12 principles are inferred to have been added to specify and clarify the meaning and implications.