One month ago (on May 9th, 2017), Timing

was released. Time for some navel-gazing!

More seriously, development started in April 2016 and the app’s interface
changed quite a bit over the course of those 13 months:

Timing 2 Alpha 1 vs Timing 2.0 final. Significant differences, yet recognizably

This article illustrates how an app’s UI evolves during development, and
highlights some subtle but important changes.

If you aren’t interested in the evolution of the app, scroll to the end of the
article for a side-by-side comparison and a summary of some little changes that
had a big impact!

Alpha 1 (July 5th, 2016)

Timing 2’s initial concept revolved around “smartly” recognizing blocks of
uninterrupted time and displaying them as separate groups. While the first alpha
already recognized the blocks correctly (as illustrated by the timeline), the
activity list was way too noisy to be even remotely useful.

Also, note how rough the interface looks — but that’s expected for an app in the
prototype stage 😉

The alpha also included a mode that grouped by application and file instead of
by time — somewhat more useful, but it wasn’t even the default:

As you can see, even Timing’s rule editor is
already present, but still very simple.

Alpha 5 (August 24th, 2016)

This version already had cards that group activities by different criteria (see
here for an
explanation). This turned out to be much more useful in than the grouping by
time or by duration.

Also note the AutoGroup button in the toolbar. That feature would try to detect
blocks of time, letting users quickly create tasks for these blocks. While the
idea is very useful (and still present in the final version), having to go
through these blocks one-by-one was cumbersome. Plus, the button in the toolbar
didn’t make for a very discoverable feature.

Alpha 7 (October 19th, 2016)

The AutoGroup button was scrapped and replaced with permanent suggestions in the

These are more accessible and easier to use, as one can pick and choose
individual suggestions to use rather than having to go through all blocks

Notice the new tab bar that leads to the ugliest dashboard ever:

Alpha 7 also marked the introduction of a (still very bland) onboarding

Alpha 10 (November 7th, 2016)

Replaced the ugly dashboard with a different — but still ugly — one:

Around this time we hired Eduardo Santos to help
design the app. You can already notice the first effects of his work in the
much-improved timeline 😉

Alpha 13 (November 17th, 2016)

Eduardo’s work is becoming much more noticeable, for example in the improved tab
bar and task editor.

Alpha 17 (December 6, 2016)

We have a proper dashboard! Still ugly, but getting there.

Alpha 19 (December 16, 2016)

Much better! This dashboard is actually surprisingly close to the final
It even featured a responsive layout:

The Review screen has made some progress as well:

Notice how there are scrollable lists inside a scrollable container. That turned
out to be a terrible idea — it makes scrolling incredibly frustrating. (I take
full responsibility for that…)

It was finally time for the…

Beta 1 (Jan 12, 2017)

At this point, we felt confident enough to circulate Timing 2 to a wider
audience — even the project editor was fairly close to the final


Until May, nine more betas followed (including additional features, such as
manual time tracking, a reports screen, AppleScript support), but the overall
design of the app changed surprisingly little from this point.

Timeline changes in detail

At first glance, the timeline hasn’t changed much over the course of the

Yet what a difference these changes make!

  • The task suggestions make it much easier to assign whole blocks of time at once.
  • Coalescing short activities makes the timeline much less noisy and easier to
    comprehend. (We could probably coalesce even more aggressively.)
  • The app icons on the timeline make it easier to see what a particular timeframe
    was about (note e.g. the block of development between 10:00 and 11:00).
  • The row labels, combined with improved typography and colors, make the timeline
    appear much more friendly.


We could have stuck with our initial approaches for the activity list and
automatic grouping and moved on. But the app would have been much worse for it.
Luckily, we were able to step back and try different approaches that ended up
working much better:

  • We switched from grouping the activity list by time blocks to grouping it by
    four different criteria instead. This made the activity list(s) much easier to
    parse and lets you quickly get an overview where your time went, without having
    to dive in.
  • The initial version of automatic grouping had you go through each block of time
    one by one, which was a pain to use. The modified version (task suggestions on
    the timeline) works much better — it lets you review all suggestions at once and
    pick the ones you need.

As you see, there can be quite a difference between the initial prototype of an
app and the final product! Before committing to a particular approach, consider
doing some user tests on your prototypes to validate whether your solution is
actually solving a user problem or not.

To recap:

  • Your app’s design might change significantly through several iterations. Embrace
  • Be willing to kill your darlings — some approaches might simply not work.
  • A good idea itself isn’t enough. Presentation and execution make a big
  • Test early, test often.
  • Consider building a solid technical base before polishing the interface. Having
    this base in place let us implement and iterate on Eduardo‘s designs quickly.
  • Your first prototype will look shitty. Keep going!