Design to Deliver
Posted by jeggent on January 8, 2021
Some years ago I started to get concerned about something. My group was becoming responsible for an increasing amount of regular maintenance as we automated more and more processes. I decided that we needed to deliver solutions in a way that empowered the end users and minimized the ongoing involvement of the technical staff. So I came up with an outline/template laying out the items to address to accomplish these goals. I called it Design to Deliver. Having this outline also helps to establish the scope of a project to make sure that everything is included and to correctly estimate a project timeline. The components of Design to Deliver are:
- Security
- Flexibility
- Usability
- Documentation
- Training
Security
Does the project have any security requirement? Do all of the users have access to the pages and items included in the solution? Getting security changed can often take some time. It is important to include security changes to have an accurate timeline.
Flexibility
Is the solution flexible enough to handle minor variations without needing rework? For example is the end user able to specify which aid year or term is to be processed? If codes are known to change over time is the selection logic written to account for that, such as using using LIKE or BETWEEN instead of EQUAL or IN?
Usability
Is the design user friendly given the skill sets of the end users? Solutions that include steps that are too complex for the end user will likely continue to require technical support. Good usability also includes being compatible with the users current process. For example, will the next item appear on a screen that is already being used often or within a current workflow? Or will the user have to take additional steps and review different screens?
Documentation
I know. I know. Documentation is not fun. However it can be critical in empowering end users to be more self sufficient. Some processes are only done once a year. Sometimes staff change responsibilities. And in these cases having documented the process in detail can make all the difference. A year from now the user may not remember how to complete the process. It’s likely the developer won’t either. Then time will need to be spent re-learning and re-explaining the steps.
Training
Does the project include time and materials for any training that will be required? Training is another item that is too often overlooked but goes a long way to empowering users. Training can take a while to complete depending on the number and locations of the users.