Technical writing/Strategies

User Involvement

The perils inherent in ignoring users while developing a product are as obvious as they are prevalent. Only a very few software projects consciously involve end users throughout the whole process. So almost every project is plagued with misunderstandings, slow communications, unclear requirements, and unrealistic expectations.

Yet, most often the developers get together in a room with a white board and cobble together bits of structure, hoping to support functions, that may or may not be of value to the users.

So what can we do about it?

If we look at the Systems Development Lifecycle, we can see that User Goals ought to be our focus:

User Goals Drive the Process

The key processes always have to start with the User. How could it be otherwise?

• For the process to begin the cycle with Structure leads to obvious problems of incompatibility.

• Starting from Functions, you'll do a bit better. But because you've not really taken the time and effort to know the Users' Goals, meeting their approval is at best a fifty-fifty bet.

• Starting from the User makes much more sense. By keeping the focus on the important Goals, you can be certain that what you produce will actually be used.

It's not enough only to start with the User, you must ensure that you remain in nearly constant contact with your User, always verifying that the Functions and Structures you make into a Product will meet your Users' Goals.

Learn More

Online Literature Review Excerpts and Commentary

Note: This section is under development and welcomes assistance in commenting on the findings of the studies. Additional studies and commentaries are always welcome.

Main Findings: Helping and Hindering User Involvement - A Tale of Everyday Design, 1997 Motivate all stakeholders All stakeholders (users, managers, designers) need to be made aware of the potential benefits of user involvement and motivated to involve users. We need to appreciate that motives vary from one individual to another, so that an argument to convince management may not carry much weight with the users. Select a representative cross-section of users Although it sounds obvious, it is worth emphasising the importance of selecting a truly representative cross-section of users when some selection has to be made. This means selecting not just users from different work areas, or those who appear to know the most, but people of varying levels of seniority, expertise and service conditions. This is complicated by the fact that designers may not have completely understood the organisational context at the point in time when a selection has to be made. Involve a champion for the cause of user involvement As was evident in this study, a champion of user involvement can play a major role in influencing the design process, motivating people and organising the design activities accordingly. Organise meetings effectively It is important to be clear not just about the time and location of meetings, but also about their purpose. Knowing the purpose can help motivate the users to attend. Poor organisation results in meetings either failing to happen or starting off in a bad atmosphere. It is better to contact the users individually, preferably in person or by phone, when arranging the meetings. Ensure active management buy-in It is not sufficient for management to simply agree to user involvement. Management should promote the importance of user involvement, making sure that users are aware of what is happening and can take time out of their normal work to contribute. Don't expect the users to be designers Different expertise should be valued, with each participant contributing their special knowledge to the design process. In particular, it is unrealistic to expect users to have design skills. Designers should be largely responsible for contributing design expertise, while users can contribute information about their work and organisation. Follow user involvement through to the end User involvement lost momentum in this case study, and therefore some of the initial benefits were lost along the way. Users need to see that their contributions have been noted and, where appropriate, have influenced the design. Be flexible No design technique is going to be suitable for all participants in any design context. It should be possible to adjust the approach to accommodate individual differences and preferences of the users (e.g. skills, work method). Facilitate later involvement through earlier involvement It is important not to exclude users too soon by selecting a subset to be involved in the design activities. Further, the inclusion of new users at later stages should be facilitated through appropriate education. Educate users about the whole design process Users should be educated about what will happen in the process as a whole, which decisions will be made when and what the consequences of these decisions may be. Organise both individual and group meetings Users should be given the opportunity to voice their opinions in individual meetings where their views may be aired openly, but it is also useful to resolve differences of opinion with other users through group meetings.

Source: Helping and Hindering User Involvement - A Tale of Everyday Design

Stephanie Wilson, Mathilde Bekker, Peter Johnson and Hilary Johnson HCI Group, Department of Computer Science Queen Mary and Westfield College

Commentary:

Main Findings: USER INVOLVEMENT AND ENTREPRENEURIAL ACTION, 2007 Practitioners and researchers who wish to promote user involvement might draw two implications from this analysis. Better utilization of user involvement can be achieved by a better understanding of company-internal and company-external barriers to user involvement. In terms of internal factors, more attention should be devoted to the role of action rationality and sensemaking processes in integrating user inputs into product development.

Source: | USER INVOLVEMENT AND ENTREPRENEURIAL ACTION

Eva Heiskanen and Petteri Repo National Consumer Research Centre Helsinki, Finland

Commentary:

The technical writings is very good work stalin_singh@infosys.com

Clear Statement of Requirements

Writing Clear Requirements is a skill that you must practise and build up over time.

Proper Planning

Realistic Expectations