Organise by when, not by what.

Design · 5 min read

I was building a task management flow for an app. The original structure was by category. You had your supplies section, your admin section, your communication section, your logistics section. Neat and tidy. Made perfect sense on paper. And it was completely wrong for how users actually think.

The client pointed it out. They said, "Nobody thinks about this by category. They think about it by when things need to happen." Twelve weeks out, you do this. Six weeks out, you do that. A week before, you're buying the fresh stuff that expires. On the day, you're running through a checklist. The information is the same. The order is completely different.

We restructured the entire flow around time. And it changed the app. Not just the look of it. The way it felt to use.

Categories make sense to you, not to your user

Here's the trap. When you're building an app, you're thinking about the system. You're thinking about data structures, content groupings, how things fit together architecturally. Categories feel logical because they are logical. Supplies go in supplies. Admin goes in admin. Everything has a place.

But users aren't navigating your data model. They're navigating their day. They open the app and think, "What do I need to do right now?" If the answer requires them to check three different categories to piece together their current priorities, you've made them do unnecessary work. The app knows the date. It knows the deadlines. It should be telling the user what matters today. Not making them figure it out.

This is what information architecture is really about. Not how you organise data on the back end. How the user experiences it on the front end. And the best information architecture follows the user's mental model, not yours.

Time creates urgency and focus

When you organise by time, you get something that categories can't give you. Urgency. A user sees "two weeks out" and immediately knows the clock is ticking. They see what's due, what's overdue, and what's coming next. That structure does half the motivation work for you. It tells people not just what to do, but when to care about it.

Research on Miller's Law tells us that people can hold about seven items in working memory. If your category view shows them forty tasks across eight categories, they're overwhelmed. If your time view shows them the six things that matter this week, they can actually process it. The information is the same. The cognitive load is radically different.

The client in this case also wanted progress tracking tied to time. Not just "is this done or not done," but "have you started this, are you part way through, or is it finished?" That added a sense of momentum. You could feel yourself moving forward. And that's what keeps people coming back to an app. Not features. The feeling that you're making progress.

You can still have both

This isn't an either or situation. The data behind the scenes is still categorised. Budgets still group by type. Tasks still belong to departments or areas. But the default view, the thing the user sees when they open the app, should be time. What's happening now. What's next. What's done.

You can give them a toggle to switch to a category view if they want it. Some users will. Especially when they're doing something specific like reviewing all their budget items or checking all their vendor contacts. But the default is time. Because that's how people actually plan. Not by department. By deadline.

If your app involves tasks, schedules, projects, or any kind of sequential work, ask yourself this: am I showing the user what they need to see right now? Or am I showing them everything, sorted the way it makes sense to me? If it's the second one, try flipping it. Put time first. See what happens. I've done it once, and the client agreed it was one of the most important changes we made to the whole product.

Sources
Miller's Law (Laws of UX) - The average person can keep roughly seven items in working memory.
Information Architecture: Study Guide (Nielsen Norman Group) - IA should reflect user mental models, not organisational structure.

Related blog posts:

The default matters more than the option →

The difference between a feature and a solution →

Who assumes the complexity? →