This is the fifth of a five part series on system design, relying on my own experiences and knowledge from working both in the public and private sector.

I have broken down my thoughts on system design into five distinct pieces: user requirements; development standards; usability, code-cutting, and testing and go-live (this article).

Testing

There are various different sorts of testing: there’s unit testing (where the developer tests each bit as they’re developing it), system testing (where the tester/developer tests the system as a whole once it’s developed); user testing (where it’s passed over to the users for testing and they have a look at it) and finally, assuming it’s passed every other suite of tests thrown at it, user acceptance testing (where the users compare what the system does against what was initially agreed that it should do) and then they hopefully sign it off and start using it.

If you have a less formal structure, or the development team have a good working relationship with the user department, you can carry out iterative user testing from the very early stages of development.

You need to have a developer who doesn’t get upset if the user doesn’t like something he or she has done, and a user who understands that they are dealing with a system which is only partially developed and so is liable to collapse in a heap at any time, but assuming you can clear those hurdles then you can begin iterative user testing at an early stage which is immensely beneficial to projects.

Early User Testing: Screen Shots and Colour Schemes

You can start this right from the beginning of the development: produce some mock-up screen shots of the system, showing the navigation bars, the colour scheme and so on, and send them to the user for comment.

The earlier in system development you are, the easier it is to make changes to things like system colours: further down the line you may have added images because they particularly “go” with certain colours, meaning that you’d have to replace these too, but if at an early stage you’re told that your pink-and-red colour scheme isn’t really suitable, and something involving greens would be more in keeping with a system for tracking first aid, then it’s really no problem to make these changes.

Of course, it’s important to differentiate between internal and external systems here: externally-facing systems may well have to have the corporate branding on them, and the individual users may not have much say in the final ‘look’ of this system as it may be decided corporately, but for internal systems it is generally easier to adapt things to meet the user requirements.

Early User Testing: Demo Pages

If you have any sort of test environment which can be made accessible to the system’s end users, or it is possible to publish temporary copies of the application in a place the users can access, then once you have completed the function of a few pages or forms, you can pass this to the user for testing.

This is of immense benefit, because you will of course be following the usability principles I told you about earlier, so you’ll be planning to lay out similar screens (“add person”, “add function”, “add venue”) in a similar way, and have the functions work similarly. Which is why it is of immense benefit if someone asks you after you’ve only written one of them “couldn’t you do it this way instead?”. Of course you could, particularly when there is only one page you need to adjust instead of five!

Not only that, but this buy-in from the users makes the development much more of a two way process: they feel as though they are taking an active role in the development process (as in fact they are), meaning that they have more of an emotional investment in the project and are more keen to see it succeed.

I’m aware that that might sound like management-speak but that doesn’t mean it’s not true. If you ask for feedback, and show that you’re willing to listen to that feedback and act on it, people do feel more involved and – quite correctly – feel that they are an important part of the project.

These demo pages can them be revised and republished as often as necessary until you’re ready to sign-off the project and for it to go live.

Project Sign-off and Go-Live

There comes a time when the developers and users of any project are happy for the project to be signed off and the system to go live. If the development of the system has been managed well, then ideally the users and developers will be ready at the same time.

Depending on whether or not there are any external pressures to have the system live by a particular date, there may be some feeling that further iterative development and testing steps should be carried out and that the system should be refined further and further before go live.

It’s important to ensure that the end-users are getting a fully functional system that does what they require, but from the point of view of the development teams, it’s also important to consider that you’re using the law of diminishing returns by this stage (every individual tweak takes longer to carry out and has less impact on the user department).

Ask the users to compare the system against the Acceptance Criteria that were agreed earlier. Hopefully – unless you’ve agreed any revisions — the system will do what was agreed. If not, then the users will point out where the system falls down and you can look at fixing that.

If the users have identified any changes that they would like but aren’t necessary in order to meet the acceptance criteria, it is helpful if some development resource can be allocated to this — even if not enough to carry out every request, if each request is associated with a certain amount of development ‘time’, and the users are told that they have X number of development days to ‘spend’, it allows them to prioritise their tweaks and changes and get those things fixed which are most important to them without being too much of a drain on developmental resources…

And then that’s it.

Make the changes, test them again, and then put the system live.

But don’t treat “go-live” as a single, one-off event.

Instead treat go-live as a procedure that takes at least a week starting from when the application is transferred to the live or production environment. Ensure that some development resource is allocated to the first week (or few) of the live system, because you can’t guarantee that you’ll have caught every potential problem; and pay particular attention to interfaces with other systems because if one of these goes awry, you could very quickly be causing problems for a number of systems!

Summary

That’s it, basically: the management of the development life cycle is about managing the expectations of the users when you agree the system requirements; about managing the developmental standards and the techniques the developers use; about managing the testing procedures and ultimately about managing the go-live procedure to ensure that the system works without any problems, that it meets their requirements, and that the users are happy with it.

There you go: get yourself away and produce perfect systems from now on…