Tables and Data

Okay, so here is a problem I encountered at my work recently:

On a datasheet for a group of products, there was a table on the front and another table on the back. The front table was glossary information about each product, and the back table was detailed data, lots of data. The sort criterion on both tables was the product model number and they were organized alphabetically. So we had products 7C, 7D, 7M, 7P, and 7X.

The problem came when the sales team tried to use the table on the front to tell the customer about the products. While the products were arranged alphabetically by model number, the characteristics of the products seemed to be all over the map, making the information hard to sort out. I would guess a potential customer would have a hard time using this table to make a good decision.

According to my subject matter expert (a sales person), there are usually only three points of information the customer wants to talk about. They are enclosure durability (the case), the engine, and the firmware. Instead of organizing the information based on the name of the product, I organized the information based on the enclosure durability.

I chose this criterion using this logic:

  1. More people want to know about the engine or the enclosure durability. Only a few people want to know about the firmware.
  2. The enclosure durability was something that could be made visible with an image to accompany the data.
  3. The glossary table on the front can help the customer make a decision about which model would best suit their needs.
  4. The detailed table on the back, organized alphabetically, can be used as a reference tool.

This is a better organization of the information altogether. Now the sales person can present the products in terms of the durability of the case, and then move on to talking about what the customer needs in an engine or firmware. When they are ready to find out more about the product, they can turn the sheet over and find the model number in the table on the back.