Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am writing a system requirements document and need to include non-functional requirements relating to the usability of the system, but am not sure of the best way to express this.
"The system shall be easy to use" seems a bit vague to me, and not testable. Are there any 'official' standards/guidelines that can be adhered to relating to the usability of a program?
Usually, we try to hash out an application-specific definition of 'easy to use'. For example, for our current project, easy to use means:
-All delays in the system longer than .5 seconds will produce a dialog box that says "Please wait."
-It is possible to reach any given system function from the main window in less than 3 clicks.
-It is possible to accomplish any given task with just the keyboard, without the mouse.
-All buttons in the system will adhere to established button convention (link to established button convention regarding size, naming, position, etc.)
-All screens will have a help button. Each help button on a given screen must provide at least one 'topic' for each control on the screen.
-etc.
These sorts of things are testable, and taken together, constitute a 'pretty good' usability standard. That said, nothing substitutes for actual users trying it out.
Usability requirements are hard because the only way to know if your system is usable is by having real users try it out. How will you know if your requirements have been met? To do that, you need formal metrics for usability. Those metrics have to somehow be extracted from the results of usability testing, and if you abstract your usability testing to the point where you're just getting metrics out, you're missing out on its usefulness.
Some items like "must be able to do X with Y many clicks" or "system must respond in Z milliseconds or less" are useful, but they're actually functional requirements that have to do with usability, not usability requirements in themselves. It's quite possible (if not likely) that you can design and implement a system that meets all such formal requirements and is still frustrating for the users. Again, the only way to know is through usability testing.
Well, 'The system shall be easy to use' is exactly the kind of documentation that frustrates both designers and developers, so let's see if we can do a little better than that shall we? :)
To start with, you may find it helpful to sit down and imagine exactly who the intended user is. Give them a background, give them a bit of colour, then send them to your imagined application and try and figure out how they as individuals would want to interact with it.
Remember, different users are concerned about different aspects of usability. Don't just concentrate on the story path you think you would follow if you were using the application.
Next it might be helpful to break the site down into usability components. Does it have a lot of pictures? If so, what's the best way of presenting a lot of pictures to a user. Does it have a deeply nested menu structure? Might there be a better way than a sitetree to help your users navigate their way around?
Usability design patters will help you here. A good resource for design patterns for usability can be found here and here. Design patterns are good because they clearly explain to everyone involved how certain functionality is supposed to work.
Take a moment to consider accessibility in combination with usability. How the site work with javascript turned off is always a very good place to start and can be a great help to developers who tend to get very tired of watching their designer stick yet another <a> link on a page that is going to need to submit a form.
Remember, usability is about clarity and it begins with clear communication to the people building the system. If you can't speak clearly about what you want built how do you expect the developers to build something functional? Take the extra time to paper prototype if you have to.
My reply may be a little too 'web' focused to be of enormous use to you, but I hope it provides a few useful tidbits amongst my ranting.
Metrics & Usecases.
We have a number of personas that encapsulate our different customer types.
We have the user poweruser (George, he's a nerdy, university type),the non-tech person (Frank, who can barely use a calculator) and someone in between (Susie, she knows how to surf the web and can talk to tech support but don't ask her what emacs is).
Based on that we say:
For feature X, George should be able to access it without using the help or pausing longer than a few seconds, Suzie may need to look at the help but probably won't and if Frank does it better be real clear because he doesn't have much patience.
Now, for metrics, we also have usability study guidelines, like out of 10 people, 8 should be able to access Feature Y without looking at the help or be able to do it with 30 seconds.
Those are really subjective, but it might help you get going to in the right direction. Plus, it may help you talk to non-developer types who "just want it to work and be easy".
It wouldn't hurt to read Joel on Software articles too.
The most unambiguous way to include usability requirements in a requirements document that I could find is: make lots of screen mock-ups (and connect them with the "flow" of the performed actions, e.g. by having an arrow point from one item at image1 to the relevant next item on image2 etc.). If people actually see how something is supposed to work, it's easier to understand and leaves less room for interpretation.
Here's GNOME's documentation regarding human interfacing. This is intended as an example of how to specify, not what to specify (as I don't agree with everything they're saying in there).
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I wonder what would be a good definition of term "over-engineering" as applied to software development. The expression seems to be used a lot during software design discussions often in conjunction with "excessive future-proofing" and it would be nice to nail down a more precise definition.
Contrary to most answers, I do not believe that "presently unneeded functionality" is over-engineering; or it is the least problematic form.
Like you said, the worst kind of over-engineering is usually committed in the name of future-proofing and extensibility - and achieves the exact opposite:
Empty layers of abstraction that are at best unnecessary and at worst restrict you to a narrow, inefficient use of the underlying API.
Code littered with designated "extension points" such as protected methods or components acquired via abstract factories - which all turn out to be not quite what you actually need when you do have to extend the functionality.
Making everything configurable to "avoid hard-coding", with the effect that there's more (complex, failure-prone) application logic in configuration files than in source code.
Over-genericizing: instead of implementing the (technically uninteresting) functional spec, the developer builds a (technically interesting) "business rule engine" that "executes" the specs themselves as supplied by business users. The net result is an interpreter for a proprietary (scripting or domain-specific) language that is usually horribly designed, has no tool support and is so hard to use that no business user could ever work with it.
The truth is that the design that is most easily adapted to new and changing requirements (and is thus the most future-proof and extensible) is the design that is as simple as possible.
Contrary to popular belief, over-engineering is really a phenomena that appears when engineers get "hubris" and think they understand the user.
I made a simple diagram to illustrate this:
In the cases where we've considered things over engineered, it's always been describing software that has been designed to be so generic that it loses sight of the main task that it was initially designed to perform, and has therefore become not only hard to use, but fundimentally unintelligent.
To me, over-engineering is including anything that you don't need and that you don't know you're going to need. If you catch yourself saying that a feature might be nice if the requirements change in a certain way, then you might be over-engineering. Basically, over-engineering is violating YAGNI.
The agile answer to this question is: every piece of code that does not contribute to the requested functionality.
There is this discussion at Joel on Software that starts with,
creating extensive class hierarchies for an imagined future problem that does not yet exist, is a kind of over-engineering, and is therefore, bad.
And, gets into a discussion with examples.
If you spend so much time thinking about the possible ramifications of a problem that you end up interfering with the solving of the problem itself, you may be over-engineering.
There's a fine balance between "best engineering practices" and "real world applicability". At some point you have to decide that even though a particular solution may not be as "pure" from an engineering standpoint as it could be, it will do the job.
For example:
If you are designing a user management system for one-time use at a high school reunion, you probably don't need to add support for incredibly long names, or funky character sets. Setting a reasonable maximum length and doing some basic sanitizing should be sufficient. On the other hand, if you're creating a system that will be deployed for hundreds of similar events, you might want to spend some more time on the problem.
It's all about the appropriate level of effort for the task at hand.
I'm afraid that a precise definition is probably not possible as it's highly dependent on the context. For example, it's much easier to over-engineer a web site that displays glittering ponies than it is a nuclear power plant control system. Redundancies, excessive error checking, highly instrumented logging facilities are all over-engineering for a glittering ponies app, but not for a nuclear power plant control system. I think the best you can do is have a feeling about when you are applying too much overhead to your features for the purpose of the application.
Note that I would distinguish between gold-plating and over-engineering. In my mind, gold-plating is creating features that weren't asked for and will never be used. Over-engineering is more about how much "safety" you build into the application either by coding checks around the code or using excessive design for a simple task.
This relates to my controversial programming opinion of "The simplest approach is always the best approach".
Quoting from here: "...Implement things when you actually need them, never when you just foresee that you need them."
To me it is anything that would add any more fat to the code. Meat would be any code that will do the job according to the spec and fat would be any code that would bloat the code in a way that it just adds more complexity. The programmer might have been expecting a future expansion of the functionality; but still it is fat.!
My rough definition would be 'Providing functionality that isnt needed to meet the requirements spec'
I think they are the same as Gold plating and being hit by the Golden hammer :)
Basically, you can sit down and spent too much time trying to make a perfect design, without ever writing some code to check out how it works. Any agile method will tell you not to do all your design up-front, and to just create chunks of design, implement it, reiterate over it, re-design, go again, etc...
Over-engeneering means architecting and designing the applcation with more components than it really should have according to the requirements list.
There is a big difference between over-engeneering and creating an extensible applcaiton, that can be upgraded as reqirements change. If I can think of an example i'll edit the post.
Over-engineering is simply creating a product with greater functionality, quality, generality, extensibility, documentation, or any other aspect than is required.
Of course, you may have requirements outside a specific project -- for example, if you forsee doing future similar applications, then you might have additional requirements for extendability, dependent on cost, that you add on to the project specific requirements.
When your design actually makes things more complex instead of simplifying things, you’re overengineering.
More on this at:
http://www.codesimplicity.com/post/what-is-overengineering/
Disclaimer #1: I am a big-picture BA. I know no code. I read this site all the time. This is my first post.
Funny I was just told by my boss that I over-engineered a new software produce we're planning for mentoring (target market HR people). So I came here to look up the term.
They want to get something in place to sell now, re-purposing existing tools. I can't help but sit back and think, fewer signups, lower retention, if it doesn't allow some of the flexibility we talked about. And mainly, have a highly visual UI that a monkey could use.
He said we could plan future phases to improve the product, especially the UI. We have current customers waiting on "future improvements" that we still aren't doing. They need it though, truly need it.
I am in the process of resigning so I didn't push back.
But my definition would be.............making sure it only does as little as possible, for as cheap as possible, and still be passable for the thing you say it is. Beyond that is over engineering.
Disclaimer #2: This site helped me land my next job implementing a more configurable software.
I think the best answers to your question can be found in this other qestion
The beauty of Agile programming is that it's hard to over engineer if you do it right.
I'm working on a product which is meant to be simple to use and simple to set up, the competition largely requiring a long set up period and in some cases going as far as a bespoke solution for each customer. One part of our application is now expanding based on customer requests and it is looking like we'll need to make it very flexible so each customer can have a lot of control over how it behaves for them. The problem being that I don't want to make the system too configurable, as I believe this then makes it more complex to learn and to work with. I'm also concerned it opens the door to someone messing things up for themselves, kind of like handing them a gun, although I'm not actually pointing it at their foot for them.
Has anyone else faced a similar dilemma of putting power in users hands? How did you solve it? and what was the result?
I don't normally like to subscribe to the idea that all users are stupid, but there is a rule which can still be applied:
If you give them the opportunity, they WILL break it
Now it is up to you whether or not to give them the ability to do potentially dumb things. Or better yet, develop it so that when they do do the stupid voodoo that they do, it can be reverted or recovered from error state gracefully.
I highly recommend you read Joel's Controlling Your Environment Makes You Happy, which can be described as a treatise on user interface design but is really about usability with a healthy dab of psychology thrown in.
The section I'm referring to is Choices:
Every time you provide an option,
you're asking the user to make a
decision.
This is something I strongly agree with. Many developers, product managers and so on take the easy route and instead of figuring out what users actually need, they just give them a choice. You see this in enterprise bloatware like Clearcase or PVCS where there are so many options--90% of which you'd never change--indicating the designers have tried to make it all things to all men rather than doing one or two things exceptionally well.
Instead it just does lots of things badly.
Keep it simple, follow conventions, don't overwhelm the user with pointless and unnecessary choices and make the software behave like a normal user would expect. That alone would set you apart from an awful lot of other products.
Personally I like the TurboTax model (http://turbotax.intuit.com/). When creating a tax return, I get a simple, tell-me-like-I'm-five wizard that takes me step-by-step through the process, but I can step outside the process at any time and use more advanced features, returning to the process later.
Make it easy and simple and uncluttered for your user to do what they're going to do 80% of the time, but give them the power to deliberately step outside of the norm.
Interesting timing for your question. In the U.S. this is Income Tax week. Filling out the ol' 1040 and associated subforms should give us some sympathy for what users endure.
Lessons I take away are:
Only ask questions that relate to the user domain; avoid questions relating to the software system; and if you can derive the answer or suggest a most likely answer, do so.
Put related questions together (as long as they are normally entered by the same person using data most likely available at the same place and time, which is the definition of related for these purposes).
Make it support incremental input. It should be easy to enter the data they have, and defer completing it when the rest is available.
Show status validity and completeness. Make it clear and obvious how far they are to having validatable data.
Make it interruptable. Make sure it's possible to interrupt the process, leave the application, come back, and resume where they left off.
Yup, it's harder to program. Embrace it.
There are at least two ways to build a good software product:
Focus on a narrow set of functionality, and implement that functionality very well.
Design your system to be customizable (ideally, through scripting.) If you do the base system right, it will be easy to provide the basic, no options, just-do-what-I-want functionality on top of the customization layer.
Unfortunately, there are many more ways to create a bad software product.
Your questions implies that you can either provide a flexible solution OR make it foolproof.
I wouldn't put it like that. To me this is rather a matter of user expectations and the question in the first place would be:
How can I meet all important user expectations (even if they conflict with each other) without corrupting the application?
For instance a web application which has a menu, breadcrumb navigation, a site map and a search offers together with the inline links five different ways to find what you're looking for and how to go there.
That way most users can find fast and easily the functionality they are expecting and therefore the need for an extensive documentation might actually decrease.
So the answer might be to offer several different carefully chosen ways to solve one specific task, while each of them can be streamlined independent to avoid user mistakes.
The answer with this lies in who your end-users are. I used to write software that got used by professional sports coaches. While these guys were definitely good at what they did, they were hardly proficient at computer use, so our configurability was kept to a minimum (at least as far as what could be done in the GUI).
On the other hand, if you're dealing with power users, adding options is usually not a bad thing as long as they aren't intrusive.
It's all about who's going to be getting them.
Read Jeff Atwood's Training Your Users. It's a great article with some very useful links.
I like the approach of Firefox towards this. The basic options are accessible in the option menu, all the rest is under about:config. Thus you have an easy interface and an incredible flexibility if you need it.
I've had great success, and been happiest as an user, when using sensible defaults. In other words, make the most common use case easy (or even better, free), but give users the ability to step outside of that use case when the situation calls for it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Starting to look at my last year project now, and so I'm doing the specification-requirements document. Now, it just so happens that this project requires a high degree of "usability" - I dunno if this is the right word in english, but what I mean is that it should be really easy to use from a user PoV. Now - in all the projects I've worked on so far, usability haven't really been a great factor, and so I could just write some gibberish to get around it. I always asked our teachers how they would specify the requirements of usability though, but no one have yet given me an answer I felt was good enough.
Our teachers have always preached that any requirement given on a project should be "test-able", but how do you test how easily accessable your user-interface is?
Say I had a real-time application running. Here it wouldnt be too hard to say "an entry should be deleted in less then 100ms after the initial call". But it's a lot harder to say "The userinterface should be 86% intuitive".
I guess this is a tough nut to crack, but surely I can't be the first person in the world to have thought about this, let alone having problems with it.
... how do you test how easily accessible your user-interface is?
With usability tests.
Basically, you grab a bunch of your friends (because you won't have any money to encourage strangers to participate) give them the documentation a new user would have and ask them to perform the system's key use cases.
Ideally, you want your test users to have at least some of the qualities of your target users, so if your system is aimed at a technical audience then your classmates will work; however, if your system is aimed at the general public then you're going to want to get your friends in Arts, Human Kinetics, etc. to participate.
So how do you turn that into requirements? You identify your key use cases and stipulate what how usable should they be (walk-up usable, a few minutes with the documentation, real actual training...) and then verify that your test subjects can complete the use cases without too much frustration, with the right amount of training, in a reasonable time.
Try to define usability in terms of "test-able" requirements.
You already gave yourself the answer, because usability can be described in terms of requirements like "an entry should be deleted in less then 100ms after the initial call".
What makes a user interface 86% intuitive? This can’t be answered without some form of measurement. You need to ask what features can make a user interface intuitive. Talk to the customer and the potential future users. Gather features (or better dig for them!), which would make working with the piece of software easier.
Maybe you get a list of features like:
The department’s organization must be
shown in a hierarchical tree view.
In this tree view drag & drop must be
possible.
The font size must be
configurable and saved for each user.
On the top of the screen there must
be a list of important links. Each
user may configure and save his own
personal list.
...
Make requirements out of these features. They are “testable” and thus “measureable”. If in the acceptance tests it turns out that 17 out of 20 features are working, you have 85% success.
EDIT: This works in a project environment, where you need to deliver measurements (like in many commercial projects). If you have a "softer" form of project environment where not everybody is poking on figures, then sticking too much on this formalism may be counterproductive since flexibility and agility may suffer from this.
I would advise you against quantifying usability requirements. The problem is not so much that you can't define metrics. You could say, for instance, that
it should take a person not longer than x seconds to find y on the site, or
the conversion rate of the store has to be higher than z%
etc etc
The problem is rather that you have to spend time and resources on finding acceptable target values for your metrics that you can actually reach. What is an acceptable time to find a piece of content?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
A (non-technical) friend of mine has asked me how to make a website. I get this question all the time. After a few questions I found out that she has an idea that could turn into a commercial site. I described three options to her:
a) Get a book/enroll in a class/follow some online tutorials and learn how to do it. She's pretty smart and her personality seems like a good match for this sort of thing so I'm sure she could learn but she doesn't have a lot of time spare. Maybe if she started with one of those WYSIWYG editors at first? I stressed that this would take a longer than a couple of weekends of playing around.
b) Hire someone to build it. Ranges from ultra cheap to ultra expensive, crappy to good and everything in between. I didn't mention sites like Rentacoder because she hasn't worked on a project like this before and doesn't know what to ask for. At this stage she'd likely ask for a Youtube-MySpace-Google for a few hundred bucks because she doesn't yet understand just how much is involved.
c) Find someone technical and partner up with them. I explained that this can either work really well or be a disaster because she'd have to give up some of her ownership of the idea.
How do you respond in these situations?
Depending on the nature of the required website (ie whether she needs shopping carts etc) I often recommend first creating a blog, although it's often not the best format, it can be used to quite good effect at times. I've seen a number of small retailers for example, using a blog to advertise their wares.
It depends on the person and their motivation. Your friend sounds like she should take option b) or c). She's probably not so much interested in the technical aspects of making a web site as she is in seeing her idea come to life, or maybe running her own company based on the idea.
Well in general there are several steps:
Determine the subject of the website.
Determine the target audience.
Decide on a general layout and look and feel.
Decide which techniques to use.
Design the overall structure of the site.
Collect content and images.
Implement the site.
Most of the times, these steps are carried out by more than a single person. Because they all require their own specialization.
I think that the only realistic options are B and C. Non-techies will almost never come to grips with real web site development. With all due respect to those who have advocated technologies such as ASP.NET or PHP - it won't work. In fact, you are likely to be fielding questions for weeks on end as to why things don't work. You'll have to bear these questions until the person, having failed, gives up.
If they have the resources, then I would strongly recommend the "hire an expert" route.
In either realistic case, they must get a legal agreement in place. If she does hire an expert, be sure that the agreement expressly stipulates that this is a "work for hire". If your friend doesn't demand a work-for-hire clause then she will have no legal means to stop the developer from using the exact same code she just paid for in creating a competing site (at least in the U.S.). Just to emphasize: they would have no legal means to prevent the developer from starting their own competing site without a work-for-hire clause - the courts won't even hear the suit.
Now, if it is really just a brochure site or something similar, and they still want your advice, then it depends on whether they use a Mac or something else.
If they are a Mac user, I tell them to try booting up iWeb and using it to feed a .me account. Just plug in some pictures and some text, upload to your .me account and you are done.
If they are a Windows user, I direct them to Register.com or a similar online Web Site template-based site builder.
For your sake, don't volunteer to help unless you are really sure you have the time to essentially build the whole thing for them! You can ruin friendships this way: friends and family, having no clue what really goes into the construction of a site, almost invariably assume that it is "trivial" for you. If you delay or fail to get things done quickly enough, they'll almost always assume that you are blowing them off and they'll resent you for it (can you tell I've been there?).
It depends on how confident she is that this thing will succeed or, alternatively, how unwilling she is to share ownership. I'd definitely not recommend (a) for something that has commercial value. Beyond the time-to-market factor, initial impressions are something that is very hard to overcome. If she has the cash and is possessive of ownership, then (b) could work well. It's a bigger financial risk, though.
I'd probably go with (c), but then again I'm on the other side of the equation. There are lots of ways of structuring a partnership that would help her maintain ownership, though probably not complete ownership since no one wants to work for nothing. Some combination of b/c is probably best - some less pay in exchange for a small stake in the business. I'd definitely see a lawyer before doing (c) and maybe even before doing (b) just to make sure any agreement she has with the developer precludes them taking the code and running.
There are really two questions here: should she learn how to write a website and, if so, how.
If she has a commercial idea and she only wants to learn how to write websites to market it, I would suggest that she does not bother. Outsource instead.
If you have someone who to trust then only 3rd option is realistic. first one takes years to give out good result and with second one you never know what you get.
Buy her a book for her birthday on ASP.NET or PHP.
A bit of topic but here it goes...
We have ONE web designer at our company(we are about 10 programmers), we usually make some jokes like: "You do not work, you just sit there making drawings all day long" (just for the record, she is very competent and does her job pretty well).
So one time she stares at my monitor for about 2 minutes while i am working on a web application, and at some point she says: "Sooo that's what you do? Formulas and stuff?".
From that day on we all say "I do formulas and Stuff" when asked for what we do at work, as for most people, saying that and saying you develop web applications is the exact same thing.
Developing a web site is not as trivial as places like GeoCities or Google Pages would make it appear.
Here is a list of things you need to know about or consider when publishing a site.
If she owns a Mac or doesn't mind to acquire one, I would suggest her to have a look at iWeb. Otherwise, starting a blog on a platform such as blogger would be a nice first step for a non-technical person.
I always give the same answer, HTML. I say what it does and then tell them to get a book. If they get what it is about they will follow their own course of action.
Unless you're a web designer, 'how do I make a website' is a similar question to 'how do I make a television'. You don't, you buy one. So this question is probably 'How do I procure a website?'.
This breaks down into:
Working out what you want:
What user features do you want
What do you want the UI to look like?
What admin features do you need?
Do you already have a graphic design/logo/color scheme, etc.
Finding someone to make it for you
How do you find them? Referrals? Local web dev companys? Friends?
Do you care which technology they use?
Are you going to project manage it?
How do you know they're doing a good job?
Are you clear on issues like scaling, support, maintenance?
Ideally, find a single company who is comfortable helping you work through all the issues. Less ideally but also good, find a consultant or company that will help you with the top level stuff and assist with production of technical specs that you can then take to a development company to produce.
(Edited for formatting)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm not a usability specialist, and I really don't care to be one.
I just want a small set of rules of thumb that I can follow while coding my user interfaces so that my product has decent usability.
At first I thought that this question would be easy to answer "Use your common sense", but if it's so common among us developers we wouldn't, as a group, have a reputation for our horrible interfaces.
Any suggestions?
Source: http://stuffthathappens.com/blog/wp-content/uploads/2008/03/simplicity.png
Read Don't Make Me Think by Steve Krug. It is a great starting point, and an easy short read.
EDIT: This is mainly for web usability though, but it would still be a good read even if you are doing rich clients.
Just two things, really:
"A user interface is well-designed when the program behaves exactly how the user thought it would" - quoted from Joel Spolsky's User Interface Design For Programmers
Put your designs in front of a user. A real end-user is best, but for lightweight, rapid feedback, you can't beat hallway usability testing i.e. grab a co-worker.
If you remember Joel's advice and make sure you get feedback on whatever you do and act on it i.e. iterate, you'll not go too far wrong. And I would echo the recommendation for Steve Krug's Don't Make Me Think - it's probably the best work-related book I've read, bar none, and is just as applicable to desktop software as websites.
Hope this helps.
Don't make things work in a different way than your users are expecting (i.e. breaking the "back" button when using Ajax in web forms
Follow the K.I.S.S principal
Really, any rules someone posts will be a variation on the theme:
Don't Make Your Users Think
"Don't Make Me Think" has already been posted, see also
Design of Everyday Things and Designing with Web Standards which are also great for light usability reading.
Avoid modes. It's frustrating to a user when input works sometimes but not others, or does different things at different times.
The single most important piece of advice I'd give someone is to work on the UI first. Pen and paper and all. That way, you won't subconsciously couple buttons to functions, input fields to variables, etc.
The best UI might be a pain to code, and if your backend code is mostly written, it will sabotage your thinking.
Other than that, I'd point to Apple's Human Interface Guidelines. Of course, if your platform is not OS X, take the OS X sections with a lot of salt. What works in OS X might not work on Windows. You should embrace your platform's idioms.
OS X stuff aside, that document has some pretty good starting points on the fundamentals.
Here are some simple rules:
Fewer clicks are better.
Frequently used features should be easier to find.
Features for "advanced" users can be harder to find than the ones above.
Think about the number of mouse/keyboard clicks it takes a user to get to something.
PS - please don't tell the Microsoft Office 2008 people about this; the poor little guys would cry themselves to sleep tonight! :)
Think about the users that will use your app. Why are they using it and in which context?
Will the majority be pro users that know the domain in which the application is used and use the app a lot? Then don't be afraid of adding a lot of data to the screens as long as it arranged logically for users (normally that is not in alphabetical order :-). Think trade screens for stock borkers or airplane cockpits.
Are users occassional users? Keep it simple. Avoid context switches (keep all/as much as possible of necessary data for a task on the screen at each time). Don't break expectations of how gui widgets normally work. Design for failures.
Anything in between? Allow users to grow in the UI. Track usage so you can later determine where users seem to spend the most time so you can improve the most used areas of your app.
Test your app on friends and colleagues (the corridor test) to see if they are able to use it efficiently.
That's a start.
I suggest to read these blog posts from the Enso creators.
Of course they repeat guides/ideas/advices from books such as
The Design of Everyday Things and About Face, but nevertheless, the posts contain quite a few insights and (IMO) they are a good read.
What information does your user need, put that on the screen and nothing else. If you cannot define what the user needs - get another user.
Remember that your application will be one of many the user will have to deal with. Don't do things just to be different or kewl. Don't come up with unusual graphics, behaviors, terminology, or interactions. Use the standard OS controls, conventions, utilities, and behaviors.
Let your app interoperate with other apps; allow cutting and pasting of data, save your data in formats other apps can read, and allow importing data from other apps instead of using your UI.
If you are making a desktop app, do not try to take over the user's computer. Leave the user's Documents folder, task bar, and application preferences alone. Don't change anything already installed on the computer. Allow scripted or command-line interactions.
If you're making a web app, do not try to take over the browser. Do not try to subvert the standard menu bars, history, layout, or fonts. Allow the user to change the page using Javascript.
(1) Common actions should require as little effort as possible and should be obvious; on the other hand, actions that are rarely needed can be require a lot of steps and can be hidden behind menus and dialogs. To be able to do so, you should always describe what the user will want to do with the application by listing use cases.
(2) A UI should be selfdocumenting. The manual should be integrated in the application's dialogs and menu's, as users don't read separate manuals. For example, the keyboard shortcut should be shown in the menu item representing the action it is associated with.
Provide keyboard shortcuts for power users (even if it is as simple as "hit enter to search")
Don't put too much on screen at once.
If you pop up a messagebox, your users generally won't ever read it.
In addition to the other recommendations here, I'd recommend Designing Interfaces by Jenifer Tidwell as a good way of becoming familiar with UI conventions.
Also, The inmates are running the asylum By Alan Cooper is excellent for providing an insight into how to approach interaction design.
A good follow on to Don't Make Me Think is Robert Hoekman's Designing the Obvious. It's more focused on web applications, as opposed to web sites like in Krug's.
Simple is better than complex
Complex is better than complicated (eliminate 'nested ifs')
Intuitive (good elements needs no explanation)
Follow the convention (for example, underlined means link, red means error, tab goes to next field, etc.)
Use semantics to apply the logic (header reads first, paragraphs next)
whitespace is important