Or maybe you are asking, “why doesn’t the IT team, or the company from whom I bought my software, get it right the first time?”

The fact is, custom technology really is complex. You’d think that with the number of years we all have under our belts, creating custom solutions to run in web browsers and on mobile devices, that it should be really quick and easy now to create something new. But in fact, the opposite it true. So, let me help you understand why that is the case by taking you through all the different facets that need to be addressed by that simple piece of custom technology you have in mind.

User Interface Design and User Experience … the way it looks, and the way people interact with it
To be successful, there’s no doubt that your custom technology needs to look good – modern, delightful, familiar but also match your brand so that it doesn’t jar with how your organisation appears in other places. Familiarity is important, so that your user doesn’t have to think too hard about how to achieve a particular task, but you don’t want your software to look the same as every other application so that your users don’t remember which software they are using.

User Experience can be constrained by the platform on which your application is to run. Is it operating within the constraints of a browser, or the constraints of a mobile app running on Apple’s operating system? Browsers have always been a source of angst for software developers. They are (now) free, but they come from different creators, and so have their own nuances. They are meant to follow standards, and these days generally do, but some browsers have implemented more of the standards than others. So you may find that one piece of functionality works perfectly in browser x, but is broken in browser y. There are usually ways around the problem, even if that way is to degrade gracefully, but they all require effort to resolve.

User Experience also needs to cater for different types of devices – mobile devices with touch screens provide a different mechanism for users to interact with the interface compared to people using your software on a desktop computer. Watches, digital pens, tablets … they all have quirks that your software needs to be aware of if it is going to run successfully on those devices.

Performance
Closely tied to User Experience is performance. Users of applications and web pages expect it to load quickly and process what they have submitted quickly. The way that an application is built needs to consider performance every step of the way. Perceived performance may be impacted by the speed of a particular user’s internet connection, the power of their hardware, the amount of memory available on their hardware, the amount of data flowing between a cloud server and the application, as well as the way the software is written.

Adding lots of features or complexity to one screen can impact on performance, and so careful consideration needs to be given to how much can be done on the one screen.

Caters for Every Scenario, and does what it is meant to do
One of the most difficult tasks in creating custom software is ensuring that it caters for every scenario. The person who describes how the software needs to operate has to think about not just the right way that a task should be done, but also all the variations that might occur, and how to handles those. For example, say you are building a To Do List application (because we absolutely need another one of those!), will your users want sub-tasks, will they always want to automatically tick off the main task once all the sub-tasks are done … the questions can sometimes feel endless.

When building software, it must help the user to know the right way to use the software, help them when, for whatever reason, they can’t follow the “right” way, and give them clear error messages and instructions on how to solve those errors when they get something wrong. We call this “data validation”.

Device and Platform Constraints
You may be of the view that whatever you can conceptualise can be built in software. That’s true to a degree, but unfortunately the device upon which your software will run comes with constraints. If you choose to have you software deployed as widely as possible, you might decide to build for both Apple devices and Android devices. These devices, particularly Apple, place many constraints on what the software can and can’t do. In some cases, only Apple itself can take advantage of some of the hardware features, so just because an app that comes on your phone can do a particular thing, doesn’t mean that you can achieve the same feature.

An example constraint is that you can only pair with a small number of other devices for the purpose of sending constant information between your mobile phone and the device you have paired with e.g. a watch, a watering system, a temperature thermometer. So if your software idea for a mobile device was resting on pairing with unlimited numbers of other devices, you wouldn’t be able to do that, and we would need to devise another way of achieving your idea.

There are many other constraints for not only mobile devices, the more common being:

• screen real estate: how much you can fit on a screen and still be able to read / interact with it
• memory: how much processing power at the disposal of your software before the computer appears to grind to a halt while carrying out a task
• disk space: how much information you can store locally on the computer your software is using

Easy to Use
Ease of use was touched on above, but is an important characteristic in its own right. Ease of use is partly achieved by a familiar user interface design, and a well laid out set of interface components. But ease of use also relates to the task at hand, and how most people would normally think about a task they need to achieve via a computer screen. It may be impacted by the user’s environment, and also the information that they need or actions that they may have had to take before they needed to use your software.

Ease of use also considers factors such as whether the user can tab from one form field to the next, can use keyboard shortcuts, or whether they have to use a mouse to carry out certain tasks.

People have never taken in large numbers to reading help manuals, so strategically placed tool tips and text instructions / placeholder text are very handy ways to improve usability. Error messages, strategically placed, and delivered early (for example immediately after entering something wrong) will often help with usability.

Accessible (WCAG)
Accessibility, while not mandated, is a very important consideration. It takes ease of use about 3 steps forward, incorporating into your user interface a range of attributes that enable people with disabilities to use every aspect of your software just as if they didn’t have that disability. For example, transcripts for video or audio content provides those without hearing access to the spoken content in those digital assets. You can read more about accessibility in our blog post about the topic of accessibility in web browsers.

Caters for Future Uses
When we build custom software it is always important for us to understand the roadmap of features planned or hoped for a future version of the application. This helps us to cater for that future in the architecture of the first version of the software. That’s not to say that you can’t later go in a completely different direction, but knowing where you are heading means that we can allow for the expansion of the features to be more easily incorporated late.

This is most often felt in the area of the data and navigational structures of your application, where, without forward planning, your software can start to feel like a collection of functions that have been bolted together disjointedly … because that’s actually what happened!

Integrates with 3rd party solutions
Integration with other software solutions provides many benefits including:

• you don’t have to build everything from scratch.
• you can take advantage of the pre-existing user base of the software you are integrating with, potentially providing your software as an add-on to their toolset.
• your software is more useful to your users because it is operating in an ecosystem.

