Wednesday Jan 19, 2011

Language and Usability: It Doesn't Have To Be That Way. And It Shouldn't

I enjoyed this very telling comic strip about how some usability professionals might regard language when it comes to designing the user experience:

" for the text... just copy something from Wikipedia and polish it up a bit."

However, it's unfunny because very often it's true. Still don't get it? Read the comments of some of our sales folks, partners, and customers (names have been removed to protect the innocent):

  • "When the language is IT-speak and not normal speak, it is part of the usability problem." 
  • "When users know what things mean, they're halfway there. When options are 'simple' English, it's obvious where to look and what to do... the language for users must be clear and helpful." 
  • "The quality of language in the user interface (UI) is a deal breaker."
  • "The competitive playing field has changed since the old days. Customers even do their own usability testing and include language heuristics now. It's a competitive issue."

So, in Oracle Fusion Applications we've spent a great deal of time getting our language (terminology, style and grammar) right for our users. Developers don't create the language you see in the UI or user assistance. There is a comprehensive terminology creation and management process and a multi-stakeholder review process for all UI strings, messages, and help content. Language is a user experience issue and that's why we continually invest in our information quality efforts. We have to. It's a strategic competitive issue for sales and as a productivity issue for users when they work. Watch out for more information about information quality in Oracle Fusion Applications on this blog in 2011.

Wednesday Aug 18, 2010

Changing Language

Interesting post from the BBC about how the internet influences our language, citing examples from English, Ukranian, and more. How does this influence users of enterprise applications? What are their expectations about terminology and phrasing?

Only one way to find out. Ask them!

Saturday Aug 14, 2010

Frequently Published Questions

We're all familiar with the concept of the Frequently Asked Question (FAQ) type of user assistance. But I have a question of my own, infrequently asked: "If it's a frequently asked question, then why?"

Frequently Asked Questions, to me, may indicate that it wasn't possible to execute a completely intuitive user experience, this time, for some categories of users. However, if a question is "frequently asked" then it also makes sense to treat it as a requirement gathering exercise; an opportunity to improve the usability of the interface as quickly as possible using the information in the FAQ itself.

FAQs are about performing tasks directly, of course, but they go beyond the straight "how-to" procedure. Some may explain the meaning of something, the consequences of a decision in advance, or the downstream consequences of a task that a user may need to know before acting, and so on.

EBS R12 Procurement FAQs

Oracle Applications Help System (EBS) Procurement FAQs 

There's a need for these sorts of orientation and affirmation/confirmation topics during task usage, but any notion that "What's this for?" "Or how do I do that?"-type FAQ topic should persist for very long in the age of agile development, or in any great numbers, makes no real sense to a user experience professional.

Let's be clear here. I am not saying that FAQs never need to be written and published. They do reflect the reality that you can't design and build everything you want all the time. Some operations may have to remain complex, some things may note be so easily learned or remembered, or there may be other reasons to write about.

But ask yourself: How often are FAQs refreshed? And what process is in place in your organization to review and eliminate existing ones? Every task-based FAQ should immediately trigger an associated enhancement request or product backlog item added to remove the need for the FAQ topic through superior design, testing, or development. Indeed, FAQ topic value should be measured through reviewing webserver logs, feedback, ratings, and user conversation, too

Plus, If you find that your customers are writing FAQs and distributing them across in the community, without reporting issues to you, then you need to do some real thinking about your user experience methodology and how you obtain feedback on user assistance or approach the notion of information quality.

Otherwise, frequently asked questions are just perpetually published answers.

Language Should Never be 'Plain'

I see a lot of UX professional debate on the subject of plain language. Many of these arguments are decontextualized. They often import personal frustrations from filling out government forms in the US or EU, anecdotal evidence about technical error messages, and so on. This is not very helpful for making a case about what language user assistance should use for the enterprise applications user experience.

Sure, we must communicate ideas clearly and succinctly, but we must also do so using the terminology of the target audience's roles,expertise, and how they actually work. Generalizations about plain language certainly seem very reasonable when we discount such variables, aren't they? Often we see recommendations made for one design context that simply don't apply in the other.

The most notorious one in the user assistance area is the conflation that all online users read publicly available web content the same way that they would read content in the enterprise space (for example the "golden triangle" or "F-shape" argument). These findings do not hold true in the enterprise applications world.

Same for language on the web. Instead of talking about some globally applicable 'plain language' being required by all users, the discussion needs to move in the direction of information quality, and away from the dominance of internal linguists, and towards the conversations in the user community.

Information we deliver in user assistance components should reflect the needs of the user and how they work. We must use terminology that our users recognize and use consistently when interacting with the UI, searching, reading online, and most importantly, when they seek help or help each other. Getting your terminology right is central to information quality.

Engaging the user community and their conversations is key to this. On one level, it's easy. Why call "breadcrumbs" something else if the term is widely accepted in general use? Or why say "Enter a valid password" when you can say "Enter the correct password"? And, then, of course, we have some language used without thought of use at all (like "OK" in dialogs instead of more meaningful button options).

But, in the enterprise space with such a broad range of domain expertise and many possible roles, involving specialized vertical, functional or technical expertise, additional layers of complexity are added to our choice of words. User experience is about knowing who our users are, so use that research.Terminology, and therefore language, can hardly be 'plain'. This is an area that interests me greatly.

So, stay tuned to this blog and the usableapps website  for news about UX developments concerning language and user conversations.

Monday Jul 05, 2010

Information Quality

When we talk about user experience, it's important to remember that the language (the terms, or words we use to call things) on the page is as critical as the page design and other components on it. As well as taking into account the business process and task flow of the user, we must take into account how what terminology and style of language would be best for their role too. And, of course, it must work globally too!

Oracle pays a lot of attention to information quality, and I'm pleased to say we spend a good deal of time researching terminology as well as managing it for use in our product deliverables. Language changes over time, and we need to be cognisant of the challenges that the social web presents even in the enterprise space too.

For those who'd like to know more about the social web challenges, then check out the video "Get Ready for Socially-enabled Everything". And if you're interested in information quality, then take a look at this video from the folks at Acrolinx. Oracle has licensed the Acrolinx IQ suite and I am proud to say that my team is leading the pilot implementation.


If you'd like to know more about terminology and language quality at Oracle, feel free to reach out to me through the comments or Twitter (@ultan).

Monday Nov 09, 2009

Welcome to the User Assistance Experience

In this blog, I'll cover all sorts of issues relating to what we call "user assistance" in Oracle Apps - messages (all sorts, errors, warnings, and more), embedded help, and nonembedded help, demos, and more and how users collaborate with each other to help themselves. I'll focus especially on the design and deployment of user assistance, and how is relates to user experience in general.

For now you might like to check out a recent usableapps posting about the use of writing patterns.


This is just one of the exciting approaches that Oracle uses to the design of user assistance components.


Oracle Apps Cloud UX assistance. UX and development outreach of all sorts to the apps dev community, helping them to design and deliver usable apps using PaaS4SaaS.


Ultan Ó Broin. Senior Director, Oracle Applications User Experience, Oracle EMEA. Twitter: @ultan

See my other Oracle blog on product globalization too: Not Lost in Translation

Interests: User experience (UX), PaaS, SaaS, design patterns, tailoring, Cloud, dev productivity, language quality, mobile apps, Oracle FMW, and a lot more.


« July 2016