Define: User Experience

Category : FileMaker , User Experience

The term User Experience (UX) is usually applied to developing startup app companies or web services where there may not be an existing market. In those cases, the company doesn’t have a customer base yet, but they’re using the principles of UX as part of the whole package they’re offering to prospective customers. These new websites and apps are changing our mental models of how software should work. Even if your users have never heard the term “User Experience” you can be sure they have worked with software built on its principles and have expectations about how software should look and feel.

But UX principles aren’t just applied to the web. Retail stores and restaurants and even physical products are paying attention to how the user feels when they interact with them. Some UX specialists analyze how people feel when they walk into a store or restaurant, and then give owners ways to improve the UX, and strengthen the bond with their customers. Some of those principles, like the aroma of cooking food, or the physical display of products at a store’s entry, aren’t directly applicable software UX, but you only have to twist the concept a little to make it fit.

Your software can’t give off the comforting smell of cinammon when a user launches your database, but they’ll form a first impression nonethless. They’ll be watching how your database launches, and what you’ve chosen to show them from the moment the first window is drawn and data starts to display. They’ll be looking at speed, and arrangement of data, and whether the tools they need are easy to spot and simple to use.

So it makes sense to understand how and where we can apply them to FileMaker design and development. First, let’s define a few terms that represent design specialties under the broader umbrella of UX:

Visual Design is the look and feel of the user interface. It’s the graphic choices you make on your layouts. Visual design includes colors, images, fonts, and symbols. It’s usually the first thing people notice about your software, and it’s the part of UX that most people are most comfortable talking about. But while good design choices are a big part of overall user satisfaction, it’s far from the only thing users experience. All the following terms are also part of UX, but they’re a little harder to grasp.

Information architecture is just what it sounds like and a little more besides. It refers to how the data in your software is organized for storage, but it also refers to the way that data is presented to your users. Does your architecture match users’ mental models of their data? Does your presentation match their work flow?

A subdiscipline of information architecture is Structure. You already design tables and records for good normalization. But structure also refers to the way data points relate to one another. What’s the context in which they’re presented, analyzed or manipulated? Does your database’s structure make it clear to users how the data is related? Is it easy for them grasp how a list of contact methods relates to a single person’s data?

Information refers to your data, but also to metadata that describes or enhances that data. In FileMaker, metadata might be things like creator and creation date data, or filetypes and paths in a document storage system. The term “information” also includes the business rules that describe how you gather and treat your data. How are discounts on invoices given? How and when are receipts issued? Who can void an Invoice?

Users need to be able to Find and Manage data. FileMaker gives us good native tools for finding and displaying data, but we often have to create custom, scripted Find processes to make it easier for our users. For an even better UX, we can think of ways to show the user what they need without entering Find mode. For example, you can show users with a list of their daily appointments when they log in, or the open items on a To Do List.

Interaction Design is how your database behaves when users navigate to a layout, click on a button or need to scroll a portal or a field. Again some of FileMaker’s interaction design is native. Portals have scroll bars for viewing a long list of related records. We can show active record states or active portal row states as highlights to help users keep their place on screen as they work with lists or portals full of records.

Affordance is a specific type of interaction design that refers to feedback from the system that makes it feel responsive to the user. Active record states and object states (normal, hover, pressed, and in focus for buttons, for example) make a database affordant—users see objects respond as they explore a new interface with their mouses. Affordance makes a database feel responsive, but it’s also a teaching device. A field that highlights when you click on it is inviting interaction from the user and makes the field’s purpose a little more clear.

All the above design choices add up to create Usablity. Can your users get their jobs done more easily with your software or does it stand between them and their work? Have you created clean, uncluttered layouts that present data efficiently? Are buttons easy to find and use? Is the system reliable? Can users trust it or does it have performance or stability problems that make it slow or difficult to use?

In a big development firm, specialists in each of the disciplines  might collaborate on every project. If you’re on a smaller team, you might have to switch hats. Even if you’re a one-person development shop, you may focus in a few of these specialties. But just understanding these terms, and how they can affect UX, will expand your set of design tools

Don’t Blame Users

Category : FileMaker

When things go south in your software, don’t blame users. Let me tell you a cautionary tale about what that blame does to user experience. I’d gotten an email from a vendor that I already had had a good experience with. They were promoting a new product that looked interesting so I clicked on the link, watched a video, read some marketing stuff and decided to buy it. Pretty good user experience, right? If had one of those satisfaction monitors that some of the reality shows have, you know those dials where you can dial it up to show you’re happy or dial it down to show you don’t like what’s happening. Well, I was well into the good zone.

Everybody knows how to buy something online right? We all have what are called “mental models” of how online shopping works. Mental models are extremely important in UX/UCD, and the idea is that we think we know how something works because we extrapolate from something else. Maybe it’s another online retailer, maybe it’s some instructions we read, maybe it’s what somebody else told us. Anyway, my mental model was that I was going to click somewhere to add this software to my shopping cart, and then there’d be some kind of payment dance, and when I was done, the download would start.

So the software is in my cart, no problem. But there are two buttons for payment: one button was for using PayPal and the other one was for using PayPal to pay with a credit card. And really the last thing online retailers should want is to slow users down by making them think about which payment button to click. What if the effort of having to think about which button to click slows me down just enough to interrupt my purchase?

But I clicked the second one and went through checkout. It was one of those sites where when you purchase something new it appears in your account for downloading. But nothing new showed up in my account. That glow is dimming some more.
So I figured I’d done something wrong (now I feel stupid AND not as happy as I was five minutes ago). But I still wanted the software so I went through the checkout process again, this time successfully. (Light’s shining a little brighter now). All was well until I checked my email and got two notices from the vendor and two notices from my charge card company. What do you think that did to my software therapy afterglow?

But the vendor provides good UX because my account page has a contact us button on it, so I explain the issue in an email and trust them to handle the problem. I figure it’s just a matter of them sending me a refund, and then we’re all on our way.

Now I’m sure the customer support person didn’t make the confusing buttons on the company’s website. But she still provided some pretty poor UX in her email to me: “I see the issue now. You should have followed instructions….”

Blaming users when the software goes wrong only compounds the problem. I design software for a living. I figure that I know how developers think and that I can work my way through most systems. But their ambiguous button naming was the problem. And then they blamed the me for getting confused.

You can have great software and then completely ruin a user’s buzz with blame-y customer support. But here’s the truth—if the user gets confused in my software, it’s my fault for not creating it the right way. I’ve got to put on my big developer pants and figure out how to keep them from getting confused. That might mean better button names, better feedback, or a completely different process. If I’m in regular contact with the users during development,  they’re going to tell me what doesn’t work early in the process so that I can fix without a big impact on the schedule and budget.

Demo and Discovery

Define: Demo and discovery

Demonstration and discovery is what we call the regular meetings we hold with our database manager and the stakeholders (who might be the whole user group, or a representative sample). It’s where we figure out the details of the use cases we’re developing. Back when I started developing in FileMaker, we used the old school development method called Waterfall.


The old school process puts huge effort into writing these detailed requirements that describe everything about the database, including what every single function should be and often even every step the software will take to get each job done. Since so much effort goes into creating them, the requirements are committed to stone, and they are rarely changed during development. In this process, production is the king. The thought is: we have a product outlined and we know exactly what it needs to do. Here’s the document that describes what we know, now you go off and make it so. This process is called “waterfall” because from concept to requirements to handing off to a developer, the process moves forward for really long time before there’s anything you can demonstrate or test.

In this scenario, the user may or may not have been involved in creating the requirements. Old school development is agnostic on that point. A manager, or an engineer, may have written the requirements. But even if end users had input on the requirements documentation, they don’t come back into the process until after development is done and the whole database is ready to test as a unit. Users test, somebody consolidates their feedback and gives it to the developer, who fixes the bugs (the ones that were found), and the project is deployed. Waterfall development can leave lots of bugs because it’s really hard to test a whole software program at one time. So often, the deployment phase—with live data and sometimes harried users—has multiple bug fix/maintenance releases, and while that’s happening, the product gets analyzed for new features, new requirements are written and the process starts over for the next whole number release.

New School: Agile

So in response to waterfall’s weaknesses, a new school of development, called Agile, started to gain traction. Agile is so widely used these days that’s it surprises me a little to remember how revolutionary it seemed at the time. Waterfall development can feel constricting because you’d often learn something in the course of development that cries out for changing the requirements. But if you do change requirements, all that time spent up front refining detailed requirements is wasted.  The engineers, marketers, and managers who’d spent so much time on developing requirements worried that their analysis would be thrown out the window if requirements were allowed to change along the way.

Here’s how Agile development works: you still start with a specific need for a piece of software, and requirements are written. But they aren’t detailed. Agile requirements describe what the database needs to do, but not how it will get those tasks done. Now the first thing that happens is that a team of requirements folks (which should include users or user proxies) meet with the development team and they analyze a small set of the requirements. Those are developed, demoed, tested, and bugfixed. Then the team bites off another chunk and runs the analyze, develop, text process again. But in this cycle, you get the benefit of whatever you learned in the first cycle. You might have thrown some sample data into the prototype database and found out that the original analysis about structure or how some feature needed to work was wrong. So you bring that up at the next analysis meeting, figure out how to adjust and move on. This cycle gets repeated with new requirements until the whole package is built.

With Agile, the software has been tested, bugfixed and improved throughout the whole development process. Bugs and errors are fewer and less serious at deployment. It’s true that the package often looks fairly different than the original concept, but it tends to ends up with more satisfied users because of the benefits of iterated development.

