Results 1 to 5 of 5

Thread: Laws and Myths of Usability & Interface Design

  1. #1
    Join Date
    Nov 2006
    Posts
    20

    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

  2. #2
    Join Date
    Nov 2006
    Posts
    20
    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. #3
    Join Date
    Nov 2006
    Posts
    20
    #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!

  4. #4
    Join Date
    Nov 2006
    Posts
    20
    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

  5. #5
    Join Date
    Nov 2006
    Posts
    20
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •