Treating end users as key stakeholders
At the beginning of every software project the question arises: which stakeholders need to be considered?
On one hand, business stakeholders, who are often taken into account, are the drivers of the project and want to adapt the business processes supported by the system to strategic objectives.
On the other hand, there are business stakeholders who may endanger the successful completion of the project through non-consideration, even if they assess the project proposals critically and therefore they are perceived as more of a "brake" rather than an "engine" during the project.
But what about the end users that will ultimately work with the software being developed? In many projects they are considered as stakeholders that must be surveyed, but too often, they are not treated as important stakeholders. In consequence, developers might work in the wrong direction, decreasing the business value of the product and at the end of the day, appreciation for the developers might drop due to diminished user satisfaction
So, how can end users be satisfied or even happy with new software if they haven’t been a part of the software development process? Are the business processes implemented in a manner that allows the end users to work more effectively and efficiently, and in a way that makes them feel more motivated when approaching their tasks? It is possible that this is the case, but it is also very likely that business processes are imposed on them and hence do not conform to end users expectations of workflow.
So how can it be ensured that end users will be satisfied or even happy with newly launched software? By putting them at the centre of the development process and treating them as key stakeholders.
Include end users as members of the project team
In various projects it has been proven wise to integrate a few selected end users as project team members both in a waterfall and agile approaches. This allows them to bring their requirements of the software directly to the table and to help shape the software itself. Then for example, they can define business processes together with Requirements Engineers or check-in during every sprint review alongside software developers, to verify if the features are being implemented as expected.
Furthermore, they can positively shape the development process by defining the features that are actually needed by fellow end users. Thus, if they contribute from the beginning, they can help make sure investments are focused on the right features. Additionally, if end users are part of the project team, tests can be conducted every few months, allowing valuable comparisons to be made and providing space for end users to proof the usability of the software. Hence, software tested from an objective point of view yields important data in regard to its usability as well as other important inputs that can also be collected from end users.
Paper and lo-fi prototyping as an example of how end users can participate
A good way to enable end users to participate in the software development process is paper prototyping. This method is used to evaluate, in an early phase, the requirements of end users. Depending on the project the method can be conducted as either group or individual sessions.
- Group session:
- Explain the methodology of paper prototyping
- Define the features end users have to sketch on paper
- Build groups of three or four
- Let the groups sketch their paper prototypes (30-45 minutes)
- Presentation of the results (sketch paper prototype) by end users to the whole group +discussion
- Individual session:
- If some features of the system to be evaluated are more complex, it is better to conduct individual sessions. In an individual session a paper prototype is created in cooperation with the end user so his needs and ideas can be consistently understood.
Following group or individual sessions, a lo-fi prototype is built by the requirements engineer with Balsamiq or Axure on the basis of the paper prototype. Soon after the lo-fi prototype can be leveraged as the basis for a good discussion to clarify questions from the requirements or usability engineers with end users, validating whether the end users see their requirements represented in the mock-ups, whether they understand them and how to interact with the system (determining if the usability is ok). Following this step, another iteration can begin by conducting another group or individual session concerning new features.
What is important in these iterations is to enable end users to build the paper prototypes on their own. In this case, by expanding the stakeholders to include end users, the process can become more efficient and results reached at a faster pace.
Figure 1: Participation of end users by paper prototyping
In a project with an agile approach the paper and lo-fi prototyping process as shown in figure 1 is adjusted to one sprint length (two or three weeks). This means that every two or three weeks user stories based on the lo-fi prototype can be added to the product backlog and the lo-fi prototype is attached to the user stories.
Figure 2: Example of a lo-fi prototype on the basis of a paper prototype
In general the benefits of paper prototyping are:
- it is highly cost effective
- all end users are able to create paper prototypes
- end user requirements are visible, clear and therefore easy discussable
- high usability of the system is ensured
- fast results can be achieved
- rapid iterations can be completed
- the process is simple and can be initiated by developers with low effort
The benefits for the development team are:
For the development team the results of the paper prototypes – the lo-fi prototypes – are very useful to understand, what end users really want and what their real requirements are. With this method the development team can understand in an early phase of the project the complexity of the system to be developed and they can already give inputs, for example: what will be easy to implement, what can cause problems and what might be a better solution. Lo-fi prototypes can be used as a design suggestion and therefore help avoid unnecessary development effort.
What are the success factors of end user participation?
Usually end users are not used to working on software projects. For them it is often not clear what is expected from them, how they should document their requirements, how to elaborate and document a topic from its foundations. By paying close attention to following points throughout the lifecycle of a project, end users can be guided by competent project staff.
- Personal talk with end users: The requirements engineer has to personally talk with the end users within individual or group sessions, to ensure the end user feels included enough in the software development process and receive feedback on what can be improved, to understand his needs better and shape the process more efficient.
- Enable end users to become lay requirements engineers: The project’s requirements engineer can enable end users to become lay requirements engineers by creating requirements documentation templates for them, i.e. for the detailed description of the paper prototypes. The templates help end users know what they have to focus on by elaborating a theme from its foundations. This leads to a more efficient process in the requirements elicitation phase.
- Don’t expect innovation from end users: In a software re-design project don’t expect innovation from end users, instead introduce innovation through paper and lo-fi prototypes and proof it with the help of end users, e.g.by conducting usability tests.
What is the benefit of the participation of end users in the software development process?
Projects usually have a tight budget. This raises the question as to why a part of it should be invested in the inclusion of end users as members of the project team. The following benefits illustrate why this investment is worthwhile.
- Development of the right features: Only the features that are really needed by end users are developed. This is an investment in identifying the right features from the beginning. Appreciation of developers at the end of the project is maximized and no effort is spent on unnecessary development.
- Effective and efficient end user support: Software is developed which supports end users effectively and efficiently in achieving their objectives because the business processes were implemented in a manner that best fits end users. Usability is high.
- Motivated end users: Due to the good support provided by the software, end users are motivated to work with it; this further increases its efficiency. The perfect basis for a highly rated product.
- End user acceptance of the software increases: Because end users know that their colleagues were part of the software development process, the software is implicitly rated better than if only seemingly "unsuspecting Business Stakeholders" had developed the software.
The above points show that early investment in bringing end users to the centre of the software development process is worthwhile. This leads to software that is unlikely to fail in delivering satisfying results to end users and also has high probability of making end users happy.