Laws and Myths of Usability & Interface Design

Laws and Myths of Usability & Interface Design

Introduction

Usability and relevance have been identified as the major factors preventing mass adoption of
Business Intelligence applications. What we have today are traditional BI tools that don't work
nearly as well as they should, even for analysts and power users. The reason they haven't
reached the masses is because most of the tools are so difficult to use and reveal so little
about the data that only power users are willing to put up with them. Just as Google redefined
the web by making search and therefore access easy … the same needs to occur with the BI
suite.

Overwhelmingly, traditional BI products are designed for the technology expert. The perceived functionality requirements are driven by widget wish lists
rather than actual business user (the BI consumers) needs.

Our design philosophy has been honed through experience and results in a simple equation:

Usability = Simplicity + Unity

This paper is a reflection on some of the design approaches used in the development of
Yellowfin. Its purpose is to provide an insight into what makes web based applications ‘work’
and how Yellowfin will continue to evolve and improve. The principles are defined by 5 laws
and 5 myths.

The laws:

1. Simplicity – the art of Zen and interface design
2. Strive for internal and external unity
3. Innovation stretchs engineering capability
4. Everything changes except change itself
5. First impressions count
The Myths:

1. Form follows function
2. Only users know what they want
3. Involve many people in your design process
4. Usability testing will ensure a great UI
5. You can’t live without rigorous design processes
At Yellowfin we use the principles outlined in this paper to continue to deliver innovation,
improvements and what we hope is an exceptional software experience for our customers.

#1 Simplicity – the art of Zen and interface design

Users want simplicity! They want to do the job they need to do with the minimum of effort and
complexity. Users must be able to perform their most frequent, most important tasks without
any resistance. This means:

1. not having to spend time sifting through an array of irrelevant options, and
2. not having to browse help files or a manual to accomplish simple tasks
The goal, then, is obvious: to maximize performance while minimizing confusion. But as
vendors and users are discovering, that's no small trick. Simplicity is sometimes the least
simple thing to achieve." 1

Simplicity requires that your code does all the hard work, rather than the user. Google, as an
example, maintains the simplest of search interfaces. No distractions from blogs, news or
ads, you simply type in your query and go. Behind this simplicity is up to 500,000 computers
globally linked and participating in answering your query. In essence, one of the most
complex hardware/software systems on the planet is hidden behind a very simple webpage
that is virtually 100% whitespace.

Deliver the right level of blatant functionality to suit user skills

The most common UI issue in report writers is BOS (Button Overuse Syndrome). If there is a
formatting option, or any option for that matter, then traditionally it needs a button. How
wrong can you be! BOS delivers too many options and results in a user confused by choice.

The cure for BOS is UI simplification through minimalism – the art of Zen and interface
design. Focus on what users do 90% of the time. Chances are your users will not mind using
a drop down menu or popup forms if the action they are performing is not regularly repeated.
Provide buttons for those actions that are regularly used and then drop down menus or side
panel menus for all the others. Whatever you do, keep the interface simple and consistent.

Of course the level of competence of your user will influence your design decisions. An
example of a product that is tailored for user sophistication is the video camera. Consumer
versions have lots of functionality but hidden in layers of menus, whilst professional versions
tend to be button centric to allow rapid access to all the functions desired.

Taking this lesson into account we have designed the UI specifically to suit the technical
ability of the average user. The interface is made more flexible through role based access,
where greater control is exposed as technical proficiency increases. For example the report
writer (a business user function is menu driven) but the more technical metadata layer is
panel and options driven.

Simplicity in everything you do

To ensure consistency in your usability message simplicity needs to be addressed at every
interaction with your application. This includes commonly overlooked areas such as
installation and version migration. Consider these as you would any other interface task.
Minimise the complexity and pain!

