|
|
Posted by YellowFin Announcements on 12/12/06 11:22
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.cfm/5347966/c_5350503?f=options
2 http://weblogs.asp.net/jlerman/archive/2004/01/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.cfm/5347966/c_5350503?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
Navigation:
[Reply to this message]
|