As FileMaker developers, our job lies not only in creating calculations, scripts, and layouts, but also in successfully understanding the needs of the user. Easier said than done, right?

So what’s the key to understanding the user? Feedback. It’s easy to get caught up in the coding and the interface and forget to ask the user for feedback on our progress. So here are a few suggestions:

Before it Starts

During the time that you’re scoping out the project, begin visualizing the look and feel of the database. Remember that while we are concerned with the structure and mechanics of a database system, the customer just wants it to “work,” regardless of what it takes to make that happen. Also, ask your user what they are currently using—it will point to techniques and approaches that they are accustomed to. While we shouldn’t be constrained by what’s already been done, it can be a gateway to understanding the user.

Scope & Screenshots

Once you have enough information to scope the project, provide your customer with screenshots or mock-ups of what you’re planning on doing. The feedback you’ll receive early on can help make the rest of the process easier on you, the developer. What I often do is create a non-working layout for my first status meeting with the customer and say “What do you think?” It’s amazing what you’ll hear—from “I love it” to “Can we get rid of that color” and everything in between. The customers/users are the ones who are going to stare at this database —let them be the judge on what “looks good,” with a little insight of your own, of course.

Dwell On Design

Ever been on a website and things just don’t make sense? We’ve all run into situations where buttons are in the wrong place, the sequence of events seems out of order, or navigation is nearly impossible. These are all things that cause user anxiety. From a development perspective, those systems might successfully serve their purpose. However, removing the human element is a sure way to failure. Even worse than “garbage in, garbage out” is not knowing how to navigate, use, or manage a database. By focusing on the interface and user experience, your database will be more successful than building a plethora of bells and whistles. Try putting yourself in the shoes of the user and going through the process from start to finish. What types of things would you want to do that deviate from a normal scenario? Think of things like deleting, duplicating, canceling, etc.

Touch, Test, Tweak

Once your database is in a state of usability, put it in the hands of future users. Even better, go onsite or setup a screen sharing session and give them a lesson on using the database. Keep your eyes and ears out for feedback like, “How do I get there again?”, “Woops. I clicked on this by accident”, and “What does this do?” A database should be intuitive for the users and questions/comments like these point to a disconnect between what the developer built and what the users expected. Once you’ve provided a tutorial for the users, give them free reign to test the database. The process of testing and tweaking is quite cyclical, but will lead to big success. Ask questions like “What would you like it to do?” and if it doesn’t vibe with what you had in mind, follow up with “What do you think about this other approach?”

Partner Up, Don’t Dictate

Now I don’t want to portray that the developer should do exactly what the user wants. If a car manufacturer asked me how to build a car and I’d never owned one before, I might end up with 7 doors, 2 steering wheels, 12 tires, and no engine. We want to provide direction and focus, but the point here is that your users know the process they are trying to accomplish better than the developer does, usually—so combine your knowledge of structure and design with their knowledge of the business process.

The real crux of understanding users is interacting with them as much as possible. Don’t leave it to just the testing phase in your development process. This will lead to rework and frustration. Instead, when you build something that can be put in front of the user, do just that! Also, the more you accept and implement what your users want, allowing them to contribute to the process, the more likely they are to accept your feedback for efficiency and improvement of the existing process. Understanding the user isn’t rocket science—it’s basic psychology.