UX Magazine

Defining and Informing the Complex Field of User Experience (UX)
Article No. 40 March 21, 2006

Design 101 - for programmers

Programming is an underappreciated art form. It is there, in the background, invisible to but a few people who usually are looking to fix it, copy it or simply understand it.

A successful human interface can make the most complex functionality work at the click of a button which in turn keeps the code hidden from the end user. Since the UI is the only way programmers can share their craft with most end users they have to come to terms with the fact it is immensely important to them.

Time and time again I’ve come across systems powered by very clever coding be criticized on first impressions because of the lack of proper “skinning”. That reaction is understandable. Indeed, most people shouldn’t have to understand the complexities (sweat and tears even) that go into building that modular 8 page data entry form, or the amount of database retooling developers have to go through every time they say “You know what, we need to store the XYZ and the ABC that goes with it”.

What people do understand is the way the buttons react, the layout of the tools, the clarity of messages. This is the finished product and the only way most users will get to determine whether a system can or cannot help them. The coding and design go hand in hand. When developers say “this is ready to demo” we should make sure that what we show is close to the final this. Developers have to take a step beyond just writing the code and get involved in the process of creating the human interface. Similarly, designers need to work with developers to create standards and guidelines that will bridge the two skill sets hopefully resulting in better applications (and far less arguments).

Being a space shared by developers and designers, Netymology has developed some ground rules that we mostly try to stick to:

Semantic for the people. While coding output templates try to add basic classes to elements. Give them standard names (possibly ones you have agreed with the rest of the team). No need to get too hung up on this, things can be changed but looking through code for something with the class “help” is easier than looking for some obscure code snippet, especially for a designer.

Make all messages in the UI meaningful. In the chaos of a project, small temporary fillers can be overlooked and can be embarrassing to have a customer call you after seeing a tooltip that says “Thing that makes the thingy work” 2 weeks after launching. It doesn’t take a lot more effort to put in “Please enter your phone number”.

Set a glossary of terms to use throughout the application. This will also help when you’re naming variables or database fields and prevent things like “items” and “products” being used to describe the same thing.

Do some usability testing. Obvious? We’re a small shop and don’t have a dedicated UI department, but we try to get as much feedback from people in the team to see if the layout makes sense, even in early barebones states. Sometimes when you’re busy coding, looking at the same screens everyday can make you miss the bleeding obvious like a missing link or logout button.

Make things look nice. Or at least decent. If you can’t get a final design working on time, go minimal with a base CSS. Make fonts and buttons clean (padding goes a long way) and try to put in customer logos whenever appropriate. Use white backgrounds and black and grey sans-serif fonts. Don’t use Comic Sans no matter how appropriate you think it is. Try to add small icons in buttons when you think a page looks bland. You can find a ton of fantastic free icons on FamFamFam or the Tango Project.

Visualise. If possible try to draw out how an application is going to look. Make an HTML mock-up, discuss it with others. Get a whiteboard, doodle, scribble, colour, whatever. In many instances a tangible representation will do a better job than the most detailed chart at spotting a flaw. Cut and paste elements from existing sites which you feel work. Get that image out of your head and share it with others.

Don’t $#^ing swear. Never put something in a source comment that isn’t meant to be read publicly (this goes for things like “$#%ing thing took me all day to do!”). Admittedly, code usually remains obscure but we have all come across instances where a server misconfiguration led to code being displayed instead of the generated page. Funny? Often. Embarrassing? Always.

Truthfully, I break these rules regularly but find that everything works out better when I don’t. If anything, thinking, even on a basic level, about style and design allows you to visualise outcome better which in turn helps the coding process.

While we’re on the subject, we are developing a very basic clean stylesheet for programmers to use while developing web applications. It will define some clean, basic classes for most circumstances such as error messages, forms fields, and buttons. If it’s good enough we might be inclined to release it together with links to free icons and tools. What would you like to see on your clean sheet?

ABOUT THE AUTHOR(S)

Add new comment

Comments

96
95

that was funny, especially the “don’t %$#^ing swear” part. i would have to agree though. my programmer and i work very closely because of what you explained here. we must. we both realize that we are not independent of each other. we like to say, i make it look good, he makes it work. =)

