A variety of factors influence a user’s experience when they engage with an app. While much of it is outside of the developer’s control, there are many intentional decisions to make when building databases. Prioritizing a user-centered development process helps set an interface up for successful deployment and use—but how do you do that? In this four-part series, we’ll explore some of the decisions developers have to make as they evaluate their database user interface and experience.
What kind of development work will you do?
Occasionally, it needs to be said that as developers we should strive for dev work that, well, works. A beautifully designed layout may be wonderful at first glance, but it cannot create a positive user experience if it doesn’t have the necessary functionality. Missing features, failing scripts, and poor database structure will not succeed.
Whether you’re updating an established software package or building an app from scratch, it’s imperative to start with your users. They can instruct on how they use the current software (if there’s one in place), as well as feedback about their ideal workflow. As those on the front-line, they know best what their desires and needs are. Additionally, you may realize that their needs have changed over time, but habits are difficult to break. One client of PK Information had gradually shifted from using their FileMaker software on mobile devices to desktop computers. While the initial request was for a complete user interface overhaul that included desktop optimization, we quickly realized that employees enjoyed the portrait orientation of the old software as it allowed them to have side-by-side comparisons and data entry. Yes, the interface needed an overhaul, but this functionality of it needed to stay the same—and only users could inform us of this.
As a natural extension of this, make sure your development process includes adding new features but not always removing existing ones. 10 times out of 10, you won’t have enough institutional knowledge of the company processes to accurately determine what needs to stay and what can go—even if you’re an in-house dev! Removal can be very disruptive, so do it only if certain, and consider hiding/restricting access in the immediate term. Your client’s end users need to determine if a tool should be removed or restricted. Even then, however, be hesitant to completely wipe it from the database. Custom hides can be your best friend in situations like this.
Additionally, as you learn more about the database, suggest new features or functionality to your client, but make sure they sign-off on them before implementation. Your client should be aware of how this new feature will impact workflows, if it will hinder future database development, and a reasonable estimate of how long it will take to complete. If not, you may end up eating the associated costs involved.
In a complete redesign, make sure to keep the main thing the main thing. Every-day functions shouldn’t be buried within multiple menus that require a plethora of clicks. Multiple clicks for repetitive actions can cause fatigue and annoyance. For some processes, batch capabilities can be a major time-saver for relatively few development hours. Additionally, creatively used hides can help prevent a cluttered layout and sensory overload of these every-day tasks.
However, make sure you use appropriate checks and confirmations for specific tasks. Such as when deleting, prevent accidents with extra clicks to complete the process. At PK Information, our standard is to incorporate a custom dialog window in situations such as this. When a user clicks on a button intended to delete a record, a custom dialog window appears to confirm that that is what they meant to do. It is a second check that the user truly wants to perform the action in question, while also communicating the ramifications that will occur in a concise and specific manner.
Finally, your development process needs to include quality assurance checks that include both developers and users testing the processes. Rather than merely “develop and dump” on your client leaving users to just deal with whatever hand they’ve been dealt, ensure you have robust control processes. PK Information includes checks performed both by developers that haven’t worked on the project as well as by administration staff that don’t have development experience. From there, we gradually roll-out features and options to specific users who will test functionality and provide feedback from their perspective. This QA process is part of our development routine, so we bill clients for the associated development time. However, any bugs discovered after launch—which should have in theory been discovered during QA—aren’t charged to clients, as they’re our mistake.
By prioritizing successful development processes that work correctly, you’ll build trust with your clients and end users as they’ll have confidence in the software package. While perhaps a simple idea, it is a major step in user interface design towards building an excellent user experience.
PART 1: WHO DO YOU DESIGN FOR?
PART 3: HOW DO YOU STRUCTURE CONTENT?
PART 4: HOW WILL THE INTERFACE LOOK?
PK Information is a FileMaker-certified development agency serving the Tampa Bay and Knoxville regions. We believe that great software can change everything. Does your database need a code review and additional development to work correctly? Contact us today!
SUBSCRIBE
Sign up with your email address to receive future posts like this directly to your inbox.