The following blog illustrates how non-core activities can alienate your users. “I use Crystal
Reports and have been since Crystal 6.0. I have a love/hate relationship with Crystal. I love
the reports I am able to create. I hate when I am forced to delve into any new territory with
them…..The worst was the nightmare upgrade to Crystal 8.…. All of my apps were broken. I
spent innumerable [unbillable] hours fixing applications and on the phone with [very unhappy
yet thankfully, patient] clients trying to get the proper components installed...2”

1 http://www.cfo.com/printable/article...0503?f=options
2 http://weblogs.asp.net/jlerman/archi.../08/48515.aspx

#2 Strive for internal and external unity

Internal unity provides the user with a sense that the application is cohesive – it is a feeling
and an emotional response to your product. It is easy to fall into the trap of developing a
disjointed application when multiple development teams are involved. Unity requires a large
amount of focus, determination and discipline.

With every release we do at Yellowfin our development team must ensure a sense of internal
unity exists within the application. To this end we focus on the following elements:

1. Language There should only be a single term or phrase used to refer to
any given item in the application. An item here may refer to a
concept, a business function, or task, or even a widget, or
individual interface element.
Language should be concise and easy to understand.

2. Icons Like language icons convey meaning. They tend to be
universal and have a far larger impact on your users
understanding of your application than text.
Icons need to be consistently used, for example only one
image used for delete, and they need to be used sparingly.
Given their high impact, only use images when you wish to
bring an element to your user’s attention.

3. Actions Common user tasks can be used across your application. For
example Yellowfin has an ‘add to list’ action. This action
needs to have a similar styling to prompt the user into
recognising the action that they are being asked to perform,
especially if multiple user actions exist on a single form.
At Yellowfin we have chosen to join the selection box to the
list box with a common border – to emphasise the unity of the
two elements on the screen.

4. Styles Probably telling most people how to suck eggs – but the
rigorous use and management of styles to ensure continuity is
critical. Common field sizes, text size etc all help to convey
unity to the user.

5. Positioning Ensure that the positioning of key elements such as tables are
consistent across the application. One of the main design
issues that leads to an unfavourable user perception is if as
they move through your application, tables appear to move
about the screen.

6. Highlight Zones We use this technique on multiple forms within Yellowfin. The
‘add to list’ box is one example of this type of UI element, but
we use highlights across many forms where we wish to draw
the user’s attention to a specific action on a form, such as
submitting or changing their password. The highlight is used
to convey a sub action on a more general form.

7. Validation Whenever possible the UI should prevent the user from
making a mistake instead of alerting the user to the mistake
after the fact. This must be achieved without the UI getting in
the way of the user.

External unity provides users with a sense of comfort

External unity incorporates elements into your UI that users expect based on their
experience with other web applications. You need to assess what the ‘thought’ leaders in
software development are doing and whether the direction they are taking the user
experience is relevant and appropriate for you. Never just focus on your competitors but look
at what other great technology products are doing to solve common problems.

There is a trap with this though. You do not want to mimic a ‘standard defining’ application,
the reason being that:

1. If they change their design radically then you are left with an Interface that can rapidly
be outdated.
2. If the product has a design flaw you may inherit it too.
3. You have no clear product differentiation – especially if the original product is a
competitor.

The report writer market is a crowded and yet the vast majority of applications have pretty
much the same interface. Crystal has defined the standard for banded report writers, and
there are many applications such as iReports for Jasper which have been developed as an
alternative to Crystal. These alternatives have not reinvented report writers, or addressed the
fundamental design issues that exist. Their only differentiator is price. The first question we
asked at Yellowfin was “Why a banded report writer?” We could not think of a compelling
answer so we threw away this paradigm and started with a clean slate.

Apply the unity principle to your entire suite of products

The law of Unity extends beyond the core application itself. More often than not we see the
complete opposite in practice. Software companies that acquire complementary software to
enable them to offer the ‘complete’ product rarely ensure a high level of integration and unity
across all products.

