When you get a new application or a customised one, you probably have a number of expectations. In some ways, the application may exceed the functionality that you desired. In other ways, you might find that your workflow processes take longer while you get used to doing things using different software. Either way, one thing is certain: The way you work will change. Hopefully for the better.
In order to better prepare you for the change that is coming, your designer has recommended you read this document.
Timing of your introduction to the system
The occasion when you are first introduced to the application might be at the design stage, or at a training session, or anywhere in between. Selected users might be asked to participate in system testing, so it is entirely possible that you are given a new application with little to no training in how to use it. If it is well developed, it should be intuitive. That is, you should be able to use the functions of the system by figuring out what they do and how to operate it by yourself. This is not unusual. When you buy a new mobile phone, or a microwave oven, you don’t attend a training session about its use. At best you get a user manual.
If you are part of the design team, or a likely administrator of the application, then your early opinion and feedback of the application is vital so that any problems can be ironed out before end users gain access to the system. This feedback will be sought before any training takes place.
What kind of user are you?
Over my almost 30 years working in I.T. I have encountered many varieties of end users.
When I first started in businesses, I taught users who had never touched a computer before. Nowadays that is a rarity. Some users are fearful of change. This fear should never be taken lightly. Some people can take the worry home with them, stress over it, and even have nightmares. I have cared for users switching from Mac to PC, and also those changing from PC to Mac. Users that experience worry or fear may require additional hand holding, but should be encouraged to experiment for themselves. I always say to these users, “To break a computer you need a hammer. As long as you don’t use a hammer then the system should not break.” If it does break, then it is the developers fault, not the users.
Other users can be resistant to change. By that I mean actively resistant. Such users can place all manner of obstacles in front of the development team. I will not reveal their tactics herein for fear that I give further ammunition to such people. Rather, I try to engage them to discover their reason for clinging to the old practices. Then I ask how the system could be made better for them. When I deliver their requests, it becomes harder for such users to maintain their resistance.
Some users embrace change. Hopefully, eventually all users achieve this level of consciousness.
Lastly, there are users who drive change. These are users that continually want the latest or repeatedly request new features. For me as a developer, these users are heaven-sent. It’s great to get positive feedback on how functions could be improved, or requests for new features. It means that these users are actively using the system to its fullest and are keen to improve the application further.
What kind of user am I?
Dear reader, you may think that I would be in the last category of user, surrounded by a bevy of gadgets, actively seeking out the new and the novel. I am sorry to disappoint, but put me in the first category. I am sorry to admit that I held on to Microsoft XP for far too long. I had software applications that I loved and knew very well indeed. Office 2000 did everything I needed. Some of my older software would simply not run on Windows 7. I am glad to inform you that I recognised there was a time to move on with the rest of the world, no matter how much worse things might be. I now run Windows 8 and Office 365, and yes I still hate the Office Ribbon. I understand what it is like to intimately know the way one system works, and yet be forced by the rest of the world to move on. So if you are like me, then don’t be afraid to call and we two dinosaurs can share stories. But I do like my gadgets.
Change changes everything
Even though your organisation has just taken delivery of a brand new system, you might have your own ideas about how the system could be improved upon. Your organisation might also require certain alterations to the program. This is typical. Once the program is delivered, users often have ideas that would make for more efficient processing or for enhanced functionality. The developer might also have ideas about improvements. So if you are not happy about something in the first incarnation of the system, there is always the opportunity to improve upon it.
Bug Catching
It would be unusual, to say the least, if the program did not have errors. In computer-speak these are called bugs.
The number of bugs that occur in a new developed or customised system could be quite large, and indeed in proportion to the complexity and size of the system. These bugs should be worked out of the system over the initial period. This could be anywhere from the first week until about three months. After then the system should settle down. Bugs can still turn up, for example when a user tries a previously unused function. A typical course of events for bugs is an inverse half bell curve as shown.
It should be noted that this graph depicts the time to find as well as fix bugs. I have systems that have been in use for varying amounts of time. I have created some systems that are untouched by a programmer’s hands in 15 years that have had no bugs reported in that time. Perhaps the ‘untouched by programmer’s hands’ is why it doesn’t have bugs. Hmm…
Sometimes a client hiring a new employee will cause bugs to be discovered, as that employee does things in a different way or tries out new things.
From a user’s point of view, there are two kinds of bugs. The first is where a function comes to a crashing halt. In a good program, these bugs should be ‘trapped’. That is, the bug shouldn’t cause the program to stop, but rather should display an error message with the ability to send a report to the developer. All of our software is built with such error traps, which include program logging to aid the developers to correct the program code.
The other kind of bug is where the function doesn’t work quite right. For example, in any version of Excel type in the numbers -123.45, 123 and 0.45 in a cells A1, A2 and A3 respectively, then use the =sum(A1:A3) function in cell A4.
In this case there will be no bug report window popup.
Users should still report any problems to the developer so they can be fixed. Our software has a special manual bug reporting feature available from the help menu for such a problem.
The bottom line is users should always report a bug so it can be remedied.
If the developer doesn’t know about the bug, they can’t fix it.
The best way to eliminate bugs early is to have plenty of testers. Ideally some from each user group. That is, administrators, end users, and management – yes, management.
Sometimes users discover that the work process the new program expects staff to use does not fit the reality that staff are able to perform. In these cases it really is back to the drawing board, hopefully for simple alterations rather than a complete rewrite.
Administratively speaking….
If your role in the new system is one of an administrator, then you will find yourself doing new tasks that you were previously unfamiliar with, or perhaps tasks which other staff used to perform.
Such new tasks could include adding new users to the system, enabling them to log in, setting and resetting their passwords, etc. Administrators can also find themselves responsible for entering large volumes of initial data, such as lists, the kind of lists that appear in drop down boxes. This is usually a once-off large amount of work, with additions later on an adhoc basis. This data entry work is required in order to set up the new system.
Administrators also perform monitoring tasks to ensure the system continues to run smoothly. Such tasks include checking for duplicates records, and assisting end users in installing and gaining access to the system.
Satisfaction Guaranteed
If you selected a professional software developer then you can rest assured they will do everything they can to ensure that your organisation is satisfied with the new application and that you as a user are satisfied as well. In addition to this, clients of I.T. Guaranteed are protected by a money back satisfaction guarantee. If you would like to know more about any of the topics raised in this article please contact me.
