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.