Technical writing/Strategies
User Involvement
[edit | edit source]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:
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.
Best Practices
[edit | edit source]Learn More
[edit | edit source]Links
[edit | edit source]Online Literature Review Excerpts and Commentary
[edit | edit source]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
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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
[edit | edit source]Writing Clear Requirements is a skill that you must practise and build up over time.