Microsoft, Business Objects, Hyperion and Pentaho share this problem. They have a range
of products to solve specific BI problems, yet the lack of UI integration results in complexity
and usability issues when trying to deliver end-to-end functionality – great for consultants,
poor for the customer. Distinct report writing interfaces (for desktop and web), separate
dashboard builders, OLAP analysis tools, metadata layer management and ETL, these may
tick all the functional boxes yet none share a common UI paradigm and each has its own
unique interface. The end user suffers - requiring additional training and time to manage the
complexity and deployment integration.

#3 Innovation stretches engineering capability

If it can’t be done then it probably worth while doing – this could be your single point of
difference. The software industry is a maturing market. It is becoming harder and harder to
imagine new applications for software, and there are a plethora of functionally similar
products on the market be it ERP, CRM or reporting. Why do people continue to develop new
software packages doing the same old thing? Either they are completely mad or they think
they can do it better (or a little bit of both).

As the creator and innovator of new software one of your functions is to imagine a better way
of doing things - a way, that will appeal to the end user, and convince the buyer that your
product is superior to everyone else’s. It is the software engineer’s job to make this vision
happen.

At Yellowfin our design philosophy is to continually extend the capabilities of a pure HTML
interface and provide the end user with a traditional GUI type experience. This is a double
edged sword as users must not be given Graphical User Interface (GUI) expectations that
cannot be met (or only be partially met) within a Web User Interface (WUI). Whenever GUI
expectations are set, they must be fully met.

One of the major advantages Yellowfin had was not being anchored by a legacy GUI version.
While excellent in some ways, the GUI is constrained by a single workspace. The typical
GUI was never developed with workflow in mind and is not really supportive of this paradigm,
yet Web based applications are free of this and users can be easily (and expect to be)
directed through process flows. One of the great benefits of the web is that your application
can take advantage of the best of GUI without the baggage of the old constraints.

The first major step for Yellowfin in introducing GUI functionality was the early introduction of
drag and drop. Initially this design request was rejected by our development team, but we
had seen some drag and drop on a humorous site, and that provided the inspiration and the
technical justification for pushing ahead regardless.

As a result Yellowfin was one of the first reporting tools to introduce drag and drop reporting
not just for building a report, but also designing the metadata layer, where a vast array of
complex user interactions need to be managed. Yellowfin is still the only reporting application
to have this functionality enabled for a pure HTML interface where no applets or Active X
controls are required.

Having said that, drag and drop is terrific, but at the same time you do not want to over exploit
the one element of your application that is unique. Use your technical achievements wisely
so that they have maximum impact for the end user. Do not use them to the point where they
become gimmick and start to actually interfere with your end user’s activities.

#4 Everything changes except change itself

The user interface design is never complete; it is an iterative and ongoing process. With each
new release for your software you should dedicate a substantial amount of time and effort to
updating your UI. Why you ask? Well it is pretty simple:

1. New technologies probably mean that you can now do more than when you originally
developed your interface. A good example of this is the AJAX, which in recent times
has provided developers with an enhanced tool set for developing even better web
based applications.
Related to this is one of the most common mistakes we see. This is developers
limiting their application to ensure backward compatibility with outdated browsers. If
anything the opposite must occur. Build functionality for the latest in browser
technology, your users will be adopting these platforms faster than you will expect.

2. New functionality needs to be checked for simplicity and unity against the rest of your
application. If during the development process you have streamlined a common user
action this action has to be updated throughout your interface.

3. Your competitors are unlikely to remain at a stand still – so having a fresh looking
interface will certainly assist your marketing efforts.

4. Evolving your design has the additional benefit of insuring your users against the
sudden shock of a major application overhaul. If incremental design changes are
ignored then at some point all of these need to be incorporated into a version that is
now a significant change which yanks users from the old way of doing things into a
whole new paradigm. An example of this type of change is the complete re-
engineering of Cognos from a fat client into Cognos 8.

#5 First impressions count

