It becomes important to have the right amount. We do not want an overload of features, and even if you can, it’s not the right way or the right approach to building a custom tool. One, it can get very expensive for you. But if money is not a problem, you can overwhelm your team members when you have so many pages and you have not structured everything properly. They don’t even know what is going on. Everyone is seeing everything. It just looks annoying. Now, there’s a way to have lots of pages, features, capabilities, lots of everything in your custom tools, but they have to be built properly. They have to follow a certain flow. I’m not a UI/UX designer, but I can tell you that this is the best way. But we are going to have to look at user behavior, that’s your people’s behavior. How have they interacted with tools over the past few years? If you have data from previous tools, it’s very easy to go into these tools and see user behavior, how they interacted with it, whether they were frequent users, and where the places were that they faced friction.
If you go into another tool and you see that sometimes there were some areas where information wasn’t updated or things were not clicked properly, you can always know. It’s very easy to detect where things went wrong. If you’re working with someone to do this, you are a source of information for them. You’re going to tell them why people are not using it. And if you cannot provide the answer, someone on your team can definitely give that answer. Now, when you need all those features, charts, automations, and all, you cannot bombard everyone with them, especially in a situation where it’s an internal tool. You look at the goals and what you want to achieve.
Some situations certainly do not call for all of that. I won’t say I’m a minimalist, but I’ve realized over the years that less is more. If your team has had issues with using these tools, they do not need an overwhelming amount of features. Now, I’m not saying you shouldn’t add features, but I think we should start small. Look at the priorities. What has been our greatest headache? What has been the greatest problem? Where have we faced the most issues, as it relates to gathering information, as it relates to doing the things that need to be done, filling out information, submitting, giving feedback to clients, and as it relates to keeping projects on track? Looking at these things, they are more important than all the other features. And when you start there, you can improve upon the rest. Start with your basic tracker, and as you go on, you say, “Oh, they’d like us to be able to do this.” And we see if that is possible, we implement it.
I have this nice thing I do. It’s called the feature list. I think I’ll do another post for this that outlines as many features as are possible and reasonable for your industry, your team size, and your budget. And I tell you, “This is it. This is all we can do.” But with this feature list, some things have to come before others. We are going to prioritize them. And then some things are dependent on other things. They are dependent on information from you. They are dependent on how your team has interacted with previous features to see if it’s sensible to even implement them. Some things are very, very dependent on other steps in the process. I’m not trying to make it sound complicated because it’s not. For smaller teams, it’s not. But you have to take a look at these things.