Behind the Scenes: How We Design Features That Actually Get Used

I still remember the demo call with a potential client about seven years ago. They were evaluating our ERP system against a competitor’s product. The other software had this massive feature list, a dashboard with about twenty different widgets, reports for everything imaginable, and configuration options that required a manual thicker than my college textbooks.

Our product looked simple by comparison. Almost boring.

We didn’t get that client. They went with the feature-rich option because, on paper, it looked more capable. 2 years later, they called us back. Their team was struggling. Nobody could figure out how to do basic tasks. The training was endless. The support tickets were piling up. They asked if we could help them migrate to our “simpler” system.

That call taught me something important: features don’t create value. Used features create value.

The 80/20 Rule of Real Use

If you look at how people actually use software, most of them use about 20% of the features 80% of the time. Sometimes it’s even more extreme. I’ve seen businesses pay for enterprise software where their team touches maybe 10% of what’s available.

The rest just sits there, adding visual clutter and mental overhead.

When we design features at Zubizi, we start by asking: what are our users doing every single day? For a garment manufacturer, it’s creating production orders, tracking material consumption, and managing worker payments. For a retail shop, it’s billing, inventory updates, and basic accounting. These aren’t exciting features. They’re not the kind of things you put in a flashy demo. But they’re what people actually need to work smoothly.

Our job is to make that 20% absolutely effortless. If we can save someone five clicks on a task they do fifty times a day, that’s real impact. That’s 250 fewer clicks daily. Over a year, that’s thousands of moments where the software just gets out of the way and lets them work.

The other 80% of potential features? We’re very careful about adding them.

Where Feature Ideas Come From

We get feature requests constantly. Some come from support tickets where users are trying to accomplish something our software doesn’t handle well. Some come from client calls where business owners describe their workflows. Some come from our own team using the product and hitting friction points.

The tricky part is separating real pain points from passing thoughts.

Not all feature requests are created equal. Some represent genuine friction in daily workflows. Others are solutions looking for problems, or nice-to-haves that sound important in the moment but won’t actually change how someone works.

The worst mistakes happen when you build something without understanding the underlying problem. A client says they need feature X, you build feature X, and then it sits unused because what they really needed was Y, or because they found a simpler workaround that doesn’t require any software at all.

Now, when someone requests a feature, we dig deeper. We ask: How often would you use this? What happens if you don’t have it? How are you solving this problem today? If they’re managing fine with a spreadsheet or a notebook or a phone call, maybe that feature doesn’t need to exist in our software.

The Simplification Filter

Before we build anything new, we try to simplify it.

There’s this tendency in software development to add options for every possible scenario. You want to let users do X? Great. But what if they want to do X in situation Y? What if they want X but with condition Z? Before you know it, you’ve built something that requires a training session just to understand the settings page.

We built our sales and invoicing module three times before we got it right.

The first version was simple and clean. Just the essentials: customer details, items, quantities, prices, and totals. It worked beautifully for basic invoicing.

Then, as we gathered feedback and new requirements, we started adding fields. More options for taxes, discounts, payment terms, shipping details, notes, linked documents. Gradually, that initial simplicity disappeared. The module turned into one massive form where users had to scroll through dozens of fields just to create a simple invoice. People would stare at the screen and ask, “Which of these do I actually need to fill?”

The second version tried to organize this complexity better. We grouped related fields, arranged them more logically, but it was still too much. The screen still felt crowded and overwhelming.

The third version, the one we use now, took a different approach. We broke everything into focused sections with collapsible panels. The header shows customer details and order date. Additional information like shipping details goes into an expandable section that stays hidden unless you need it. Item selection gets its own clean table with customizable columns. The footer displays totals and action buttons.

Now users see only what they need for their immediate task. Everything else is one click away when needed, but not demanding attention when it’s not.

That version took off. Training time dropped from two hours to twenty minutes. Support tickets about invoicing dropped by 60%. People just got it.

