Designing one timeline for your whole day.

The client was building this on his own, alongside a full-time job: a product he wanted to exist, not a commissioned brief.

The problem was one he lived with. None of these tools can see each other, so every morning you look at your calendar, then your task list, and reconcile the two yourself.

The brief: collapse that into one surface, on web and mobile, with a shared model across both.

Three designers, split by platform. I owned the web application; Smruthi and Kavya owned mobile.

• I owned: every web screen (dashboard, calendar views, task creation and editing, meeting scheduling and invitations, special events, projects, journal, profile and notifications), plus the interactive prototype

• We owned jointly: the product model, the user flows and the competitor research

• I didn’t own: any mobile screen, or the design system

We looked closely at Google Calendar, Notion and mainstream to-do apps: the three kinds of tool our users were already running in parallel.

Each is good at one part of planning, and blind to the rest.

Tasks, meetings, special events and journal entries all live in a single chronological stream. Anything with a scheduled time appears on the calendar automatically, and projects group tasks without pulling them out of the timeline.

That “never file it twice” rule is what makes the one-app claim real. Three tools in one shell would still be three tools.

The web dashboard groups everything by time, and inside each group the types are mixed together. A task to water the plants, a birthday and a PTA meeting sit in the same list, told apart by a small type icon and a right-aligned time or “All Day”.

A quick-add field sits pinned at the bottom of the dashboard, and a dedicated Create action lives in the sidebar. One control for both would have made the fast case slow or the complex case cramped.

Smruthi and Kavya designed the mobile app; I designed web. Both platforms share the information model, the grouping logic, the card anatomy and the quick-add pattern we defined together, so a task card reads the same on both.

How you reach it doesn’t, because a thumb and a cursor are not the same instrument. My web decisions adapted their mobile patterns to a larger screen and a cursor.

I designed every web screen, across onboarding, planning, projects, journaling and settings.

Onboarding is passwordless: enter a phone number, get a 6-digit code, and you're in. A returning number goes straight to the dashboard. A new number, already verified, adds only a name and an email.

Projects collect tasks, meetings and events while they stay on the main timeline. The journal sits alongside for notes, with tags and attachments, and an entry can link to a task.

Profile and settings hold the defaults the rest of the app relies on: timezone, the default calendar view, reminders and sync.

Atomic Calendar is still in development, so there are no launch metrics yet.

I built an interactive prototype of the web application covering task creation, calendar navigation, meeting scheduling, project creation and journal entries. The client approved the design and the product moved into development, with web and mobile sharing one model.

Next, I’d validate: whether mixing tasks, meetings and events in one list slows people down when scanning their day, how often people use quick add versus the full Create form, and whether the collapsed Overdue section keeps overdue work visible enough.