When you’re in “developer mode” criteria for “done” is more or less precise: tests are green, code is OK and metrics (if you have some) are acceptable.

Then I have to do some UI work and when I wear my Designer hat it gets difficult to define “done” criteria. We can easily appreciate “functional” quality of one particular screen. But it’s Design and Usability values are more difficult to formalize. You can check some UI Guidelines, you can show your work to a stakeholder or client. They both will say it’s OK. Then you’re improving it by grouping better screen’s content. They again say “it’s OK”. You’re checking alignments, highlight frequently used commands and do subtle color changes to application’s color set. And again, “it’s OK”.

Is it better than before? Definitely. Is it done? Well … If you’re at your “it’s good enough” point, you probably will stop. Until next time…

To some degree, this tendency towards perfection it’s applicable to development too. A developer can (almost) infinitely polish, optimize & refactor existing code. The code will be better. Will it be observable by final user? Less likely (unless it’s a performance issue). And this is the difference with designer’s work: any change will potentially be appreciated by end-user.

That’s why I think that impact of Design and Usability on any software product is more important that it’s internal beauty.

But not this case:

I’m working on Windows Phone 7 application (yes, mGitHub and btw it’s already available in marketplace) in my spare time and weekends and I own a WP7 device which I really like. So, there was no surprise when I’ve seen that Metro UI, the visual style of Windows Phone 7 platform, influenced me and leaked in this screen that is part of a Silverlight application.

Asked people what they think, got mostly positive appreciations. It would be interesting to see how this concept will evolve. It’s only an early sketch, done by a “more developer than designer”. How you like it?

Even if it’s talking in context of User Experience on Windows Phone, I think these numbers are a formal guidance for good user experience on every device, modern gadget or software application.

I’ll make a copy of this table here, just to keep it in a handy place for further reference. It’s so well worth keeping it…

Read, remember, apply!…

While he is talking about it in the context of concrete application, it remembered me transition from “traditional” toolbars to Ribbon bar, particularly in Office apps. Still, lots of people didn’t get the sense of the Ribbon, but I consider it as an improvement. The biggest advantage is feature discoverability.

Lets look at two screenshots. The first one:

First one is from Visual Studio 2010, a very traditional toolbar. Of course, there are other icons that being simple and intuitive give you enough confidence clicking them (think changing text alignment in Word). But to get a sense what will clicking on a unknown button will do you either will:

• get with mouse over it and read the tooltip (and you’re lucky if you have one, lots of application developers are not even bothering writing them)
• click the button and observe what happens
• forget the button and go to the menu and actually read trough menu items to find what are you looking for

Hmm, of course, over time you get more confortable with clicking on the buttons that look familiarly or are used often. But finding the features are still a pain.

And then second screenshot showing a fragment of a Ribbon bar. We’re having here not only icons, but also a small label giving an instant hint for what the action will do. Then you even have an sense of the context, these actions are related to “Editing” the document. Click target is bigger than a 6×6 icon. And there are other advantages…

Yet the first toolbar is looking simpler, takes less place and over time it is easy enough in use. But any time when I see a complex application with a considerable number of options and actions, I would prefer a Ribbon instead. It’s about discoverability. It’s about first impression your application is giving to a new user. If you screw that, you’ll miss the user too…

Still, the Ribbon it’s not a panacea. It is not suitable for any kind of applications. Document oriented interfaces are genuinely fine for the Ribbon. But when you have data intensive apps, with lots of interactions, contextual actions, flexible layout and navigation – Ribbon may be not your choice…

The thing I liked the most is how “cheap” are usability improvements. Change the caption of the button, remove that cryptic description, move important things higher and hide functions being rarely used.

And test it. Iteratively. It’s agile on it’s better form – pick a user or two and just let them do something useful in your app. Notice errors, fix it.

And test it, again…

Any developer occasionally or permanently is playing to role of user interface and interactions designer. Every time you are spiking an UI prototype or creating a data entry form we should keep in mind the user, usability and characteristics of successful user interface. What they are?

User interface should be:

• Clear
• Concise
• Familiar
• Responsive
• Consistent
• Attractive
• Efficient
• Forgiving

Read more, with details in 8 Characteristics Of Successful User Interfaces.

Take care of the users. At the end, they are paying your wages…