I'm currently involved in a project that focuses on tracking the time spent by team members on various projects. We are facing a dilemma regarding whether to include the 'h' notation in the 'Work hours' column to represent hours and on various cards on dashboard. Below are wireframes illustrating examples of both approaches.

  1. Without h

enter image description here

  1. With h

enter image description here

Which version makes more sense from UX standpoint? Are there any alternative solutions that might better address this case?

  • TBH, most apps I know use your second version. However, I think the version JazzRo and Harrison (alt 2) suggested in their answers are the better ways
    – Devin
    Commented Nov 28, 2023 at 19:17
  • Bizarrely enough CLDR does not have duration formats, but you may want to look at TC-39 Intl.DurationFormat, because you'll probably need to localise all this at some point, and not everybody counts in h, m, s
    – jcaron
    Commented Nov 29, 2023 at 23:54
  • 1
    The column is already labeled "hours", so in my opinion the "h" is just useless clutter. Commented Nov 30, 2023 at 0:37

5 Answers 5


The suggested format of 8:30 can be confusing for durations, especially because it is also used for the start and end time.

The h is not a common addition for that format and can confuse people as well. It is normally written as 8.5 h. But some people read it as 8 hours and 50 minutes instead of 30 and it becomes even more difficult to interpret when it is precise to the minute.

If the 8:30 format is the way to go (whether or not due to technical constraints), explain the format in the header: Working duration (h:m). But this is not ideal.

I recommend using the 1 h 30 m(ins) format instead. It is the least ambiguous. To keep it readable/scannable, you may need to be clever with the design, such as playing with the font weight and size of the number or and/or unit, use a monospace font or separate hours and minutes in different columns etc.

  • Just to add to this excellent answer (I manage timesheets for developers for over 50 clients). It also depends on whether you relate that time to costs or other aspects requiring calculations (e.g. 8.5 hours * $50/hour makes far easier reading for the client). If the client only needs to see h:m then either works, but further processing of the data can mean leading to one approach or the other. In our timesheets we use both h:m plus a decimal hour column, so 1:30 is mirrored as 1.5.
    – EvilDr
    Commented Nov 30, 2023 at 12:11
  • 1
    I think the standard notation for time (in the sense of duration, not date) in the SI system is 2 h 31 min 45 s, as you and other(s) answer(s) write. Could not find an exact reference for that.
    – Pablo H
    Commented Nov 30, 2023 at 13:37

I think this is going to be opinion-based no matter what, so here's my standard way of doing it:

1d 2h 3m 4s

One day, two hours, three minutes, four seconds.

Omit some components as appropriate for the context - or, display the first two non-zero components and omit the rest (being sure to round down).

Spaces go after the letter and before the next number, not before the letter.

Don't display leading zeroes.

Don't use dots or colons and definitely don't put a unit after a colon ("08:20 h" makes no sense to me).

Here's your examples in this format:

  • 2h 4m
  • 3h 6m
  • 22m
  • 51m

Nice and readable IMO.

  • 1
    Is 1d 24 hours or a workday (8h or 6h or even 4h depending on the contract)? Commented Nov 30, 2023 at 19:15
  • 24 hours - this is a generic solution for displaying durations. Even in a specific context I wouldn't recommend using 'd', as a unit of time, to mean something other than 24 hours. (It's also perfectly valid to just not use the 'd' component at all, and display arbitrarily large numbers of hours, if that more suits your use case.)
    – Keiji
    Commented Dec 1, 2023 at 8:04

While I agree with Keiji that the ultimate answer is likely to be opinion-based :), there is a standards based solution i.e. ISO 8601 wiki iso.org. The relevant section is 5.5.2 Duration which begins: General

Duration can be expressed by a combination of units — years, months, weeks, days, hours, minutes and seconds — with designators. A duration expression shall begin with [“P”].

The P in the above quote is for "Period", and the T below is for "Time".

