Web Design 101 for Developers

Let’s do some role playing. 2 days before a product launch, your manager comes up to you (a developer) and tells you that you have to make the administration panel for the application (the spec guys apparently forgot about it and you were happy entering records directly into the database throughout the dev cycle). Or a separate flow for users with minimal access rights. Or better yet, there’s no designer or ‘UI guy’ in your team and you (yes, you the developer) have to come up with the entire UI flow for the application. Sounds familiar doesn’t it?

I’ve personally been a part of a couple of projects that have had 90% of their UI work done by developers. One got rejected by the client. The other didn’t do too well either.

So how do we fix this? How do we get an everyday developer to understand the touchy feely word of web design and usability? Developers are used to working with things that are precise, fixed and deterministic. A Boolean is either true or false. Don’t expect the poor things to understand why 70% of users won’t notice the elaborate list of steps that they’ve put on the page to make the UI look easy. Nor why navigation is best placed on the left or top of the page. Or why it’s not always good to make everything clickable. Or why drop downs really do suck as navigational elements.

The first and most important step is to realize that not everyone using your site will be as web savvy as you. Or will even understand what the site is for. Don’t assume that users of the site will be anything remotely like you. Even if you’ve worked on an application for 2-3 weeks, your opinion regarding the UI won’t count because you know too much. You understand what the application is for, where you’ll find a certain set of options, and how you’ll go about using a certain feature. You have to wipe the slate clean when evaluating your UI. If you realize this, and before making any change in the UI you make a mental check of how will the user use what you’ve coded up, you’re well on your way to becoming a better and more versatile code monkey.

The second thing to keep in mind, in fact this should really be the acid test for your UI, is that a user should be able to find their way through the site if they’re plopped onto an intermediate page in a flow. A user should never feel lost. Consistent UI elements, breadcrumbs and ‘ejector seat buttons’ all help in making the user feel in control of things. Remember, the more ‘in control’ the user feels, the more satisfying, relaxing and fulfilling their experience will be.

I remember the first time I had to make a UI. I was completely stuck at the very beginning. I didn’t know where to start. Making DAO’s, POJO’s and Managers was all fine and peachy, designing a UI flow was a completely alien concept. What you need to do is start with the 6 basic parts of a web page:

Page layout elements

  • Site ID/Site Logo – This has to be the identifying symbol of your site. If it’s an admin panel you’re making, maybe it will be the logo of your site with some ‘admin like’ embellishments (a cog, key, or lock). The logo usually has the tag line as well (which is a separate topic in itself … just remember that the tagline is really important). The Site ID should always be clickable and take the user to the home page. It’s like the ultimate ‘ejector seat button’, no matter where the user gets lost, they always know clicking on the Site ID will bail them out and take them to the home page, where they can start over again.
  • Global Navigation – This will be the set of links to major portions of the site. If your site is small, you might have only a couple of links in your global navigation. Also, this doesn’t have to be on the top of the page, many sites have their main navigation on the left vertical side of the page as well. Usually your logout, feedback and other such ‘convenience’ links go in the top right corner of the site as well.
  • Breadcrumbs – If your site has a deep hierarchy, and your navigation doesn’t highlight the current level of depth, then breadcrumbs are a great way of keeping context of the user’s path. Elements in breadcrumbs are usually clickable (except the last element, which should be the name of the current level).
  • Page Name – You should always tell the user where they are. If you’re not using breadcrumbs, then a standalone page name should always be present. The page name helps in reminding the user what they’re doing on the page and gives a label to their current task.
  • Local Navigation – These are mostly links which drill deeper into the site hierarchy (increase levels in the bread crumbs). These will probably change as you go to different sections of the site, but they should always have a consistent look and feel.
  • Content – Put whatever your page does in here.

Remember, this is just the orthodox way of organizing a page, you don’t have to use such a layout, although using it or something similar will ensure users will have a better chance of noticing things that you’ve put on the page and getting a better feel for how things work on a page and the application as a whole.

Apart from these basic parts of a page, there are some general concepts that you should keep in mind as well:

  • Consistency, Consistency, Consistency. This is the easiest and most effective way of making a user familiar with your application. Everything should look the same on every page. And it’s not hard to do either. Just have global default styles defined in your style sheets for your basic HTML elements (body, a, label, input, h*, p should be defined as a minimum since they’re the most common). Break up common parts of your pages into templates and keep them separate from the ‘content’ part of your page.
  • Don’t bombard the user with options. Giving too many choices to the user or too many things to click will only add to the noise on the page, which will keep the user from doing what they actually want to, or should be doing. If there’s a large form that needs to be filled out, break it up into pages. Use tabs to separate out related options etc.
  • Also give the user a way out. Every step in a flow should have an exit button. Every modal window should have a cancel button. There’s nothing worse than leading a user to a dead end and not giving them an easy way out. There are of course certain exceptions, like the purchase flow. Most sites if not all usually take away all clickable distractions after the user checks out the cart and is in the payment process. That’s understandable, since you don’t want the user click away just before hitting the ‘charge my credit card’ button.

So my fellow developers, I hope I’ve shed some light on the problems (and solutions) that we face while standing in for our designer cousins. This post is just the tip of the iceberg of course, but do comment if you feel that I missed out something very important.


One thought on “Web Design 101 for Developers

  1. […] this rant makes some sense to you and will help you in structuring your pages better. If you think I got something wrong, comment and be […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: