January 30, 2017 Blog FileMaker Techniques User Interface Design designFileMaker ProFileMaker Pro 15UI techniques Mental Map for User Interface Design Using a Mental Map to Make Intuitive UI This article will introduce the mental map concept of user interface design as it applies to FileMaker. The FileMaker platform enables us to build software very quickly – far less time than the typical software development cycle. With the ability to construct a working piece of software quickly, it’s easy to “rough in” a quick UI. However, it may not be very intuitive to use. The most intuitive software needs little or no explanation. The user intuitively knows how it works, either from visual cues, conveniently integrated documentation, or through the use of conventional UI techniques that people already understand. Unintuitive Software Design Unintuitive software is confusing or overwhelming, and leaves users asking where to find something, or how to accomplish basic tasks. A badly-designed user interface can be learned through sheer muscle memory, but that doesn’t mean it’s become easier to use. It just means that the user has been able to finally remember the steps to get their job done. It means that they’ve finally been able to construct a “mental map” of the system. What is a Mental Map? Just like in the real world, people need to create a mental map of software to find their way around. You know how to get to work without GPS, because you’ve built a mental map of your surroundings. To find their way around complex software (particularly a relational databases), users need to build a mental map too. Geographical Maps & UI A map graphically describes the spatial relationship between objects in an abstracted form. In the case of a geographic map, that’s the overhead view. In a desktop operating system, the overhead view is analogous to your “desktop”. Users visually move into and out of folders, scrolling through files that are contained in them, and then close the folder again, which goes back to its original location on the “desktop”. You move “into” and “out of” folders and applications, go “back” in your browser, and up and down in the directory structure. All of that is reinforced by visual cues in the UI. You have a sense of where you are, and where you’ve been at all times. The same sort of interface conventions hold true for your mobile OS. You swipe left/right to move across the surface of an imaginary area. Even though the entire surface of that area is not visible at all times, you are able to create a mental map of the entire workspace. This is because the location of objects in it are reinforced by the movement of the interface. You know that the app you’re looking for is “to the right” of your home screen. Likewise, when you click on an email in a list, and the single email slides in from the right, you know that the list of all your emails is still “to the left”, and clicking the arrow at the top left corner will return you there. Of course there is no “to the right” or “to the left” on your phone, but the software has enabled you to build a mental map that makes it easy to remember where to find everything. FileMaker Relationship Graph As a FileMaker developer, you’re intimately familiar with the relationship graph. The relationship graph serves as your actual map to the system, at least in data form. But it’s all too easy to forget that the user of your software will likely never see that graph. This is your map to show how table B is accessed from table A, but the user doesn’t see that. They need to be shown, through the interface, what the relationship is between the two tables. Similarly, the relationship between a found set of records in list view, and a single record in form view needs to be clearly delineated. As a developer, you should aim to enable users to easily create a mental map of the system. There are several techniques that I use to reinforce a user’s mental map in the systems I design. The Dashboard The first technique is using a “Home” screen or “Dashboard”. This serves as a central point from which you can access almost any other screen in the software. Think of it as the front door, or perhaps more accurately, a “software foyer”. Taking this analogy, you enter the software through the front door. You are presented with a set of doors and hallways that take you to other locations in the house. If one doorway leads to the dining room, and one to the living room, and a staircase leads upstairs, then you always know how to get to the living room from the dining room, or from the dining room upstairs: by going back through the foyer. The home icon takes you back to the start, so you can move to different parts of the software. It’s easy to build your mental map based on a single home screen, with all the different sections of your software radiating out from there. This is not unlike the FileMaker relationship graph. Limited Context-Jumping Another key technique I employ for reinforcing the mental map is to limit navigation across contexts. Every time you move from one context to another, it adds another layer of complexity to your mental map. If you move your user between contexts without providing some very clear indicators that they’re looking at things from a different perspective, you run the risk of actually breaking their mental map, since the place they think of as “back” is no longer the same as it was moments before. Floor plans & UI As a real-world example, wouldn’t it be confusing if you started at the front door, went upstairs, then into a bedroom, and then walked through a door and suddenly found yourself back downstairs in the kitchen? For that same reason, it’s generally better to make the user return to the dashboard (back downstairs to the “foyer”) in order to visit a new context, so that they can easily add on to their existing mental map. Context-Jumping in FileMaker Alternately, you can enable your user to view their related data from a single context, without forcing them to move to a new screen. I do this whenever possible. For example: My user is viewing a “Customer” record, and on the layout is a portal that displays related “Jobs” for the customer. When I click on a job in the portal, instead of navigating away from my customer to the Jobs context, I simply load the single related record right there from the customer context, using a global-field-based relationship. Now, my user only has to hold the Customer “location” in their mind, and from there can see into detailed info about that customer (i.e. their jobs), rather than forcing them to build a new location into their mental map – the Jobs “location”. If they are required to move over to a new layout in the jobs context, they’ll need to somehow build into their mental map exactly how that relates to the customer, how to get back to the customer they were on, and how that relates to the system as a whole. If, however, they’ve never moved from the customer context, they can immediately understand how the job relates to the customer, and how they got to that information, because in theory, they’ve already built that part of their mental map. Signposts and Icons As I described earlier in this post, one of the ways that mobile operating systems reinforce the mental map is by using buttons that explicitly display an arrow icon, typically coupled with animation that shows the movement of one screen to another. When clicked, the screen shifts over from the direction that the arrow pointed, reinforcing the mental map of “detail on the right, list on the left”, or the “master-detail” view that we’re all familiar with. Although we don’t currently have the benefit of sliding animation in FileMaker (with the exception of slider panels on the Mac and iOS), we can still reinforce the mental map by using arrow icons on buttons. From a Customer list view, I’ll place a clear button (i.e. no color fill, gradients, or outlines) over the row that navigates to the detail view. At the far right end of the button I’ll place a simple arrow icon, which implies that the Customer detail is to the right. When I arrive at my detail view, there’s a button in the upper left corner, with an arrow pointing to the left, that says “Customer List”, implying that the List view I was just on is to the left. These reinforce the user’s mental map, in which they begin at the dashboard, click customers, then click a single customer. They’ve “moved” from left to right. When moving back up the chain, all icons point to the left, reinforcing the movement back from right to left. And moving from left to right, they can build a mental map of All>Some>One, which is not unlike navigating a hard drive, where the user drills down from hard drive, to folder, to file. Remember the Mental Map Designing an intuitive interface for your app is probably the single most important element contributing to the successful adoption of your software, as a database system is only as good as the user’s ability to get at the data. If they have a hard time wrapping their head around how it all connects, what the relationships between tables are, and how to get the right data into or out of it, then it will be of no use to them. They’ll probably find something they can more easily grasp. If, however, your user can easily build that mental map, they’re much more likely to feel comfortable using and understanding the software, and if you can make that mapping process effortless, all the better. Having a few go-to techniques to help reinforce the mental map can be especially valuable for projects in which the development time is limited, but as a software UI designer, you should always try to have foremost in your mind your user’s perspective, and remember to help them create their mental map. If you’d like to learn more about UI design from us, check out our upcoming class offerings. By David Weiner
2 Comments Hank Shrier Posted on 11:45 PM - February 3, 2017 Nice explanation and good info. To keep the context for users, I have a single layout for each of the rooms from the home page. To display different related information, I use clearly labeled popovers to display related data. The popovers are in the same order in each of the “rooms”. So when a user looks at Customers, or a user looks at Staff Members, the buttons are in the same place and in the same order as they are in other similar sections. All the layouts and buttons in these sections use the same color throughout the application. Do you think it would make sense to set the colors of the sections to match the color of the button used on the Dashboard? Thanks for your informative article. David Weiner Posted on 5:41 PM - February 5, 2017 Yes, actually, I think assigning color to a context can definitely make sense, as it can help the user to immediately distinguish one location from another. Once the colors are solidly associated with a certain context in the user’s mind, use of that color will link the object (like a button) to that context in the mental map. I’d be careful about using too much color, though, and never use color unless there’s a specific reason to. Use of color in a UI should never be arbitrary, lest you end up with the “angry fruit salad” style of user interface. Any color in a UI should convey information: Blue text might signify a link, for example, or a yellow field might signify a missing required value, and red text usually signifies a negative result or important information that needs to be addressed. None of those color choices is arbitrary. If you can’t give a definitive reason behind a color choice, then just don’t.