I'm Ben Turner, a user experience designer / developer and I'm all about enhancing user interaction on the web - this is my blog and play area.
Origin: Ctrl Alt
Now before I start I just want to point out this isn't an article about whether you should use tables for layout. You shouldn't. If you want to go over that antiquated argument look elsewhere. This article's just about getting the best out of tables.
Whenever I'm thinking about using a table I ask myself the following questions first:
1. Does the information or data best suit being in a table in the first place?
2. What's the most important information that needs to be displayed?
3. Where does this information fit in with the rest of the user journey?
4. What does the user want to be able to do with the information?
5. And lastly but equal important what do you want the user to do?
It's important to take time and consider the content. How do we ensure the best interpretation of our data - how it should be presented to the users?
Just because content often comes in a spreadsheet it doesn't mean it should stay that way. It's important to resist just copying information across. By putting content into a table you're being prescriptive about how the content is going to be read. While that is far from a bad thing you do need to make sure it's what you intended.
Knowing how the web works and how a page is coded can help inform how content should be structured. It's key to start any design with the base content well thought out and symantically structured. It's then much easier to layer design and funtionality on after.
Obviously the first point to make on this is - if it's not important what's it doing there? However there will always be a heirachy to information in a table. It's unavoidable. Whether it's the first few rows at the top, those details that take up more space, or any information that has link in it, for example, will all be deemed to be more important.
Since there will be a perceived importance to the content anyway - you need to make sure those perceptions match the users needs.
Decide what information is to be promoted just that bit more or what can take a step back. Think of the goals of your user. Is the table helping the user compare products against one another. Is it a detailed spec about something technical. Whatever the purpose of the table it needs to have clear visual handles that can help a user scan and make sense of what's in front of them.
Once you have got the information as you want it, show it to someone else, ask them to perform a suitable task with the information in front of them. Can they find the cheapest product, or find some specific detail. Performing this task before applying too much styling will give you more accurate feedback as to whether the contents organised properly.
If it passes this test and you are comfortable there isn't a better way to display the content then defining where to put the information is the next task.
It depends. What is the table doing? How much information has it got in it? Has it got lots of details about one item or is it an overview of lots of things?
Planning where the table sits in the site is as important as what information sits in the table itself and the two should inform one another. Hiding a table full of useful content within a site isn't going to help users, likewise though, having too much on the homepage is probably going to confuse and overwhelm them.
I think you probably get the point. But the important message here is that as well as planning the information in the table the tables should be planned in the context of the site too.
What are the sites users like? What are they looking for? What have they come to your site to achieve? Knowing the answers to these question isn't always easy but understanding and empathising is all important when it comes to user centred design.
Making sure the user is a the heart of problem solving is paramount. Indentifying areas of potential frustration is so much easier if you can step back and look at it from someone else point of view. Or better yet do exactally that. Step back and watch a user try to use the content you have created in context and record where they a having problems.
Ultimately you should have a goal when you start off designing your site or page and you also need to keep that it mind. If you have a key measure for success it much easier to assess if you've done a good job.
Although once it's deployed that's not the end of the cycle, monitoring it after it has gone live will give you a great insight into how it's done. If you have the ability to AB test a design against an old design and or multiple variations of your solution this is always a good idea and can be really informative. After all putting a little science behind the decision is what make us designers rather than artists.
Good luck with your tables.