Every GUI project has a user of some sort. Whether enterprise or commercial there is always someone who, in the end, will interact with your system in a very real way. The user is the purpose of the software, and it is the user, or a user advocate, that usually gives final approve on whether or not the software does what it is meant to do.

Commercial software in particular makes use of user advocates like product specialists and business analysts. Their job is to behave for certain parts of the workflow in the exact manner that an enterprise user might behave when internal software is being built. Beyond this introduction I will refer simply to the user, which will refer to whichever is applicable to your situation.

The User Timeline:

The user is involved in nearly every aspect of the ideal software development lifecycle. By involving the user all the way through, with no long gaps in user interaction, a software team is able to take a more agile approach to development and changes.

Because of this, the user has the longest timeline of anyone, they see the start and finish of the software development lifecycle, and continue to partake in it even after most of the software team has moved on, providing information for improvements, bug reports and the like.

Starting with the problem – Step 1

Software solves problems, it’s that simple. Whatever the problem is, that’s right where the user comes in. The user’s responsibility is to be able to define the problem clearly enough that the business analyst can own the project.

Users should be encouraged to come to the business analyst with clearly defined problems, not clearly defined solutions. There are a few reasons I say that, but the main one is that the business analyst is more prepared to offer software solutions to problems than the user is to come up with them.

Not only will the user potentially offer solutions that are not immediately actionable on their own, but they may also offer a simplified version that doesn’t do everything for them that it could, instead relying on extra manual processes that aren’t actually needed. The software development team is there to offer solutions, and to help the user make as easy a transition from whatever their current solution is (if they have one at all) to a new, improved solution.

Defining the solution – Step 2

At this stage we have a little bit of choose your own adventure. This section will be written as if the user is too busy to take part in the test case development and feature clarification, however, it is ideal if they can take part. If a user is capable of taking part in these procedures, please see part 3 in this series and have the user take the role of the business analyst for the section Specification.

Given that the user is not able to help define the tests.

When the tests have been defined

Then the user will review the user will review them at their leisure

It’s really that simple. At this point I can’t avoid the very real need to use Gherkin style language, or something enough like it that the user can read and understand what functionality is being tested, but we’ll talk about that more in part 3.

The user should review the tests to at least ascertain that the software development team is heading in the right direction and that no major functionality is missing right off the bat. This will be the first chance for the user to interact with the software process directly, but not the last.

Iterations and reviews – Step 3

Other things have been happening in the background while the user waits, and now there’s something to show. I’m going to say ideally that the meeting I’m about to describe should happen weekly, but bi-weekly iterations are not uncommon. Anything longer than bi-weekly and you start to lose the advantages of being able to make a rapid shift in development.

As each iteration comes to a close the software development team will gather. This meeting serves several purposes, but for the user the purpose of this meeting is singular. To see the software and get a real time demo of what it does. It doesn’t matter if the software team only has a skeleton of a page with some checkboxes on it.

This meeting will serve to keep the user constantly in the mindset of the software that they’re having developed, it will keep them thinking about the direction it’s heading, and it will help ensure that needed changes are caught prior to release. This regular demo of the software development process is absolutely vital to keeping the user in the loop.

Yes, this means software developers who are working on the project will interact directly with the user. This serves a lot of purposes. This actually comforts the user to a degree, but it serves a greater purpose which we’ll talk about in another segment.

Acceptance – Step 4

By this point the vast majority of changes have already gone in. The user already knows what the software done, has seen it run at the end of every iteration, and should, thanks to the weekly/bi-weekly demos, understand every decision made about the software. Acceptance should go very smoothly, with only minor changes now that the user is directly interacting.

At this point the user will make usability requests, these should be simple and easily handled by the development team.

At the end of acceptance the software passes into QA and the user should not see the software again until release.

Conclusion:

As stated previously, a user advocate of some type can fit in to the user role acceptably, though doing so means that to some degree the software development team owns the entire process, which is not really ideal.

Also, although step 2 was written from the more realistic perspective that a user would simply review the acceptance criteria written, this is not ideal either, and reasonable attempts should be made to include the user in the initial planning meetings which will be talked about extensively in the remaining segments.