Data Tables like all other components align to a responsive grid structure and should maintain various visual alignment vertically and horizontally to insure visual consistency and ease of use.
Integers are right aligned with consistent number of digits across a report or within a single column, all other types of data is left aligned. Special exceptions to this rule and examples of each are listed below.
Column Header Row
The column header row should be visually distinctive from all other rows within the data table.
Column header names should always be left (or center) aligned based on the overall theme of your application.
Row Based Header
When data is row nested and the data table contains row based headers they should be visually distinctive from all other columns within the table (and match the treatment used for column headers).
Row based header names should always be left aligned.
Nested header rows can actually be reduced/avoided using different methods such as in Google Analytics’ model where rows of data are repeated essentially creating a flat table view removing the need for row nesting.
Each method has its advantages and disadvantages for the end user and data export, however we’ll save that for another article.
The type of data contained with the column determines its alignment within the grid.
If the data is a percentage, decimal or pure integer based and comparative in nature the information should be right aligned to allow for ease of reading.
If the comparative numbers contain currency, weight, percentage or other symbols as part of its definition these should be maintained as part of the number and follow alignment rules.
The main reason that alignment is so important and why integer based data should always be right aligned is readability. Users need to be able to easily scan the column of data to spot interesting points of data.
If you take a look at the next table where this rule wasn’t followed.
On quick scan the user mentally sees the number $877,689.73 as $8 million because the numbers proceeding it in the column are out to the millions. If we take this same table and right align the numbers in the column the user can easily mentally process the differences. Notice the $14,356,699.36 in the second column? Look between the table above and the one below and you’ll see how integer alignment makes it easier to see and understand values.
Like most things in life there are always exceptions to the rules the most common exception is the presence of compound numbers in a single cell or fractions.
In the first example you have a set of two different numbers within a single sell. This is pretty common when doing date comparisons such as week-over-week. The entire cell contents follow the basic rules or right alignment for numeric values and the decimals are aligned and all contain an equal number of placements (as illustrated by the orange lines).
The second example is fractions. Fractions unlike decimals can’t contain an equal length of numbers after the / which makes it difficult to get alignment. However; take a look at the two images. Which is easier to read?
I’m guessing you’ll say the one on the left. There are a few reasons that this is true. First all the fractions are aligned to the / which makes it visually easier to read. They also don’t contain whole numbers which the example on the right does and adds visual noise.
When aligning fractions there is no common rule on what is best practice. Common practice is to align the / between the numbers in the fraction like in the left example above but this doesn’t take into consideration how to treat whole numbers.
Text, characters and non-integer based numbers should be left aligned within data table cells.
General rule of thumb on numbers alignment... if you can add cell contents from two different cells within the same column and they loose context then they are non-integer based.
(zip codes) 60601 + 60095 ≠ zip code.
(product ids) 1234 + 3456 ≠ product id.
Also if a number contains symbols that do not define it as a single number such as a phone number (312) 555-1212 ≠ a whole number then it isn’t an integer or equation.
Phone Numbers and zip codes are like fractions in that they don’t contain a consistency of numbers when going international. There are no special rules for this and they should continue to be left aligned and follow the non-integer rules. When possible try to use a consistent formatting to ease eye strain for users.
Special characters can take the form of icons, notations (N/A, …, etc.) or snipes (corner triangles for notes within a cell) as well as empty cells and others.
When a special character occupies a cell exclusively it is centered within the cell to visually draw attention to it in order to inform the user that the cell contains a different context or element (checkbox, state, etc). Depending on the context it may also be colored differently, highlighted or visual made different.
When a special character occupies a cell as a definition of the data or information contained within the cell it can take on the form of a “snipe” (corner note) or follows/proceeds the data in the cell depending on the need.
This article focuses heavily on readability when it comes to alignment of cell level data. There are also several design oriented techniques that can be used to increase readability and overall data table performance for the user.
You can take a look at some of these articles for more on those items.
I’m always looking for additional resources so please leave a comment below and let me know your opinions.
Designing table data isn’t sexy and often UI/UX designers leave these patterns to development. Its important when designing for users that all the elements within your application are designed, communicated and made to give the user an overall easier and more enjoyable experience. The psychology of how people process information and how your application communicates those data elements can lead a user to greater clarity and ease of use. Even something as simple as data within a table matters.