Let’s start with a story. Once, a developer, let’s call her Jenny, had been tasked with rolling out a software update to a group of users. Jenny did all the hard work that developers do for these types of projects. She sure that the update would work with the old system, that the update matched the features from the users, and that the program was rolled out without any downtime. Following up a few months later, Jenny found out that many of the users were no longer using the program. She verified that she had given the users what they wanted in a program, but found that they could not use it because they did not have the latest version of the operating system that was needed to support her program. She had failed to understand the ecosystem in which she was developing the program.
This happens all the time, when we forget to look at the ecosystem surrounding our users.
Once you understand what your users want, you have to then look at all of the regulations, limitations, and resources in the ecosystem you are working in. Regulations could be company rules, guidelines for the industry, or laws put in place by the government. Some examples of this would be security protocols a company sets for sharing data internally and externally, industry best practices to protect data integrity, or regulations in place to protect sensitive personal information.
You need to know if there are any limitations to the technology available to your users. This includes understanding if users have both the hardware and software available to support your program. You should verify that none of the features of your program will be limited or disabled by security and antivirus software or firewalls. You need to know what other devices, such as smartphones or tablets, will be accessing the program and ensure that your program will work on all of the platforms users expect. Verify you have the appropriate resources for backing up and archiving the data your program uses available.
Check out the larger scope of where and how your program will be used. If your program requires access to the internet, but is being used in areas which have limited or unreliable internet, you have just provided an unreliable and limited program. If your program touches networks that are less reliable, you may need to change how your program AutoSaves to protect the data. You may find that some of your users don’t always have access to a computer and need to be able to print out crucial data.
At the end of a project you can provide all of the deliverables, meet all of the scope, and still fail because you didn’t understand the ecosystem in which your program will be used. When you take the time and make the effort to understand the resources and limitations you in the planning phase, you should never find yourself in that unfortunate situation where your program is brilliant, but unusable.