The OP's examples using ISO 8601 are:

  • PT2H4M
  • PT3H6M
  • PT22M
  • PT51M

These are, unfortunately, somewhat cryptic and so I can't really say no to Keiji's format which is a simplified and friendlier version of ISO 8601.

I mention ISO 8601 a) for completeness and b) as a reference for how to do (almost) all things relating to time and computing. See also this (somewhat) related question and answer https://stackoverflow.com/questions/51168022/what-does-pt-prefix-stand-for-in-duration which is for Java but is applicable in other contexts.

  • 1
    Cool, I hadn't heard about that one. Standards are great :-) However, if the standard form is not well recognized among the people who have to work with it, then don't forget that you (er, the OP) have to evaluate the tradeoff between standard compliance and ease of use.
    – David Z
    Commented Nov 30, 2023 at 7:44
  • 1
    While human-readable, that format is definitely intended for computers (e.g. for use in JSON, XML or other machine-to-machine formats), not for UI.
    – jcaron
    Commented Nov 30, 2023 at 12:40

This seems that it could be more of a matter of personal preference...

Typically in tables, the units are either added in the column heading, or in every cell (as you have done for the last column).
When the latter is done, users will begin to ignore the extra characters as they become familiar with the system, so the focus becomes more about instant legibility. This is why in the last example I deliberately add extra characters for the edge-case, as it would make the cell would look noticeably different and a user would focus on it more than "usual".

In option 1 the times are quite clear, but could the leading-zero create minor confusion for some users. At a glance the final column could be misinterpreted, reading as "four minutes past two, AM) To counter this, perhaps simply removing the leading-zero could help here:

Option 1 alt:

Avg. Project Duration

I find the "h" a little moot in option 2, and would likely opt more for option 1, but if option two ended up being the prevailing preference, it could be modified slightly:

Option 2 alt:

Avg. Project Duration
8h 4m

Adding both "h" (hours) and "m" (minutes) could lead to a more easily extensible solution. Consider the following:
A task has taken far longer than anticipated, taking days of effort (or even time has been tracked erroneously)

Currently the UI would look like:

26:04 h

If the time is not an error and the colleague has indeed spent several days on one task then the above certainly looks strange. A user may have to work out the total time taken (if not already obvious like in the example), but if "Option 2 alt" were adopted, it could be easily extended like so:

1d 2h 4m


  • Option 1 without the leading zero
  • Option 2 could favour quick legibility, providing time doesn't go beyond "24 hours"
  • 1
    Please, please, leading zeroes 08h 04m.
    – hlovdal
    Commented Nov 28, 2023 at 21:47
  • 2
    If 26 hours were spent on a project, it probably took far longer than "1 day". The 1d 2h makes sense for a timespan than ended 26 hours after it started, but less so for an accumulated 26 hours of work than perhaps occurred over the course of several days; in the latter case, leaving 26h may be more clear.
    – Ralph J
    Commented Nov 29, 2023 at 15:50
  • @hlovdal why? if the numbers are aligned properly why use the leading zero? I think not using leading zeros helps to avoid confusion with clock times.
    – ACarter
    Commented Nov 30, 2023 at 16:09
  • oth 26h is the amount of billable hours. 1d 2h could be interpreted as one day worth of billable hours (tipically 8) Commented Nov 30, 2023 at 19:16
  • @hlovdal Definitely not. Even coming from a culture that's exclusively 24h and always uses leading zeroes for time display, I wouldn't add it to a duration. Leading zeros have two roles, first, to make sure time lines up correctly in columns and to make it much more obvious that a display of NN:NN is automatically a time. None if these apply here.
    – Gábor
    Commented Dec 1, 2023 at 11:26

It does not matter one single jot

If this was a display going to be flashed up at people once and they were expected to understand it, then adding the clarification might help, but its not. It's a system that is going to be used by people on a regular basis over years. They will know what it means, without confusion.

Any non-stupid means of showing the duration will be fine in these particular circumstances

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.