Measuring Feature Success

How do you know if a feature is actually being used?

We track a few things. First, adoption rate. What percentage of users actually enable or use this feature within their first month? If it’s below 30%, that’s a red flag. It means either the feature isn’t relevant to most users, or they don’t understand why they need it.

Second, frequency. For features that are supposed to be used regularly, how often do people actually use them? We had a production scheduling feature that we thought would be used daily. Turned out most manufacturers were using it once a week for planning, then ignoring it the rest of the time. That told us we’d misunderstood the workflow.

Third, support burden. Good features reduce support tickets. Bad features generate them. When we added auto-fetching customer details based on GST number, our support tickets about incorrect customer data dropped significantly. Users just enter the GST number, the system validates it and pulls in the company name, address, and other details automatically. That’s a feature doing its job. When we added advanced filtering to our reports, support tickets went up because nobody could figure out how the filters worked. That’s a feature creating problems.

The best indicator, though, is qualitative. When we visit clients or do training sessions, we watch how people work. Do they hesitate before using a feature? Do they ask for confirmation that they’re doing it right? Or do they just fly through it without thinking? The features that disappear into the background, that become muscle memory, those are the successful ones.

The Balance Between Feedback and Vision

Here’s the uncomfortable truth: sometimes users ask for features that sound perfectly reasonable but would actually make the product worse.

I’m not saying users are wrong. They know their business better than I ever will. But they’re describing solutions based on their specific context, and sometimes those solutions don’t generalize well. Or they’re solving a symptom rather than the underlying problem.

This is where product design gets philosophical. Users naturally think in terms of solutions, not problems. When someone requests a specific feature, they’ve already done the mental work of diagnosing their issue and prescribing a fix. But their diagnosis is constrained by their context, their existing workflows, and their mental model of how software should work.

The challenge is distinguishing between the requested solution and the underlying need. Sometimes what looks like a simple feature request would ripple through the entire system, creating complexity that affects everyone. A feature that solves one person’s specific workflow might introduce cognitive overhead for hundreds of others. It might require new fields in every form, new options in every report, new training for every user.

There’s a concept in systems thinking called “local optimization versus global optimization”. You can make one part of a system work perfectly for one person while making the whole system worse for everyone else. That’s the trap of building exactly what users ask for without questioning whether it fits the broader architecture.

The solution is deeper discovery. Instead of accepting feature requests at face value, we need to understand the job the user is trying to accomplish. What problem are they really solving? What’s the cost of not having this feature? Are there simpler approaches that achieve the same outcome without the architectural complexity?

Learning to say no is hard, especially when the person asking is paying your bills. But protecting the overall user experience sometimes means declining feature requests. Our job isn’t to build everything users ask for. It’s to build software that works well for most users most of the time.

It’s Easy to Build Features

Adding a new button, a new screen, a new option - that’s the easy part. Any developer can do it. The hard part is knowing what not to build.

Every feature has a cost. There’s the obvious cost of development time. But there’s also the cost of maintenance, the cost of documentation, the cost of training, the cost of cognitive overhead for users who now have one more thing to understand.

The best software I’ve used doesn’t feel powerful because it has lots of features. It feels powerful because it makes complex tasks feel simple. That requires restraint. It requires constantly asking: does this really need to be here?

We’ve removed features from our product. Not many software companies talk about this, but we’ve actually taken things out that we’d spent weeks building. We had a calendar view for production schedules that looked great in demos but nobody actually used day-to-day. We had a social feed-style notification system that just became noise. We removed them. The product got better.

Design isn’t about addition. It’s about subtraction. It’s about removing friction, removing confusion, removing everything that stands between your users and getting their work done.

When we’re evaluating a new feature now, the question isn’t “Could this be useful?” The question is “Is this useful enough to justify its existence?” And the bar for that answer keeps getting higher.

Because at the end of the day, the software that wins isn’t the one with the most impressive feature list. It’s the one people actually want to use.