Another benefit of coming to WritersUA is that it’s helping me write my new novel, Amiga. There’s a scene where my narrator is looking at Workbench, the Amiga user interface, for the first time. He is perplexed when he looks at the screen. (Keep in mind that this happens in 1985 when windows and icons were new things.) He asks his colleague, “What do I do now?”
Nearly 30 years later, we’re asking the same questions when confronted with new user interfaces. Our challenge as technical communicators is how we can provide answer that question for our users. Here are some tips I learned from today’s sessions at WritersUA.
Put Information Where People Will See It
“Wee Willie” Keeler‘s quote, “Hit ’em where they ain’t” works well for baseball. In technical communications and user interface design, we want to do the opposite: Put important items where the user will see them.
In “Techniques for Crafting UI Text Based on User Reading Patterns,” Linda Lior provided the results of research into eye tracking and mouse clicking to determine where people look the most on a screen. Our eyes tend to follow an “F” pattern when scanning a screen. We look at the first line all the way through, and then our eyes trail down the left side of the text with decreasing frequency as we go further down. (In right-to-left languages like Hebrew and Arabic, it’s a reversed “F” pattern with eyes scanning down the right.) What are people looking for? They are searching for keywords that help them identify the information they need.
Not everyone scans text this way. Some cultures prefer reading text word for word, as do older people, and those who are looking at new or unfamiliar information. In both cases, we have a better chance to get our important information noticed if it is at the upper left part of the screen and go for lists over long blocks of text.
Get Users Involved in Interface Design
John Alwein shows how to design more effective apps using task-oriented design, but the biggest takeaway from his talk is to get the users involved.
He showed the process of how his group designed a new mobile app. The most important thing he did was to get his prospective users involved in the design. He learned that they preferred looking at PDFs because they included diagrams they can use as anchors for finding information. He also considered how the app will be used. For example, it is used where WiFi might not be available, so documents had to be downloaded so they are available offline.
As a result, Alwein’s team developed an app with innovative and useful features. Users can use their smartphone’s camera to view flashing lights from the equipment they are fixing. The app can either display the error indicated by the light. If the flashing lights cannot be detected, the apps take users to an interactive screen that helps them identify the type of error.
All of these useful features wouldn’t have been available had Alwein and his team engaged their users. He said, “Sometimes, we think we know something we don’t really know.” The way to find out is to learn how the software will be used and get feedback from those who used them.
Follow and Take Advantage of Industry Standards
In designing interfaces, we have to follow the guidelines and rules set out in the operating system where the app will run. Such is the case with iOS for Apple mobile devices, as John Collins explained.
He showed how the user experience with an app begins when users start searching for it in the Apple App Store. The ease of searching for the app and the information that appears when the user finds it sets the user’s impression of the app. Although Apple controls what appears in the App Store (and has rules on what text you can put in it), we can use those rules to our benefit. Collins showed how we can make good decisions what text appears in the description before the “more” link. We can provide enough information to entice prospective users to read more or buy the app without reading it.
In order to take advantage of those standards, you need to understand how the operating system works and know its rules. You also need to adapt to different systems (such as if you want to provide the same app for Android.)
Know Your Users
Throughout WritersUA, the same theme has been hammered through by almost all of the presenters: Know your users. Learn their needs and what they want from the product and documentation. Don’t do things because that’s the way you’ve always done them or because your organization is structured so you’re only allowed to do one piece of the product. Design the product around your users — not your tools, not your methodology, and not your org chart. Answer the big question all users have, “What do I do now?”