On good web design

A few months ago I was looking for ways to improve the TurnKey web site. I spent a lot of time researching good web site design online by:

  1. studying the theory of web site design from such resources as "a list apart".
  2. "reverse engineering" the design of existing successful web sites:
    • Good.is online magazine / community
    • The Wordpress blog
    • Techcrunch
    • A List Apart (they're the experts on web site design and usability)

I payed especially close attention to the social aspects of the web sites I was studying as I was interested in improving the social experience on the TurnKey web site as well.

I wanted to improve my understanding of good web design in general. Not just for my work on the TurnKey web site. By then we were discussing our ideas for the TurnKey Hub and it was clear it would come in handy for that as well.

Besides, the principles of good web design and good usability in general are tightly related. Thinking a lot about one is a good exercise for improving the other.

Bottom line, I refined what I've learned so far down to a simple design methodology:

  1. Brainstorming: put into writing a list of ideas of items that should be presented to the user. Anything goes, in no particular order.

  2. Attention map: translate the brainstorming list into an attention map by:

    • Grouping related items: things that are really different parts of one design element
    • Ordering the high-level elements by priority (1, 2, 3...)
    • Translate the ordered elements into a drawing of blocks that divide the user's attention according to the priority we give the item.

    You do that by taking into account that users don't read or analyze pages, they scan them very quickly (e.g., a few milliseconds). The amount of attention that elements on the page receive are effected by their size and location. English audiences scan a web page top to bottom, left to right, so a large item on the top left has a much higher chance of receiving attention than a small item on the bottom right.

    Imagine that it takes energy for the eye to keep scanning and with each passing millisecond your visitor is more likely to stop reading, be distracted, make a decision, click a link, close the tab, etc.

    Questions we can ask ourselves to determine the priority of an element:

    • Is it informative? (e.g., blog post, related links)
    • How useful is it for the user? (e.g., search box or navigation links)
    • Is it a call to action? (e.g., sign up!)
    • Does it improve the credibility of the site? make it easier to trust us? (e.g., well known brands and logos, testimonials, blog archive)
    • Does it encourage community contribution? (e.g., list of top posters, recent comments box)

    Regarding repetition, in some cases it can make sense to have an element (e.g., RSS subscribe logo) in multiple locations. Careful use of repetition can improve user engagement.

  3. Functional implementation: translate the "attention map" design to a functional web site implementation. Pay minimal attention to form / styling considerations at this stage.

  4. Styling: make the website's functional information architecture look visually appealing

This sums up my thought process, and it seems to work pretty well in practice too. For best results try not to work on all the steps at once. I find I'm much more effective when I minimize mental context switches and focus my full brain power on each step separately.

Have you designed user interfaces or web sites? What process have you used?


Adrian Moya's picture

I was waiting when I had a bit of free time to comment on this issue, which I'm also researching and have a lot of interest in learning the tricks. What I've found so far is that there are two different worlds here, and each of them have it's own techniques:

There's the "traditional web design", where elements like big colorful images, flashy things and social widgets are abundant. The main objective in this kind of web design is presenting text information, articles, and making them easily readable. Also, the "hotspots" would invite you to subscribe, buy or share, tweet, etc. in social networks to bring more traffic to the website. Also presenting videos are getting an important role in this kind of design. Navigation should be easy to find the info you're looking for, with the ability to cross related info easy. Links to external resources is also abundant, and spaces for the users to express themselves (comments, polls). 

And there's the "web application design", which is more focused on presenting a simple but functional gui to the user of the system, with the main objective of making him productive while working with the app. Yo can forget about the colorful images and flashy things, replaced by clean logos and ajax components. The main type of info you'll be presenting is data. So you need to design a way to show something useful to the user. More tables and less text. Hotspots would be buttons to make actions over the data, navigation must be well designed also to know which module of the app you're working on. And as you're actions are going to affect data, you need more control and warnings and confirmation before doing things on the app, bringing you the need of designing coherent messages, windows and icons for these elements. Links are almost all internal to other parts of the app. 

These two worlds I've encountered share some common elements (tools and skills) that must be learned, and there are others elements that apply more to one or another. What I've found:

Common: 960 Grid System (for making the overall layout), learning css, html, javascript. Learning about color combinations. 

For web design: gimp and inkscape (for prototyping and then converting to templates), flash/html5 (I hate flash personally but maybe because I'm not into design), banner design, learning deep one or two cms of your choice and how to code templates and plugins for them (For me, wordpress/drupal). Typography is also important for sites with lot of text. 

For app gui design: jquery (both for gui effects and ajax processing), learning the template system of your programming tool (modern dynamic languages have very powerful template system). Of course you need to know "the business" to decide correctly what is going to be presented to the final user in each screen. Having a good icon set or knowing how to design cool icons (any suggestions?). 

Some applications may cross both worlds, which I think is the whole concept of web 2.0. So you need to start learning the two skills (programming and designing) or at least know the basics (I'm on the programmer side learning the basics of web design). Today, a designer who can't code is going to be in trouble (and viceversa!) 

Well, that's my two cents on this topic. Have you seen this kind of separation when designing? You'll need to be clear when cycling through your steps! 

Liraz Siri's picture

I thought of our previous discussions on programming and design when I published this post so I'm delighted you shared your thoughts. Besides I was starting to think from the silence that nobody really cared about my thoughts on this stuff. :)

Regarding the separation you suggest, I'm not sure the "two worlds" is a useful model for discussing how developers are using technology to get things done.

I focus on utility because I find semantic discussions tedious and unproductive. Concepts and words represent mental models which compress reality into symbols we can manipulate in our mind and communicate to others. They're always imprecise. That is a limitation of human language and that great "teetering bulb of dread and dream" that uses it. But precision doesn't necessarily matter if you accept that all models are wrong. Some of them just happen to be useful.

Case in point, the distinction between a "web application" and a "traditional website" has become so fuzzy that I'm not even sure it's meaningful anymore to talk about "separate worlds". I think the origins of the distinction are more historic than a representation of the current state of affairs. In the PC era an application would usually ran on your desktop and provide an interface with which you manipulate internal states interactively. Websites started out as online versions of magazines or books. With hyperlinks. There was no internal state to interact with. It was static.

Today, various tools are optimized for achieving different goals (e.g., Rails vs Drupal), but focusing on the tools while useful in the implementation phase is a distraction when you are thinking about a problem in the abstract.

My thought process when I am starting to design involves stripping away all the unessential details so I can keep my mind focused on the simplest abstract models and manipulate those. Boiled down to their essence a website or web application are just regular computer programs. With input, output and state. And all of the infinite variation that implies with no clearly useful categories. Some programs just print hello world, others simulate the big bang to test models of high energy physics.

When I think about it like that, a "traditional website" is just a program that is output oriented with very little to no state, which is designed to serve a mostly unengaged stream of temporary users. From that the rest follows. The importance of form over function, making a good first impression and making the interaction as familiar to the user as possible, which usually means following the conventions set by other "traditional websites".

A "web application" is a program that is more state oriented, serves a more engaged audience, so function tends to be more important than form. An attractive but poorly functional application will wear down the patience of its users quickly. From that too the rest follows.

Web 2.0? I've always disliked that buzzword, but if it means anything at all, then I think it means the state of the program is shared and manipulated by many users simultaneously. That seems to be the only thing that was truly innovative thing that applications labeled "web 2.0" had in common.

Adrian Moya's picture

Yes, everything ends up being bits & bytes. Html/css/javascript. We can be really abstracts when approaching a problem. But we are talking design here. Visual design I understood. So there's a point in which you can't simply leave it so abstract. You need to understand you target. Is not like a webservice, where it's not important what happens inside, which language, if its follow code standards or not, because it's a black box, you simply see the output. But in design it does matter what's the intended target. Yes, it's fuzzy the distinction between web app and web site. But it exists. IMHO I can't sit down and apply the same rules for designing the Turnkeylinux Website and the TKLDevEnv app. Both are completely different in my mind. Of course, that's me, that's the beauty of being able to solve problems with different approaches. And sharing them here :)

Now that I think, the same goes for an application. There are different kinds. Yes all of them are code. We can make UML diagrams of them. But there's a point where you need to be a bit more specific. How many users are going to access the app? The design won't be the same for 10 users than for million users. (I'm talking here the components design, ie, using a queue to process things instead of procesing them on the fly). 

But I agree with you in that both are the same at the end. Code. And yes, we can forget about the tools in the process of the design. We can't design thinking on the tools, otherwise our creativity would be limited by those tools. I did mentioned them because I'm curious of what the people use to implement their designs. Lots of people work in the windows world and their photoshop/dreamweaver. But my research suggests that at least there is a way to do it opensource. 

Anyway, maybe we just see two different phases of design here. You'll be talking about the very initial process and I'll be talking about the second revision, or starting to focus on the usability.

I also like the idea of using pen & paper, to have a general idea of what you want before starting to do a mockup. To be honest, I've never done it, but I haven't design much in my life. But in my mind, I do set them on paper! Is just that I often think about this in my way to work/home. So I don't have pen/paper to write down. I have some ideas for the TKL web I'd like to share with you, but I have not downloaded them from my mind. Maybe if I set you an ssh user? :P There are lost in these forums, but images speak louder than words. So I'll see when I can put them on paper for discussion. 

Martijn Meerts's picture

I started as a designer, but gradually moved more towards the developer side of things. These days I do a bit of both, but I tend to only make 1 or 2 designs per year that I'm actually really happy with. Of course, I mainly design for personal sites/projects, so 1 or 2 per year is more than enough :)

I don't really follow any set of rules or guidelines. I make a few rough sketches on paper to see if my general idea for the site itself as well as for the design would work. After a few days of sketching (not full time of course) I start mocking up the design in Photoshop. That can take anywhere from a week to several months before I have something I want to try to convert to XHTML. The project I'm working on now, I've mainly worked on in the train going to and from the office, so it took a long time to get anywhere. It seems like a good way to work though, because I'm rather happy with it :)

Design wise, I tend to go fairly minimal. I don't often look at other websites for inspiration, because I tend to "borrow" too much and end up with a site that I feel is not my own design. I do some Objective C/Cocoa programming from time to time, so Apple's design ideas and HIG do shine through a bit. I like light colors, often going for a slightly off-white background color and a dark grey for the text color. I also often use a dark red for links and little design highlights. My current project will also add quite a bit of jquery, jquery ui and css3 animations. Nothing fancy, but just small things to add to the user experience.

I sparingly use icons, and when I do, I either use the Fam Fam Fam icons if I need small ones, or find some on iStockphoto or similar sites. If I ever get to the point where I have an OS X and/or iOS app, I'll definitely get an icon designed by something like The Icon Factory. Can't imagine they're cheap though ...

For the programming side of things, I've used a whole slew of things. I've made a (small, private) CMS in asp, did some E-learning stuff in Coldfusion, an interactive store in Flash, and a whole bunch of things in PHP. Now that I'm also doing Objective C though, PHP is starting to look like a bit of a mess. It's quite possible to make PHP code look good and be manageable, but I don't seem to have the patience for it. I've been learning some Ruby on Rails the past months (also in the trains ;)), and I'll be using that to run the new project (using a VPS running the Turnkey Rails appliance.) I'll have to code everything from scratch though, since what I need doesn't really exist in any language. Since my experience mainly comes from non-OO languages, my code tends to look terrible without even so much as a hint of any design pattern :)

Oh, and I never use any wysiwyg editors like Dreamweaver. I've just never come across anything that was actually worth it. The few times I tried I ended up spending more time cleaning up the generated code than it would've taken to just write it. I don't use many tools actually.. TextMate for programming anything except Objective C, for which I use Xcode. Other than that I use Photoshop a lot, Flash occasionally, Transmit, Sequel Pro and the Terminal.

I don't consider myself a professional though, and I seem to have my own way of doing things that isn't compatible with anyone else. Doesn't matter though, because I tend to be the only developer on projects anyway, always worked at small companies, and quite like it that way :)

Liraz Siri's picture

I'm a bit of a minimalist myself, so I believe perfection is achieved not when there are no features left to add but when there are none that can be taken away.

I try to minimize my toolset. A simple window manager (fvwm), a good text editor (Vim, which I converted to from Emacs), a shell console and occasionally a browser.

But strangely enough, by far the tool I am most productive with is an empty paper notebook. When I'm designing I take a notebook and a pen on long walks and just think. No chair, screen or keyboard. The open space frees my mind. If it's a really hard problem I can walk for many hours. I usually come back with the satisfaction of having something to show for it. There are some squiggles on paper but the main fruit is the shape of things formed in my mind, ready to be birthed. The human mind, free from distractions and focused appropriately is a marvelous engine of creation. It never ceases to amaze me when a new design somehow works as intended once implemented.

Unfortunately, the magic only works when I already have all the basic ingredients imported into my head and adequately understood. When I don't have the time or patience to do the research required to do that, I revert to slow incremental progress using an exploratory process that relies heavily on trial and error. With ever increasing layers of complexity and reliance on third party tools I'm having to do that much more than I used to, and it's not nearly as productive or enjoyable. But maybe that is just a signal that I need to depend on less tools / libraries or at least understand them better.

Martijn Meerts's picture

I often scribble stuff on paper as well. I might have this idea in my head that I think is really good, but once sketched out on paper it turns out to be utter crap. There was a time when I started drawing up very detailed, near final mockups in Photoshop when I had an idea, and then waste many, many hours because it just didn't work. A sketch on paper is just as effective, but only takes a fraction of the time to create.

I do the same with the couple of iOS / OS X app ideas I have, I first sketch all the possible UI screens on paper. There are various templates for prototyping iPhone/iPad apps, but I find when I use those, I end up getting to much into the small details again, and lose track of the general overview.

I actually don't think it's possible to not come up with features to implement. There's always something that seems like a good idea to have, but ends up never being used, and just bogging down the site/application. What I'm trying to do with the new site I'm working on, is to get the core functionality up and running, and then just see what kind of features people want to see. If something gets requested enough, it might be worth implementing.

I've also had quite a few months recently where I just didn't feel like building home pages anymore at all. I thought I'd done enough of them to last me a lifetime. When I started thinking of a new project though, a friend mentioned I should try Ruby on Rails for that project, because it'd be easy to set up. Looking into it, I found I was genuinely interested again, and initially thought it was because of Rails. Now I know though, that it's not Rails, but frameworks in general. Not having to write all those boring SQL statements and CRUD functionality is just great :)


Add new comment