Why bother with the first 4 laws if end usability is not a key driver for you? Well if anything the
UI is the first experience that users will have of your application even before using it. When
marketing and selling your product the UI is shown in demonstrations, product brochures and
on your web site. The interface to your product says everything about what your product is
and what your core development values are. Treat your interface as if it was the only product
brochure you have. The interface that you design should be tailored for your target market.

Some questions to ask are:

• What does the audience relate to when they think about this concept?
• What colours would appeal to the user?
• How much functionality should be on any given page and how should it be balanced
on the page?
• Where should the navigational elements be located?
• How can the design allow smooth navigation throughout the application?
A well-designed application must literally follow in the path of, as well as compliment its
function.

When considering UI as a component of your product marketing strategy you are forced to
view usability in a much broader context. Consider all the touch points required to sell your
application. The most important of these is your documentation and support, but also
consider demonstration versions, online demonstration sites and packaged installers. All of
these touch points need to have the same level of usability and consistency to provide the
buyer with a sense that everything you do is to a similar standard – it’s a unified experience.

How your UI reflects your business model

Your design values do convey meaning to the buyer. If we can take the example of open
source reporting tools, the message that they express is that there is no imperative for great
usability and design since their business models are predicated on ongoing services revenue.
If your revenue is service oriented, what incentive is there for you to design software that is
easy to use? The simple answer is none.

However, commercial software with a traditional revenue model should aspire to enhanced
usability so as to reduce the overall costs associated with support. This scenario is
highlighted by Pentaho, an open source developer. Their open source BI suite is funded
through a support service business model (if you want support then you pay an annual fee).
Yet they also have an advanced reporting capability, including an End-User Reporting tool
which is neither open source nor free!

Myth # 1 Form follows function

Function should never dominate over form. Although form follows function is a much touted
design principle it has been distorted in the world of software. There are too many
applications out there which have fallen into the trap of squeezing in additional functionality
with little business benefit and to the detriment of usability. “People who rely on business
intelligence software would benefit much more if vendors placed less emphasis on breadth of
functionality and more on depth of effectiveness.”3

Crystal Reports is fine example of software that keeps adding feature upon feature until the
simple things you used to do are no longer simple, and the whole thing feels overwhelming.
No one doubts the capabilities of Crystal. While never positioned as a business user tool;
Crystal is now so complex it alienates technical users as well.

At Yellowfin we are fast becoming experts at saying no to additional functionality requests, if
that functionality, does not fit with our vision of the software.

Give users what they actually want, not what they say they want. And whatever you do, don't
give them new features just because your competitors have them! As this quote from CFO
magazine highlights it is easy to get caught up in what your competition is doing and not
concentrate on your customer - “Given the competition … vendors have had little choice but
to trick out their programs with all sorts of bells and whistles. But after prodding from
customers most vendors are at least beginning to address the issue of usability….And such
established vendors as Business Objects, Cognos, Hyperion, and Geac Computer are
attempting to design applications that are simpler and more straightforward." 4

The main item to consider in designing the form of an application is to know the audience and
to build it based upon how they interact with elements. The "perfect" balance of form and
function is always going to be difficult to find. Some software designers spend years working
to perfect the balance between form and function - it's often an evolving process that changes
as the designer's experiences change his or her outlook views on what constitutes the
"perfect" balance. After succeeding in balancing form and function to a satisfactory level, it's
time to notice a few key indicators in the design.

These key items are:

1. The functionality of the application will be seamless with the user experience. The
user will not struggle with interface or navigational issues like site structure and
organisation; they won't see any of that. The user will only see the outcome of tasks
that they have set out to do - everything else will appear transparent.

2. It will add to the application and not be distracting or annoying.
A well-designed application will balance form and function to the point where these elements
are invisible to the user. The user experience is what's important in design, not just the way it
appears or works in the designer's eyes.

3 http://perceptualedge.com/blog/
4 http://www.cfo.com/printable/article...0503?f=options

Myth #2 Only users know what they want

When designing an innovative product the reality is that most of your users have not even
imagined what is possible and would not have the capacity to articulate their needs based on
your vision for the future.

When we receive very positive feedback regarding the Yellowfin interface, often the
assumption is made that we have really been listening to our users, taking their feedback and
using that to make sweeping changes. Well that is only partially true, listening to our users is
maybe 20% of it, but the other 80% is something else. We developed Yellowfin because we
knew we could do better, because we were frustrated by the alternatives out there, and by the
fact that people still weren't having the kind of experience with reporting that we knew they
could have.

It turns out that most of the major innovations made come not from user requests and
suggestions, but from the Yellowfin team's own innovations. Most of our users have little idea
about what was needed to make a better reporting tool. In fact, many of the changes went
against what some of our user feedback seemed to suggest. In other words, in many ways
Yellowfin deliberately does not listen to users.

At Yellowfin we trust ourselves, and we do what we believe is right for our users, even if it
means doing things that on the surface seem even less user-friendly.

Most of us realise that focus groups are notoriously ineffective for many things, but we still
assume that listening to real feedback from real users is the best way to drive product
development. But there's a huge problem with that - people don't necessarily know how to ask
for something they've never conceived of! Most people make suggestions based entirely
around incremental improvements, looking at what exists and thinking about how it could be
better. But that's quite different from having a vision for something profoundly new.

True innovation will rarely come from what users say directly.

This doesn't mean that you don't listen to users--because the truth is embedded in what they
say...but you have to look for the deeper meaning behind what they ask for.

For example, if they ask for "A", as an improvement to "B", you have to explore further to find
out what it is about "A" that they want. And in that, you might find the seed of an idea that
leads you to come up with the innovative solution. And your solution looks nothing at all like
"A", but gets to the heart of what users really wanted and needed when they asked for "A".

Where we tap into our user base is for iterative improvements. One thing that users know
very well is what does not work. This is the sort of feedback that we treasure as it gives us
the kernel for developing innovative solutions. However in the end, you have to trust yourself.
You can offer your users much more if you keep innovating in revolutionary, not just
incremental ways.

Myth #3 Involve many people in your design process

Wrong - use the smallest design team you possibly can. The idea of small design teams is in
vogue right now for a reason: they just work better. They are faster, their work stays in focus
and true to vision, and they avoid many of the political problems and the interpersonal tug-ofwars that happens in larger design teams or departments.

There is nothing better than the following blog to illustrate my point about small design and
development teams. Enough said!

“I spent a full year working on a feature which should've been designed, implemented and
tested in a week…..My team had a very talented UI designer and my particular feature had a
good, headstrong program manager with strong ideas about user experience. We had a Mac
[owned personally by a team member] that we looked to as a paragon of clean UI. Of course
the shell team also had some great UI designers and numerous good, headstrong PMs who
valued (I can only assume) simplicity and so on. Perhaps they had a Mac too.

In addition to our excellent UI designer and good headstrong program manager, we had a
user-assistance expert, a team of testers, a few layers of management, and me, writing code.

So just on my team, these are the people who came to every single planning meeting about
this feature:

• 1 program manager
• 1 developer
• 1 developer lead
• 2 testers
• 1 test lead
• 1 UI designer
• 1 user experience expert
• 8 people total
These planning meetings happened every week, for the entire year I worked on Windows.

In addition to the above, we had dependencies on the shell team (the guys who wrote,
designed and tested the rest of the Start menu), and on the kernel team (who promised to
deliver functionality to make our shutdown UI as clean and simple as we wanted it). The
relevant part of the shell team was about the same size as our team, as was the relevant part
of kernel team.

