3 Design Choices to Avoid in the Design of your Document Management Systems

Document management systems are like cars. In the case of cars, any car that you buy is going to let you move around. Likewise, any document management systems that your company buys is going to allow you to store documents. But just as with cars, software users don’t usually want the car with just the factory settings; they want to customise it according to their needs.

Some users will opt for the customisations that the brand allows them to make, which guarantees that these customisations will be under warranty: paint colour, anti-fog coated headlamps, front parking assist, navigation system, etc.

Other users will want more complex customisations. They might even modify the engine!

Making changes to the document management systems factory settings and beyond the customisations that the software allows involves two important risks:

• It puts the viability of the project at risk: it could be that the changes asked for are so complex that the duration of the project is unexpectedly extended or it could even become impossible to carry it out.
• It puts the ability to maintain the software at risk: it’s possible that we may have difficulties updating the product to new versions due to incompatibilities with the custom developments.

Below, we share 3 especially grave errors you must avoid if you are in charge of a document management project that involves software customisation.

1. Avoid making a Frankenstein out of the features

A car is a car, it won’t cut the grass. So adding a lawn mower doesn’t make much sense, right? It’s the same with a document management systems. Why insist that a document management systems be able to make calculations or have ERP features?

I’ve participated in processes in which it was insisted that the document management systems be able to calculate the purity of a laboratory sample!

Keep the document management systems features and use integrations with other tools to cover the specific needs you have.

2. Made-to-order modifications

Let me use a different comparison to illustrate this point. Surely, if you order a bespoke suit from a tailor, it will be more expensive than if you go to a store like Zara and buy one off the rack.

The same is true with software. In this case, the higher costs are paid in the medium and long term. An application developed by us or only for us has various disadvantages:

• It is tested and evaluated by a small group of users. A product on the market is tested and evaluated by users in a wider variety of circumstances. Therefore, the software is much more polished.
• They tend to go out-of-date. As there is no marketed product behind it, all the updates are your responsibility. Whether with internal or external personnel, you’ll have to bear the costs of evolving the platform.
• Performance problems. As I was telling you, applications on the market are tested by many more users in varying conditions, including with volumes of documents or concurrent users, that you don’t have at the moment. But, with the passage of time, you could find yourself in these situations. Software manufacturers carry out tests with billions of documents in some cases, so the volume of documents you have won’t be a problem.
• Integration problems. If you develop a custom application, you will also have to develop the integration possibilities. There are no products currently on the market that don’t have an API. Many products on the market support CMIS or even have embedded features.

The problems listed above are also applicable for large developments that we decide to do on a market product, which brings us back to point 1.

3. Too make restrictions, validations, or fields that threaten the platform’s usability.

This is an easy mistake to make. Let me show you some typical examples of some technical requirements for document management projects:

• Forms with more than 25 fields, 90% of which are obligatory. Users will be discouraged in the face of such long forms. Do you really need all that information? Is there no possibility of inheriting or importing it instead of digitizing it?
• Fields that we list as required and that block the user when it comes time to continue if they are not completed. Usually, the people who develop the software tend to forget that there are exceptions. You won’t always have all the data and users CANNOT be blocked from moving forward if they are missing a piece of data.
• Format checks that block the user if they are not complied with. The same as above. For example, we cannot send a form if a piece of data does not have a certain format. At first, we think that the format is X, but in the future, we realise that in some cases, it’s also Y. When we reach this point, for the cases that the format is Y, the users are blocked.
• Hiding fields according to the rules of business. This is another typical requirement that users in the design phase really like. The problem with this is similar to the previous two points. When we are already in production with the new software, we realise that we are mixing rules and we are left without the visibility of fields we need, or we find that the hiding rule shouldn’t be following in all cases.
• Too much JavaScript. In applications, the last two points we talked about tend to be controlled by JavaScript. If you add in too many checks or business rules, you end up with a JS code that is difficult to maintain. In addition, anything that may have slipped your mind means that you are going to have a technical dependency to solve it.

These are just some of the examples that come to mind, but there are many more cases and errors.

Trust the user, trust their professionalism and their ability to discern before deciding to put up all kinds of roadblocks that will demotivate them when using the new software.

Also keep in mind that however much you try, when designing, you aren’t going to have in mind all the possible cases and exceptions that may arise. The best thing you can do is offer visibility and lots of consultation help that users can have as a reference.

I hope this has helped orient you and help you reflect if you are in the phase of defining the requirements for a new project or expansion of your document management systems.