Designing an effective UI for FileMaker
Alexis Allen from, Designing FileMaker, shares her session “Introduction to the UI design process”, from this year’s FileMaker Developer Conference.
The process of designing an effective user interface can be long and complex. There are a number of ways to break it down, but here’s one way to go about it and make the process more manageable.
First, you prepare, by defining the requirements and drawing some initial sketches.
Next, you begin to plan your solution, deciding how you’ll structure your interface so that it best suits both the features you want to include, and the end-users.
Third, you’ll probably start thinking about more concrete details, like colours and fonts.
Last, you finally start to create your layouts, choosing and organizing the objects you need, and at the end, evaluating your results.
Each of the steps above requires you to make decisions and compromises to get to your goal — to create something that the user can easily understand and use.
This may be easier said than done, because there are many variables in any project, such as the scope of the features, the tech-savvy (or lack thereof!) of the end-users, the client’s budget, and your level of design experience. It’s smart to understand the impact of those decisions you can control, so you have a solid foundation to build on and can manage the rest.
Here are some specific things to think about in each of the four stages I mentioned above:
I recommend a specific sentence format for stating requirements, that gets to the heart of what the user wants, and why. It goes like this:
a. As a <user>
b. I want <feature>
c. so that <reason/benefit>.
You can have one set of these sentences for each type of user you have in your system. This format is helpful because it reveals the purpose behind why the user has asked for a specific feature, something which can get lost if we focus solely on describing functionality.
You don’t have to be an artist to create sketches, all you need is a pen or pencil and paper, and be able to draw lines and boxes. It can be tempting to open your computer and dive right into creating layouts, but it’s worth cultivating the habit of drawing some preliminary sketches first. You’ll be more creative and it’s quicker to hash out multiple ideas with low-tech tools.
Make sure you know in advance what platform(s) end users will be using to accessing your app. You want to tailor a solution for the correct audience. Layouts designed for the desktop might not perform well in WebDirect or FileMaker Go, for instance.
Also think about whether you’ll show the status area at the top of the window that FileMaker so helpfully provides. You may want to hide it in order to gain valuable screen real estate. That’s a fine choice, but then you’ll have to be very careful to provide all the functionality users need, because you don’t want to leave them in a dead end.
Will you have one application window (where each new window replaces the existing one), or multiple windows (where each new window opens, leaving the existing one in place)? Many longtime FileMaker users like the flexibility of multiple windows, but some systems are more suited to the one-window approach. Window management can be tedious to program, though, so make sure you have your approach nailed down early.
Every application interface or web page can be divided into a few different functional zones. If you establish these zones in your design, you’ll know right away where to put the functionality when adapting or extending your design for different views of the data.
- Content — The actual data
- Navigation — A way to get around
- Buttons — A way to take action
- Metadata — Record creation or modification information
Establishing these zones in your design will take you a long way to creating a coherent, consistent interface, because you won’t wonder where objects should go every time you design a new layout, and functionality is naturally grouped together, making it easy to find and understand.
It’s easy to overdo colour. You really only need three colours: a base, a background, and an accent (in addition to white and black, of course).
Your base is the anchor, and typically appears along the top of the screen. It’s probably a fairly strong colour, with some presence. The background covers a lot of the screen, and is usually a light colour. And the accent is just that, used sparingly to make action button stand out, for example.
Again, you don’t need much in the way of fonts. One or two will usually be enough. One for the “display” information such as field and button labels, and (maybe) a different one for the data. You could actually use just one font, and change the style — bold for the labels and plain for the fields, for example.
The biggest issue with choosing a font family is whether it will be available on the platform used to access the app. There is quite a short list of 100% cross-platform fonts. That said, if your users are on desktop and have Word installed, you may have a slightly more expanded list. Still, proceed with caution.
You’re finally ready to start creating some layouts. First you have to choose what objects you’ll use. A combination of fields, buttons, portals, tabs, shapes, lines, and text, among other things, will form the basis of the actual interface itself.
You want to make sure that you go back to the user stories and choose objects that help you deliver the features you defined, keeping in mind the reasons the users stated for wanting those features in the first place. Does the information need to be broken up into tabs? Will you use portals to show related records? These kinds of questions will help you decide what you need.
You should know how you want the user to interact with the layout in order to achieve the goal. (What steps should they take first? Next? etc.) The objects you choose should support this purpose and make it obvious what action you want them to take at each step.
Once you’ve decided what objects you need, you’ll have to organize everything so that it makes sense. You’ll want to group like with like, for instance. A portal is an excellent inbuilt example of this, where each portal row appears directly below the row above, and shows the same information. It’s a natural group. You can apply this same principle to other more disparate data too, grouping address information together, for instance.
Whenever possible, try and make the visual flow match the real-world flow of the data. Because we read from left to right, we assume that items on the left come earlier in the process than items to the right. It makes sense that client information would come before (to the left) of invoices, for example.
A similar rule applies from top to bottom. More general categories or groupings generally appear at the top of a layout, and become more specific as you go down. When the visual flow matches the real-world flow, it helps users understand your app much better.
Finally, once you have a design that you think is functional, take some time to go back and evaluate what you’ve created. Go back to your requirements and see if you actually built what you said you would. It’s amazing how certain requirements can somehow slip through the cracks.
Take a step back and see if each layout works both individually and when compared with any other layouts you might have. Is there consistency from layout to layout? Is it obvious what action you want the user to take in each layout?
Making a habit of looking critically at your work will help you gain design experience, because you’ll be more aware of what works — and what you might want to change, and why.
You’ll make many design decisions when working towards your goal of creating something the user can easily understand and use. These tips will help make some of your decisions easier, so that you can design better and faster.