UI Design Guiding Principles
July 21st, 2009 by
Russell Wilson
Just as my team and I began working on establishing a set of core guiding principles, I came across a post from John Schrag and his team at Autodesk describing their core design values. Based on their list and our own brainstorming, we have developed our own list of UI Design Guiding Principles:
- Understand the problem before solving it (and avoid “design on the spot”)
- Sketch before making it pretty (and discuss abstractions versus specifics — “selection” vs. “combo-box”)
- Validate designs before investing in (production) code
- Well designed key features & workflows over quantity
- Ease of use over ease of coding
- Validated designs over expert opinion
- Don’t make things “consistently” wrong
- Don’t let users shoot themselves in the foot
- Context is important (Where am I? How did I get here? Where can I go next? What is my current state?)
- Whitespace is good (… the more you add, the more you detract from what is there. … every element added to a page detracts from the rest. (Paul Boag)
This is a living list – I expect to tweak it over time, adding, deleting, editing…
Several colleagues pointed out Bruce Tognazzini similar list: http://www.asktog.com/basics/firstPrinciples.html
UI Design Guiding Principles… http://bit.ly/1TVZYO
This comment was originally posted on Twitter
Love these design principles: http://bit.ly/2RgGP
This comment was originally posted on Twitter
RT Love these design principles: http://bit.ly/2RgGP (via @BrianKSullivan Bookmark these. Quite useful. Quite concise.
This comment was originally posted on Twitter
Re design principals http://bit.ly/2RgGP via @brainksullivan; happy cuz I believe in them. Sad cuz hard to get into practice institutionally
This comment was originally posted on Twitter
I tried to copy and paste an interesting discussion thread that kicked off after
Adrian Howard on the stcusesig mailing-list emailed my post and asked for feedback:
==================================================================
With regard to Number 10 — while often true for many products and
services, there are times when high-density displays are important and
whitespace is a secondary or tertiary concern. This came to light
when I was working on the design of some executive information system.
Our first designs provide lots of white space and when we went to
executives and their research assistances, we found that the
executives wanted 8 charts and tables on the same page so they could
compare things without flipping to other pages or other views. The
feedback was unanimous against what would be considered a good use of
white space. So this guideline might apply much of the time, for some
cases, you would violate it because of other considerations.
Chauncey Wilson
==================================================================
Chauncey – completely agree.
I was trying to address the fact that in so many cases programmers and designers pack things
together as tightly as possible without any regard for visual hierarchy and “breathing room”.
You can create an information dense interface but still design it in such a way so that the
user’s eye can at least follow a path.
Thx for the feedback!
Russell Wilson
==================================================================
> Why do you have a “niggle” with item 5, “Ease of use over of ease of
> coding”? One of the biggest problems I encounter is with
> applications and web-sites that are built according to the coders
> world-view and because of that make little sense to the ordinary user.
Two niggles really… and minor interpretational ones at that
1) The problem is often not ease of implementation, but world view (as
you said)
I find dev/ux issues are often nothing to do with ease of
implementation. It’s the developers not understanding what users find
easy / difficult – the “whys” behind the design that’s been handed
down. Generally I find that ease of use and ease of implementation are
not particularly tightly coupled. That’s obviously not always the case
- but fairly common.
It’s not that the implementation is hard. It’s that the developers
don’t understand the design in it’s fullest sense – so they don’t
_really_ understand what/why they’re implementing it.
The problem I’ve seen is that some UX folk take this as developer
laziness rather than bad communication/understanding of the models and
abstractions in the design. Trying to convince a team to do something
with that in their head often causes problems.
(Saying “do it this way coz it’s better – no matter how hard it is” –
rather than “we need to do it this way because the user is expecting X
and Y, because of Z which represents the underlying Q”. )
Because they’re not addressing the underlying problem – getting the
developers to understand the user model – we continue getting a lousy
implementation.
I find that communicating those models well mean that the developers
can implement the solution more easily – since they now understand the
abstractions that need to be embodied in the code more effectively.
2) Ease of implementation == money.
Projects have budgets. As a (hopefully) responsible designer I need to
be involved in building the best project I can for the money available.
What “Ease of use over of ease of coding” is saying from a budget
perspective is “Ease of use over money”.
If I’m metaphorically wringing my hands and going “Boo hoo – this
wouldn’t be rubbish if we could spend a bit longer implementing my
wonderful design – not my fault!” then I’m abrogating my responsibility.
I need to work with all of the stake holders and all of the team to
build the best possible product in the time/budget available.
Sometimes that will be spending more time the product a joy to use.
Sometimes that will mean getting that vital feature implemented no
matter what in the best way we can in the time available.
Now – there are certainly good arguments to be had about the impact of
a badly implemented feature on a product – short and long term. But
that’s not an really about ease of implementation (or otherwise). The
same issues arise from badly implemented features (from a UX
perspective) whether they were easy or hard from the developer
perspective.
Hopefully that makes some sort of vague sense
Cheers,
Adrian Howard
==================================================================
I also agree with Chauncey and Russ. I work with many programs for Travel Agents, who want to be able to see as much information on the screen as possible. These screens are very densely packed.
The agents hate scrolling. They prefer to scan and keyboard input rather than use the mouse.
>From what I have seen, the travel agents really use the mouse almost as an extension of the keyboard with very small movements, using the wheel more than gross hand movements with the mouse.
Still, they prefer to scan. White space is a secondary concern. They actually prefer the density.
Thanks,
Brian Sullivan
==================================================================
> Still, they prefer to scan. White space is a secondary concern. They actually prefer the density.
Do you think there’s some sort of “complexity appeal”? I’m wondering if some people prefer the
oscilloscope over the iPhone? I know some engineers who like to tinker – they like complexity – wires,
gauges, messiness…
hmmm…
Russell Wilson
==================================================================
> Adrian – what are your thoughts on 1, 3 & 5?
Heh
Hopefully you’ve already seen my ramblings on (5)
> 1) Understand the problem before solving it (and
> avoid “design on the spot”)
I’m not 100% of the intent behind it. To me it seems to be saying the
ideal is:
1) Do the understanding
2) Do the designing
3) (implicitly – do all the implementing).
That may be me wilfully misinterpreting your words of course
I don’t work that way at all.
I understand a bit. I design a bit. That sparks of some more
understanding. Which leads to some more designing. Which leads to a
bit of implementation. Which highlights an issue that I hadn’t
spotted. Which leads to a rethink of a bit of the design. Which points
to a new area of understanding which…… I’m sure you get the
drift….
For me design is a incremental process of creative refinement – and
(1) seemed to be saying that was a bad idea.
I’m not anti research. Research is great! It’s just that I often find
that the fastest way of clarifying my understanding of a problem is to
build and try something.
I have found folk who try and do all the understanding of the problem
up front tend to miss something – usually a big something – that
causes problems later on in the project. If they’d done a bit more
solve it / build it earlier it wouldn’t have happened.
For me there is a fantastic and thoroughly enjoyable dance between
understanding, design & implementation. Doing all of one before the
others is less useful (and less fun
> 3) Validate designs before investing in (production)
> code
I’m niggling again…
I want to validate the designs in the fastest most cost effective way
possible. Sometimes that’ll be a scribbled sketch in a notebook.
Sometimes that’ll be a vaguely formal paper prototype. Sometimes
that’ll be a quick HTML mock up or something in Omnigraffle. Sometimes
that’ll be a quick code spike.
Sometimes that’ll involve writing production quality code.
It – as they say – depends!
Validating the design and getting feedback in the quickest and most
effective way is the important issue. Throwing one of the ways of
doing that out of the window coz some people do really dumb things
seems counterproductive to me
I’ve many problems with designs that come down to not validating
practicalities with real production code early. Equally I’ve seen a
whole bunch of problems where folk have gone down one particular
design path too and have wasted a whole bunch of time and money.
Understanding the costs and benefits and making an informed decision
seems better than an absolute statement.
> Thx!
> Russ
And thank you for the thought provoking post
Cheers,
Adrian Howard
==================================================================
I can’t speak for everyone, but personally I prefer the density because
it’s more efficient. It provides the information I need to do my job,
without hunting and scrolling.
Kathryn Grant
==================================================================
> Do you think there’s some sort of “complexity appeal”? I’m wondering
> if some people prefer the
> oscilloscope over the iPhone? I know some engineers who like to
> tinker – they like complexity – wires, gauges, messiness…
I think that can certainly appeal to some folk.
But for data entry/comparison it’s often a case of a more effective
workflow. Not having to scroll can make some tasks easier.
Also – I remember talking to one guy when doing some user testing who
was really anti-scrolling because he had to touch the computer.
With the old system he could bring up a page of information and then
have an interaction with the customer, glancing at the screen when
necessary. With the new system he had to turn, tweak the mouse, turn
back. Since he had to do that several times during each interaction he
felt that it broke the rapport between him and the customer. The quote
on the usability report was “This will cost me f**king sales” I seem
to recall
Cheers,
Adrian Howard
==================================================================
I think it is both a complexity appeal and they want to be very
efficient. On one hand, Travel Agents want people to see them as
experts (and they truly are experts–the general public does not know
what happens behind the scenes).
So, the complexity appeal makes them feel like experts. Yes, it is an
ego thing.
And…I do think it is related to efficiency. Time is truly money. The
agents need to book revenue to make a living. With the advent of online
travel sites, the vast number of travel agents are becoming very
specialized.
You do not have a travel agent really in strip malls too much. Just 15
years ago, there was a travel agency in every other strip mall. To make
money, they must book revenue faster–screen density makes that
possible.
The agents see density as enabling them to book $$$.
Brian Sullivan
==================================================================
>> I think it is both a complexity appeal and they want to be very
efficient. On one hand, Travel Agents want people to see them as
experts (and they truly are experts–the general public does not know
what happens behind the scenes).
>> So, the complexity appeal makes them feel like experts. Yes, it is an
ego thing.
It all really goes back to ‘know your user’. I have an application I’m working on that is used by both the very barely computer literate salesman and the guru computer user in operations. What they want and how they interact with the same information is very different. So I have two different UIs to help each user role be productive.
Thanks,
Jeanne Hallock
==================================================================
UI Design Guiding Principles: Just as my team and I began working on establishing a set of core guiding principl.. http://awe.sm/tn9
This comment was originally posted on Twitter
Great list of UI design principles http://tinyurl.com/nkwj87
This comment was originally posted on Twitter
10 “UI Design Guiding Principles” http://tinyurl.com/nkwj87 (dexodesign.com)
This comment was originally posted on Twitter
10 “UI Design Guiding Principles” http://tinyurl.com/nkwj87 (dexodesign.com) (via @IATV)
This comment was originally posted on Twitter
#5 is a particular pet peeve of mine.
#6 also, but to a lesser degree.
Also, regarding #10, I agree, but have a preference for the term "negative space" over "white space" as not all uncluttered design has a "white" background (Semantics. I'm aware I'm splitting fine hairs. Just pointing it out).
I love these UI Design Guiding Principles. http://bit.ly/Bf8Yx
This comment was originally posted on Twitter
10 “UI Design Guiding Principles” http://tinyurl.com/nkwj87 (dexodesign.com) via @IATV
This comment was originally posted on Twitter
I’m really huge on the 1st one – Understand the problem RT @IATV: 10 “UI Design Guiding Principles” http://tinyurl.com/nkwj87
This comment was originally posted on Twitter
[...] UI Design Guiding Principles [...]
10, UI Design Guiding Principles – http://ow.ly/jxT3 #ux #ui #design #prototype
This comment was originally posted on Twitter
[...] UI Design Guiding Principles: http://www.dexodesign.com/2009/07/21/ui-design-guiding-principles/ [...]
Really appreciate your post, seems as though a lot of our designer community know these things yet we have trouble selling these ideas and reasoning to those who make the final decision.
Good points. I think the main guiding principle is to understand both the problem to be solved, mindset of the end user and have adequate tools to make the job good. Armed with these we cannot fail.
Cheers
Colin
[...] UI Design Guiding Principles [...]