Category Archives: Design

ROI on User Centered Design

You may have heard that User Centered Design (UCD) costs more up front. Project Managers have definitely heard it, and sometimes, they’ll balk at a new approach based on cost alone. In response, you’ll need to give those PMs some arguments they can use to make a case for UCD to their bosses.

When users are involved in development from the beginning the project is much less likely to fail because:

  • goals and requirements are clearly understood by all parties
  • goals and requirements are reiterated throughout the development process
  • if goals or requirements change, then the delivered software can match the the moving target of shifting goals
  • users need little or no training because they’ve been testing and using the software BEFORE launch
  • testing undercovers more bugs before launch, which gives you time to fix them when it’s less expensive
  • tech support costs go down, due to fewer errors

All these items are above-the-line costs. You can quantify the savings when a project launch requires less training and tech support. If there are bugs that cause downtime or financial errors, it’s easy to see how much that would cost.

And that’s just the internal ROI. If the software is for online shopping carts, or retail order fulfillment, then you can include an increase in sales after the software is launched in the ROI calcualtion. Don’t forget the ROI studies specifically on document management have estimated that up 30% of a person’s work week is spent looking for the resources they need. So the ROI on that software is 30% of each user’s annual salary. So that’s the business case for User Centered Design.

But don’t forget the intangible, below-the-line ROI of having passionate users who are now more effective and efficient at their jobs because you’ve created a great user experience for them.


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.

Giving Users Feedback

No matter what type of database you’re creating, at some point you’re going to find an occasion to employ some sort of method to let your user know they have made an error or neglected to fill in a required value. One method of achieving this goal is through the use of a custom dialog. Another is to use a global variable ($$message) in a merge variable.

At first glance, it may appear that this is more work than using a custom dialog, but the advantage is that you only have to write it once for each database and you can re-use it whenever you need an error message.

Place the merge variable in prominent location in your layout (or in a popover) and give it a red color to draw attention to it. When the $$message variable is empty, it will be invisible. You don’t want a lingering reminder when you use it, just a timely message. So the only real task after you use it to send a message to the user is to empty it again.

This is done with two small scripts. In our examples below, the first is named “Set $$message.” This script is using MultiParam (as opposed to Get (Script Parameter) ). If the error message you want to send is “A value is required for Name,” your script parameter would be:

“message = A value is required for Name.”

Alternatively, you could set a variable ($error, for instance) with the content of your message. In this case, the script parameter would be:

“message = ” & $error

The “Set $$message” script beeps (to give audio and visual feedback), sets the $$message variable to the value of your error message, then uses the Install Timer Script to call the “Clear message” script after 8 seconds. It includes a Refresh Window step just to make sure the $$message is redrawn.


The second script is “Clear message,” which clears the $$message variable, refreshes the window, and calls the Install OnTimer Script step without providing a script or a timer value, which  clears the timer.