great post, thanks.

87
89

Your comment about using the entire team in a small shop to test and proof is validation of what we do. Technical people often don’t value the importance of non-technical personnel in the evaluation process. However this step is especially if the intended end user is non-technical.

104
93

great post. might be the first time i have ever seen an article on design for programmers. much of the typical old-school stuff i have seen urges to “make it work, then make it pretty”. i can’t stand that, i’m a programmer who’s a frustrated artist.

on the clean sheet: how about form definitions that make switching to a different color theme easy ? maybe with comments “storing” 3 themes: red, green & blue ?

88
96

Thanks for your comments!

I would like to make the stylesheet as simple as possible, but it would be a great idea to have some hex color palettes in the comments. I always end up asking the designers to “give me a light color that goes with #000042” or the like, so it would probably save everyone time :)

96
92

Great points all around. The thing I probably think is the most easily ignored issue is the consistancy of terminology. This basically is the informational equivilent of having your color scheme different for certain pages.

Nice read.

86
101

Everything so true. Sad enough it has to be said, as it should be self-evident. Bottom line: Don’t let engineers (I’m one of those on my own) create the UI alone.

PS: The link to FamFamFam (good resource!) needs to be complete (http://www.famfamfam.com)

91
85

Great advice, especially about visualize. Do it. And do it often. In a pragmatic environment this will save you tons of specs and paperwork. When I come think of it, it might save some forrests, too ;-)

82
96

I think the base stylesheet is something I, as a programmer, would really, really love to use. One of the great things about developing Cocoa applications for a platform like OS X is that all the UI widgets are attractive, and the UI design tool gives you good guidelines for spacing and text sizes. When designing a web UI, I don’t get the same level of support. A nice base GUI toolkit would be awesome. A clean sylesheet would be a great beginning.

87
85

Thank you so much for the links to the free icon resources – I have been looking for 2 years for good, free 16×16 icons for Web site development.

This is the first time I’ve been to your site and I love it – the design, content, everything!
– Shawna

93
88

Thank you so much for the links to the free icon resources – I have been looking for 2 years for good, free 16×16 icons for Web site development.

This is the first time I’ve been to your site and I love it – the design, content, everything!
– Shawna

83
89

I think the base stylesheet is something I, as a programmer, would really, really love to use. One of the great things about developing Cocoa applications for a platform like OS X is that all the UI widgets are attractive, and the UI design tool gives you good guidelines for spacing and text sizes. When designing a web UI, I don’t get the same level of support. A nice base GUI toolkit would be awesome. A clean sylesheet would be a great beginning.

90
101

Great advice, especially about visualize. Do it. And do it often. In a pragmatic environment this will save you tons of specs and paperwork. When I come think of it, it might save some forrests, too ;-)

87
94

Everything so true. Sad enough it has to be said, as it should be self-evident. Bottom line: Don’t let engineers (I’m one of those on my own) create the UI alone.

PS: The link to FamFamFam (good resource!) needs to be complete (http://www.famfamfam.com)

84
94

Great points all around. The thing I probably think is the most easily ignored issue is the consistancy of terminology. This basically is the informational equivilent of having your color scheme different for certain pages.

Nice read.

90
90

Thanks for your comments!

I would like to make the stylesheet as simple as possible, but it would be a great idea to have some hex color palettes in the comments. I always end up asking the designers to “give me a light color that goes with #000042” or the like, so it would probably save everyone time :)

95
92

great post. might be the first time i have ever seen an article on design for programmers. much of the typical old-school stuff i have seen urges to “make it work, then make it pretty”. i can’t stand that, i’m a programmer who’s a frustrated artist.

on the clean sheet: how about form definitions that make switching to a different color theme easy ? maybe with comments “storing” 3 themes: red, green & blue ?

84
88

Your comment about using the entire team in a small shop to test and proof is validation of what we do. Technical people often don’t value the importance of non-technical personnel in the evaluation process. However this step is especially if the intended end user is non-technical.

88
91

that was funny, especially the “don’t %$#^ing swear” part. i would have to agree though. my programmer and i work very closely because of what you explained here. we must. we both realize that we are not independent of each other. we like to say, i make it look good, he makes it work. =)

great post, thanks.