Omit Needless Words

Appropriate feedback is critical to creating a good user experience. But was does “appropriate” mean? It’s a given that you need to let users know when an error occurs. Sometimes appropriate feedback tells them that everything’s just fine, for example “Results: 17 invoices were processed.” Be thorough and consistent with your feedback. But don’t be verbose. You wouldn’t write bloated code, and you shouldn’t write bloated messages.

This way of thinking is relatively new to me. And I didn’t come up with it on my own. One of our clients drove this point home to me. She jokingly yelled at me while she was testing a new script, “Don’t waste my time with all those extra words!” I’d given her a well-worded and dynamic message telling her something like “Your email to Constance Sorrow was sent.” I didn’t think it was all that wordy. Sure it’s passive voice, but that construction is shorter, and doesn’t try to anthropomorphize the database by saying something very silly like “Friendly database here: I sent an email to Connie Sorrow.” Anyway, I thought the message was a model of brevity already so in the name of friendly discussion I argued with her.

“I know who I just sent the email to. I just need to know if it went out or if I have to do something to fix the problem. Just tell me ‘Email sent.’ I don’t even need a period hanging out there. I just want to flash on that message and get on to the next thing.”

She didn’t want complete sentences. She didn’t want objects. She wanted one noun and one verb. It’s not second nature to me yet. I still have to remember to edit messages to make sure they contain the basic information, but no time-wasting extras. But for most users, this is exactly the right way to give feedback – short, simple, clear.

Like all design solutions though, make sure you know your audience. This type of brevity works well for sovereign apps (those that users work in all day/every day). Those users know what to expect and are waiting for it. Less sophisticated users may need more handholding, and for them, extreme brevity is actually harmful. If you’re not sure what category your users fall into, ask. That’s what demo and discovery meetings are for.

Call yourself a designer

Category : Design

Designer defined

Do you call yourself a designer?

Even some FileMaker developers who are known for their beautiful database designs take pains to say that they aren’t designers. There seems to be an idea in our community, and maybe in the general software community, that developers can’t be designers. I think that comes from the misunderstanding that all design is Visual Design or Graphic Design. Or maybe it comes from large software development teams where there’s an information architect and a coder and a developer and a sales person. In that type of setting, people may not switch hats often and they’re highly specialized. But smaller teams, even one person “teams,” is more common in the FileMaker community. So some of the more formalized approaches in use by teams might seem out of reach because of human resources, budget or schedule. Even if you don’t adopt a full scale approach, there are lots of lessons to be learned, tools we can adapt to FileMaker and to small team development.

Design is the first signal of human intention. If you woke up this morning with an intention, you’re a designer.
– William McDonald, architect

Design = Planning

Design = Making Choices

Design = Intention

If you have an intention towards your database—the way it works, how it serves your users, the way you assemble the hidden parts that no-one but you will ever see—then you’re a database designer.

Does it matter if you call yourself a designer?

Human beings work in categNameYourselfories. Once we file something away in a category, it solidifies the way we think about that thing. We rarely take that thing back out and reexamine it. Try re-categorizing your work as design. So thinking of yourself as a database designer, instead of a developer, can change the way you approach problems. It can make you more creative and help you move away from the old solutions you gravitate toward.

Give Users Feedback with Merge Variables

Much of what happens behind the scenes of your scripts is, and should be, invisible to your users. But there are times when you need to give feedback about what’s happening. If a script can’t process an invoice, or is finished marking a found set of records, it’s common to use a Show Custom Dialog script step to tell users what they need to know. But there’s a problem with this step—users have to stop what they’re doing and click OK to make the dialog box go away. That violates at least one rules for creating good user experience: Don’t interrupt your users.

Fortunately FileMaker gives you other ways to give users dynamic information without using a pesky dialog box. You can set your message into a merge variable with an install timer script set, and then clear it back out again with a second one. This process is so useful that we include a pair of scripts for this purpose in every database we design.

Here are the steps you can use to set a message:


It’s a good idea to give users audio AND visual feedback, so the script starts with a beep step to get their attention. Then it parses out a message that you send to the script as a parameter. If you’re using the method described in the link above, your message needs a name and value pair, separated by an equals sign. Use this syntax:

message = Email Sent

And to make sure users don’t have to hunt all over their interface to read the message, put the merge variable in the same spot on every layout. This should be such a integrated part of your design routine that that you plan for it from the beginning of a project. Figure out where to put the merge variable, and then format it with whatever red color you’ve chosen for the solution to give another type of feedback that says: This message is important.

So this short little script makes a noise, shows a brief message, and then does its own housekeeping so the user doesn’t have to do anything to make the message go away again.

Here’s the script you can use to clean up afterwards: