Category Archives: User Experience

ROI on User Centered Design

Category : Design , FileMaker , User Experience

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.

 

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

Omit Needless Words

Category : Design , Development , User Experience

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.

Give Users Feedback with Merge Variables

Tags :

Category : FileMaker , Scripts , User Experience

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:

 

Giving Users Feedback

Tags :

Category : Design , Development , FileMaker , User Experience

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.

SetMessage


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.

ClearMessage


Archives

© 2019 DBHQ, LLC