Why dashboard freedom is not always good UX
Instead of a fully free-form dashboard, we chose selectable cards inside a fixed hierarchy. A productivity tool should reduce unnecessary decisions, not create a new layer of configuration work.
Some product ideas sound good almost by definition. One of them is: let users customize everything however they want.
It sounds reasonable and user-friendly. Let people move cards, resize them, create their own dashboard, add or remove widgets, change column counts and build a personal system. Everyone works differently, right?
I was close to that position for a long time. While designing Ordovia’s Daily Command Center, I assumed users should have significant dashboard freedom. Then I noticed a basic contradiction: a product built to reduce chaos was starting to give users a tool for designing their own chaos.
const designPrinciple = "freedom within constraints";Freedom within constraints.
What problem is Ordovia actually trying to solve?
I do not think of Ordovia as another to-do list. The core goal is to make it clearer what a scattered worker should focus on throughout the day.
- tasks
- habits
- notes
- projects
- calendar
- daily focus
- personal knowledge
Putting all of those domains in one app does not solve the problem by itself. You can create chaos inside a single application too. The real problem is not storing information. It is showing the right information at the right time.
The value of a productivity system is not only how much information it can hold, but how little it can show at the right moment.
The first attractive idea: a fully customizable dashboard
In theory a free-form dashboard is compelling. Users can move cards, resize them and persist a personal layout.
interface DashboardCard { id: string; x: number; y: number; width: number; height: number;}
move(card);resize(card);hide(card);show(card);saveLayout();It is technically feasible and it looks impressive in a demo. But product design has a dangerous question: does the fact that we can build it mean we should?
Customization is not free
Every option gives the user freedom, but it also gives them a decision. Where should this card go? How large should it be? Do I need it? Should it be visible today? Each decision is small, but together they create cognitive load.
userFreedom = capability - decisionCost;Unlimited capability does not automatically create more real freedom because decision cost also grows. For a product that promises to reduce mental load, that cost belongs at the center of the design conversation.
Managing the dashboard can become a new job
Flexible tools are powerful because they adapt to many workflows. The same flexibility can become the problem for some users. At some point the user stops managing work and starts managing the system used to manage work.
What should I do today? ↓How should I arrange my dashboard? ↓Maybe I need a new template. ↓Let me tweak this view again.An hour later the productivity system may look better while the actual work remains untouched. I do not want Ordovia to reward that behavior.
Especially for users who struggle with attention
One important Ordovia audience is people who struggle to maintain focus, choose priorities or switch between responsibilities. For that user, the dashboard should not generate options. It should reduce them intelligently.
If a screen shows seventeen cards with equal visual importance, the design has not prioritized anything.
if (everything.priority === "high") { nothing.priority = "high";}The Daily Command Center needs a hierarchy. Asking users to rebuild that hierarchy every morning simply hands the product’s design problem back to the user.
Fixed does not have to mean rigid
The opposite extreme is wrong too. A completely identical dashboard for everyone forces users to adapt to the system. One person may never use habits. Another may rely heavily on calendar. Someone else may not want notes in the daily view.
The answer is neither fully fixed nor fully free. There is a third model: the system owns hierarchy, the user owns visibility.
Selectable, but not movable
The Ordovia model is roughly this:
interface CommandCenterCard { id: string; approved: true; visible: boolean; position: "system-defined"; movable: false; resizable: false;}Users choose which approved cards should be visible.
setVisible("habits", false);setVisible("calendar", true);setVisible("notes", true);They do not redesign the information architecture. They cannot freely reposition or resize cards or create arbitrary layouts. The user decides what to see; the system decides where and in which hierarchy it appears.
Think filter, not dashboard builder
The mental model that helped me is filter rather than dashboard builder. A dashboard builder says: I am designing my system. A filter says: show me what is useful right now. The second is much lighter.
const visibleCards = { focus: true, tasks: true, habits: true, calendar: true, notes: false, library: false,};Users do not need to manage grid coordinates, card dimensions or breakpoint behavior. Personalization becomes a natural filtering action instead of a layout-management project.
Why three columns on desktop?
We chose a three-column grid for web and desktop not simply to fill wide screens, but because it creates a useful information hierarchy: orientation and focus, today’s execution, and supporting context.
const desktopHierarchy = { left: "orientation", center: "execution", right: "context",};It does not need to be a rigid rule at every pixel. It establishes the rhythm of the screen so the Command Center feels like a flow rather than a pile of cards.
Why we dropped the timeline spine
We also explored a vertical guide or timeline spine for the Daily Command Center. It was visually strong but it pushed the product model too far toward time. A timeline says the day is made of hours. Not every task is time-based, every habit is not a calendar event and every note does not belong on a timeline.
A grid is more neutral. It can keep different information types in one hierarchy without forcing them into the same temporal metaphor.
Why shrinking the desktop grid is not a mobile strategy
A common responsive-design mistake is desktop design, made narrower, called mobile. Turning three columns into one column is not enough. On mobile the core constraint is not only space. It is attention.
Desktop can expose more context simultaneously. Mobile ordering should be an explicit product decision, not the accidental wrap order of a CSS grid.
const mobilePriority = [ "todayFocus", "criticalTasks", "habits", "schedule", "supportingContext",];Mobile is not a compressed desktop. It is the same system adapted to a smaller attention budget.
Why constraints can create trust
A well-designed product can make the user feel: I do not need to figure out how this should work. You do not want to configure sensor logic before using a camera app or choose a rendering algorithm before using navigation. A productivity system should not require every user to become an information architect either.
bad constraint → frustrationgood constraint → reliefGood constraints remove work from the user. Bad constraints force the product’s assumptions onto them. The design problem is to draw that line well.
Users are still different
The second half of freedom within constraints matters. One user may need Focus, Tasks and Calendar. Another may want Focus, Habits, Tasks and Notes. Both dashboards can differ without becoming different products.
The user personalizes the system without redesigning it. The dashboard changes; the information architecture stays coherent.
Technical upside: a smaller support and test surface
Free-form customization also creates engineering and operational complexity. A bug such as “my calendar card is missing” may require understanding the layout, column, card size, custom configuration and breakpoint state.
A constrained model has a much smaller state surface.
type CardState = "visible" | "hidden";Fewer edge cases, fewer test combinations, less layout corruption, simpler migrations and more predictable mobile behavior all feed back into product quality.
The power-user objection
The obvious objection is: I am a power user, why can’t I arrange everything however I want? It is a fair question. But a product does not have to maximize flexibility for every possible user. Products can have opinions.
Ordovia’s Daily Command Center should be an area you use, not an area you continuously design.
Power-user flexibility can live in filters, tags, project structures, capture methods and automations. Keeping the core daily flow stable protects the character of the system.
The larger principle: more options do not always mean a better product
Modern software often assumes more options equal a better product. I believe that less and less. Sometimes a better product simply means fewer unnecessary decisions.
more options ≠ better productfewer unnecessary decisions = better flowA productivity product should not measure success by how deeply users customize the dashboard. The more useful question is whether users can do the work they intended to do with less friction.
The question I use to evaluate customization
Does this option help the user do the real work, or does it help the user manage the product?
Hide the Habits card may support real work. Choose the border radius of the Habits card probably supports product management. The line is not always that obvious, but the question is a useful filter.
Constraints are not the enemy of creativity
The same principle applies to product development. “We can build anything” sounds powerful but can be a terrible starting point. A good constraint states which problem the product solves, how it solves it and which dozens of possibilities it deliberately rejects.
The Command Center decision is a small example. A free-form dashboard is technically possible. Choosing not to build it is the product decision.
Conclusion
I am not against user freedom. I simply do not think freedom and transferring design responsibility to the user are the same thing. When a product says “build any system you want,” it can sometimes mean “we decided not to design the right system.”
Ordovia takes a different approach. The system defines the core hierarchy. Users remove what they do not need. They do not have to redesign their productivity system every morning.
const ordovia = { structure: "fixed", visibility: "personal", chaos: "optional",};The goal of a good Daily Command Center is not to give users more controls. It is to reduce the number of things they have to control.