Reasons why you might want to integrate with other systems include:

1. marketing automation purposes – triggering email marketing to a new user, for example
2. analysing the behaviour of users – what areas of your system are getting the most use, which ones are generating errors
3. sharing data with other processes, your accounting function, for example
4. adding data from other systems, such as the current weather, postcode and address lookups … the options are endless
5. triggering additional processes, such as ordering components, setting up a meeting …
6. notification purposes – keeping people involved in your work in the loop
7. and much more!

Integrating with other software requires work, and careful thought. Where your integration involves 2 way data sharing, you need to identify where the master source of information is going to reside. You will also need to determine what happens when data comes back, if something has changed in the interim in your software? And there are many more questions to be answered with regard to integration.

Secure
The proliferation of cyber attacks on software means that security of your software solution is paramount. However, there’s a cost with the implementation of security, as well as usability trade-offs. It is important to understand upfront the level of security you need to build into your application, which will be different for a banking application compared to a To Do List application.

For example, secure applications interrogate every piece of data that is submitted into it, checking that it is of the allowed type, length and does not contain a malicious payload. Secure applications store and pass all data in encrypted form. Secure applications have a layered approach, adding extra checks for access between the layers.

An application that is secure one day may not be the next … hackers are continually looking for ways to break into systems. A code library that has been built into your software may tomorrow be exploited for the first time by a hacker, and then the creator of that code library (assuming they know about the hack) will need to close out the vulnerability and distribute a new version of their code library. It’s then up to the development team to bring in the new version of the code library, ensure that your software still operates correctly, and then re-deploy the new version. It’s a bit of a cat and mouse game unfortunately.

Keeping your application secure is one of the reasons that regular maintenance is required for all software applications.

Scalable
The ability for your software to be used by large numbers of people simultaneously also needs to be built into the architecture upfront, if that’s the intention. Scalability comes at a cost, although cloud application platforms such as AWS, Azure and Google Cloud have made it more easy to scale up your processing power, and distribute your solution across multiple servers and geographic locations, with greater ease.

Easy to Maintain
The first version of your software will not be the last. Usually a person with an idea for software determines the features that comprise their “minimum viable product” – enough functionality to inspire someone to use and pay for the software, or switch from a competitor product to yours – and then has that built and launched as quickly as possible. After that, continued investment is made in improving features to keep ahead of any competitive changes, and also to keep users happy that they can see improvements over time. Decades ago people were content with the software they bought on day 1 and didn’t expect (or want) any changes. Those days are gone!

Therefore, it is very important that your software is easy to maintain into the future. This characteristic is determined by things like: what language is my software written in – is that easy for developers, well-known in case I need more developers, as well as the platform that your solution is built and deployed on. Some platforms make it easy to make incremental changes and deploy those quickly.

You may also want to be able to update the content within your application – enabling this requires extra work to be done during the build of the application, as well as having security implications.

Documented
Finally, are partly to assist with some of the factors mentioned above, it is very important that your software is fully documented as it is being built. This can be a time consuming task, but it is vital for future ease of maintenance and enhancements. It will help you, developers and support teams to remember how the software is constructed, and efficiently deal with issues or correctly implement enhancements into the future.

As part of developing software, it is also important to keep version history on the development of your software overtime. This provides peace of mind that it is possible to revert to a previous version, should the need arise. Backups of the software are also important.

Solutions to the Complexity

The complexity described above means that creating custom software is not for the faint hearted! There is definitely a case for using pre-built / off-the-shelf software which you can read more about here.

There are also many ways to help reduce the effort required to deal with the above, for example:

• Design frameworks. Material design is a prime example, where the team at Microsoft have created a collection of user interface components for icons, buttons, forms, cards and other user interface devices, which you can pick up and re-use in your own branding colours. These collections are often used as the starting point for a user interface design, with uniqueness added for more special functions of your particular application, as well as differentiation through your brand.
• Code frameworks. Similar to design frameworks, code frameworks help for faster development by having commonly required features available pre-built. Things like standard animations, sorting elements, working with collections of elements. Without code frameworks the effort required to build custom software would be massively bigger. The choice of code framework employed for a particular software solution will depend on the type of application being built, and therefore the components likely to be the most handy to get the job done. Coding frameworks also assist in the implementation of security, with most frameworks being structured with maintaining security in mind.
• Cloud development environments. This is similar to code frameworks, except that the development environment provide different types of pre-built component. For example, Amazon Web Services (AWS), Azure and Google Cloud, all provide a platform for hosting online software, along with components that are pre-built ready for use within your solution. Cognito is an example of a component available through AWS, which is used by many applications to handle to job of authenticating users into your application.
• Integration middleware. To help integrate your software with another online solution, it might be expedient to use a middleware platform such as Zapier or Automate.io (there are others) to use their middleware to connect to the destination application. This will definitely be faster during an application prototype phase, even if it doesn’t get you everything you need into the future.
• NO SQL / Document databases. These modern database platforms allow more flexibility to easily grow your data model to cope with any type of data you decide to add in future, which can require more work if you are using a relational database, although they have their place depending on your application.

If you are considering engaging a development team to build custom software for use by your organisation, or for the purpose of selling to other organisations (or maybe both!) please get in contact so that we can help you plan the successful development of your idea.

We’ve been designing and building custom software for more than 15 years, so we’re up for the challenge! Below are links to just a couple of examples of our work, if you would like to read more:
– Scinogy Centrifuge Protocol Builder desktop application
– Toll Group – Toll Transitions Pre-Removal Visit and Carrier Inspection Android App

by