In this article, I ponder the age-old developer question of, “How can I get the users to like the changes that I made?” There’s no easy answer, but there are some things you can do that can help.
It’s not surprising that I’m often asked to speak about UI or UX design in different contexts. Sometimes it’s a class or workshop, and sometimes it’s a presentation at a conference.
What is surprising is that almost Every. Single. Time. some version of the following question will come up: “How do I deal with users who complain about every little change that I make?”
It’s interesting, because in theory, I’m there to talk about UI design, visual design principles, or Gestalt design principles (shout out to our free resources on those topics!).
UI/UX Design Is About More Than Just the Interface
But in reality, UI/UX design is much more than just about the look or experience of the UI itself. It’s about what that UI or UX represents to people who interact with it in their daily lives.
To understand this better, let’s put ourselves in the user’s shoes for a moment. Imagine that you work for a widget company that has a legacy FileMaker app. You’ve worked there for many years, and the FileMaker system has been a faithful companion along the way.
In fact, you spend the majority of your working hours interacting with it, doing your work, getting stuff done. Yeah, maybe it could be better organized, and maybe there are a few things (ok, a lot of things) on the UI that nobody’s used for years, but on the whole, you’re happy with it. You know where everything is.
And whenever you need something new, you just ask the developer in charge to add this or that button or feature. They find a spot and squeeze it in.
To you, the solution represents a reliable way for you to get your work done and feel competent and satisfied at your job. And you have a feeling of power because you can dictate a solution to any problems you encounter and get someone to make it happen for you. So it’s not just a UI—it’s actually your livelihood, and even part of your identity as a worker.
The Problem with Piecemeal Solutions
Now, a new FileMaker developer gets hired, because your employer recognizes how valuable the FileMaker system is to their daily work, and ultimately their bottom line. Their intention is to revamp the existing solution to make it better and more scalable. They’ve noticed that it takes a long time for new hires to get up to speed—maybe six months or more—and it’s making it hard for the company to grow the way they want.
The problem with the existing system is that when new users come in, first they have to learn the business, then they have to learn how to use the FileMaker system, because it’s been built organically, over a period of many years, without a real roadmap.
The thing is, once new people acquire this knowledge, they can do their work quickly and efficiently. But nothing on the UI gives new users any clues about the process. They have to know what to click ahead of time (from some source outside the system, such as training materials or a colleague), in order to use it effectively. In other words, all the features are there, but you have to know how to use them. The company wants change.
Why Users Resist Change
But as an existing user, you don’t have the same agenda. You might not be on board with improving things, and you might fight even small changes. Because you just want to get your work done with as little problems as possible. The fact is, the company’s plans are not your plans.
And when developers go and move stuff around, it throws you off. That thing isn’t where you were expecting it to be, and that makes it harder to do your job. The dev team making changes disempowers you and makes it feel like you have no control.
So here’s our basic conflict: Users on one side, the company decision-makers on the other. And developers are caught in the middle.
The Pitfalls of Over-Customization
When users directly ask the development team to make changes, yes, they have been empowered. But this then sets up a dynamic where the developer is basically operating like a barista: Users decide what they want, and they ask the developers to make it for them.
This puts individual users in charge of discovering problems, figuring out solutions, and then initiating changes to solve those problems.
The issue with this is that users aren’t software designers or developers, and they often don’t have the context of the whole company’s solution. And frankly, they may not care about what others need. Don’t get me wrong, this isn’t a value judgement. It’s just human nature to worry about yourself and your own problems. Why wouldn’t you try to solve your own problems if you can? The company has given you access to a developer, so you’re going to go and ask that developer to do things that help you, right?
On the one hand, it’s not a bad thing for users to feel a sense of ownership or responsibility for improving the company’s FileMaker solution. In fact, that’s one of the things that makes it easier to implement new software. You want users to be involved.
On the other, this dynamic of being able to “order up” any change they think of can become difficult to manage.
The Hidden Costs of One-Off Solutions
This way of operating can result in a system that has many “ways” of doing slight variations of things, but few of what I call “methods”.
A lot of legacy FileMaker systems grow by building and maintaining workflows for one—one person, one client, or one situation. How many times have you ended up with a script that tests for case after case after case, and gets progressively longer to run and harder to understand and maintain as time goes on? (And how many scripts and layouts go unused after being used once and become cruft inside the Script Workspace?)
This is called “technical debt”—and the costs are often hidden, but very real. Technical debt refers to the long-term risks and inefficiencies created by quick, short-term development decisions, leading to increased maintenance costs, reduced scalability, and potential system failures over time.
The same thing happens with UI/UX design. Objects get added to the layout. Then another object with a slight variation is needed, and that, too, gets added to the layout. You need to find a spot for it so you move other things out of the way to make room. And so it goes. Pretty soon, you can forget about having an aesthetic. There’s just clutter, and it gets in the way of understanding what the UI is all about. These ad-hoc feature additions lead to UX debt similar to technical debt.
What you need, instead, are “methods” of doing things. Scripts that are modular and/or data driven, where the basic script remains the same, but the variables and conditions can change depending on the context.
Having “methods” also applies in UI/UX design. For example, there could be dedicated places on the layout where you can group functionality, such as button bars and popovers. These are objects that can hide complexity from the main layout, but which are still available a click away, if needed.
One method I use a lot is using card windows to add and edit records, instead of allowing access to the record in Browse mode. This moves complexity off the main layout and into a dedicated card window, which remains hidden most of the time, unless it’s needed. (You can learn more about this in the free preview class of The UX Design Workshop.)
I also make use of the three-dot “more” popover button (containing a button bar) at the end of a portal row to gather disparate functions that apply to related records shown in the portal.
Empowering Users Without Sacrificing Design
Another issue with this “barista” dynamic is that there is often no one person who understands the overall flow or process—and the needs of all the users. Everyone in the situation is reacting to every stray idea, and then implementing it. This, too, can lead to a proliferation of scripts, layouts, and workflows that are either redundant, difficult to maintain, or both.
So what was once an advantage—the ability to add new features on-the-fly quickly and easily—is now the thing holding the solution, and the company, back.
To combat this, it’s helpful to designate one person, or one team, to vet all user requests and determine how they fit in to the overall system. This person could be a Subject Matter Expert (SME)—in other words, a user—who works together with the development team to deliver system improvements.
That way, there’s someone who’s thinking about what would benefit everyone, and consulting with the devs over the best way to do things.
Users would still be encouraged to bring their problems to the designated team or person (we’ll call them the software product owner or project manager), to sit down and discuss their problems, and brainstorm potential solutions.
The team would then discuss how those problems could be solved (while considering the methods already in place, and the needs of other users), and then verify the proposed solution with the user.
In this way of working, users are still a part of the process and their opinions are still seen and heard (which is important), but they aren’t directly driving specific solutions to specific problems they have—often to the exclusion of other priorities.
Which makes sense, because they’re generally not designers or developers—you are! This is how you move away from being a barista, to instead becoming a software development professional offering your recommendations about ways in which you might be able help users.
Becoming a Trusted Partner
As a FileMaker developer, you wear many hats: problem-solver, designer, and often, mediator. The trick is finding the balance between empowering users and maintaining the integrity of your solution. While it’s tempting to give users exactly what they ask for, taking a step back to focus on their workflows—and the company’s goals—leads to better, more scalable systems in the long run.
Remember, good design is about making intentional choices that solve real problems, not just responding to every request. By establishing methods instead of workflows “for one,” you’ll not only simplify your development process but also deliver a solution that’s easier for users to adopt and enjoy.
Most importantly, transitioning from a reactive “barista” mindset to a proactive design partner allows you to take ownership of your craft. It’s your expertise that transforms cluttered, outdated systems into modern, usable apps that empower users and drive success.
After all, you’re a developer—not a barista.
If you’re ready to dive deeper into the art of user-centered design, consider exploring The UX Design Workshop for practical, actionable techniques to improve your FileMaker solutions.