So that nets us a conservative estimate of 24 people involved in this feature. Also each team
of 8 was separated by 6 layers of management from the leads, so let's add them in too, giving
us 24 + (6 * 3) + 1 (the shared manager) 43 total people with a voice in this feature. Twenty-
four of them were connected sort a closely to the code, and of those twenty four there were
exactly zero with final say in how the feature worked. Somewhere in those other 19 was
somebody who did have final say but who that was I have no idea since when I left the team

- after a year -- there was still no decision about exactly how this feature would work.”5
http://www.blogger.com/profile/1944025

Myth #4 Usability testing ensures great UI

90% of all usability testing performed on software applications is useless. Ok now that we
have your attention - this is not to say that it doesn’t have a significant role to play in UI
design, but the current culture surrounding usability testing is such that it rarely benefits the
design process.

At Yellowfin we advocate a simple approach, create a shared vision among your
developers and do lots of prototyping. Often we find and solve some of the biggest
usability problems long before they occur simply by discussing, drawing, prototyping and
trialling. So forget the camera, the testing labs and artificial environments, and take
ownership of design at every step of the development process.

Software development is a mix of creativity and code, form and function. With good design it’s
often difficult to tell where area each stops and the next begins. The real questions we try to
answer are, why do users pause? What are they looking at? What are they thinking about?
Did our interface fail them because of the categories we created, the words we used, or is it
the placement of the navigation? Perhaps it’s because of inconsistencies across the
application. Traditional usability testing does not give us these answers.

Usability testing is not quantitative. We do not have scientists in white coats watching mice
running through a maze in our usability labs. Rather we focus on the qualitative aspects of
design. We try to understand how and why people have an emotional response to what has
been created, and, more importantly, how to apply that insight to future development.

Everyone in your company is responsible for usability

There is an outdated notion that usability research requires outside observers who will
somehow comprehend what your users are doing in a more objective manner than yourself.
Usability testing doesn’t require outside firms that hold themselves separate from the design
process. Internalising responsibility for usability means embracing UI research as part of the
design process. It should be performed with the full participation of the development team, so
that everyone can empathise with the user’s perspective. Developing and leading usability
tests should be a core competency owned by everyone within your development team

And it shouldn’t be exclusive to this team. Individuals from across the organisation should
participate. Anyone who might have a stake in what’s being tested should be involved in the
process. If the right people in your company see real users having real problems to which you
can provide solutions, they’ll understand both your value to the client and the need for the
time and resources to make sure that good design happens.

Changing the approach to usability testing also changes what you should expect to get out of
it. Rather than a validation done once before completing a product, this internal, qualitative
usability testing is done earlier, more frequently, and as part of the design process—not
separate from it. This approach allows usability to move from being a one-time, report-
oriented process to an iterative, action-oriented one. This approach also allows you to
always make changes when they’re least expensive.

OK so this section appears to be in direct contrast to involving too many people. Well yes
and no. Primary responsibility rests on the shoulders of a few but anyone who sells, demos
or trains users is encouraged to provide ongoing feedback and suggestions.

Myth #5 Can’t Live without Rigorous Design Processes

Wrong – design methodologies are processes that assist software engineers to engineer
software not to design great software. Design and innovation is first and foremost a creative
process. You can document UML diagrams and functional requirements to your hearts
content but without the people that are passionate about the final outcome, and who are
empathetic to the user, you will be delivering software that has more in common with 2 minute
noodles than your Nona’s Carbonara. Both satisfy your hunger but only Nona’s pasta leaves
you with a sense of fulfilment.

The point here is that if you or your team are not passionate about delivering the very best, or
you have highly bureaucratic processes that hinder creative output you cannot possibly
deliver the best possible software solution.

Processes are required but these like functional requirements have to be balanced against
the creative processes that need to occur for great design to happen. Some internal chaos
and madness can stimulate the creative juices. Continually evaluate the way you develop
software to ensure that you do not place barriers in the way of your developers.

Above all be passionate about what you do!

Copyright © Yellowfin International pty ltd 2006 www.yellowfin.com.au