Design
Everything we have filed under this category.
2 items
A dashboard people actually read
Most dashboards die a quiet death: built with enthusiasm, shown once at the launch meeting, and unopened two weeks later. The problem is rarely the data — it's design that shows everything and says nothing. A successful dashboard isn't a gallery of charts; it's a daily decision tool. In this article we distill the principles we use at Grid to design dashboards people open every morning because they actually answer their questions.Start from the decision, not the dataThe wrong question when building a dashboard: "what data do we have?". The right one: "what decisions does this dashboard's user make every week?". Every element must answer a specific question that leads to action — "do we need to intervene today?", "where are customers leaking?". A chart that changes no decision is noise, however beautiful.Every chart on the dashboard answers a question — if you can't write the question down, delete the chart.Data-ink: every pixel earns its placeEdward Tufte's famous principle: give as much "ink" as possible to the data itself, and as little as possible to decoration. In practice that means removing shaded backgrounds, heavy borders, gradients, drop shadows, dense gridlines, and 3D effects — they all compete with the data for the eye's attention and add no information. A clean dashboard isn't an aesthetic preference; it's reading speed.One accent color is enoughA dashboard using ten colors distinguishes nothing — when everything shouts, nothing is heard. The system that works: quiet grays for the base, one accent color for what matters most — the line that matters now, the segment that needs attention — and red reserved exclusively for genuine warnings. With that discipline, color guides the reader's eye to what deserves it within a second.Hierarchy guides the eyeReaders scan dashboards; they don't read them line by line. Design for that behavior: the critical numbers at the top, large and unmissable; supporting detail beneath; deep exploration at the last level or behind a click. And the one-screen rule: what needs long scrolling won't be seen — if sections multiply, split them into dashboards for different audiences instead of one endless screen.Choose the chart that matches the questionTrend over time — a line. Nothing beats it.Comparison across categories — bars, sorted largest to smallest.One critical number — a big number with its change indicator versus the previous period, not a speedometer gauge.Pie charts — rarely: two or three slices at most, otherwise bars are clearer.And watch for bar-chart axes that don't start at zero — they inflate differences and deceive the reader, and a dashboard's credibility is its most valuable asset.A number without context is not information"Revenue: 48,000" — is that good? Nobody knows without a comparison. Every number on the dashboard needs a reference: the previous period, the target, or the market average. Add the target line to the chart, the change percentage next to the number, and color the deviation — then the number turns from a statistic into a verdict: we're fine, or we need to act.For Arabic audiences: the dashboard reads from the rightBilingual dashboards are a challenge we handle daily: in the Arabic interface the entire layout mirrors (RTL), so the visual hierarchy starts at the top right — while time axes inside charts still run left-to-right as readers expect for numbers. Long numbers and dates need correct locale formatting. Test both versions — a dashboard that reads naturally in Arabic doesn't come for free from a foreign charting library.A pre-launch dashboard checklistDoes every chart answer a clear decision question you can write in one sentence?Have you removed every decoration that carries no information — backgrounds, shadows, 3D?Do you use one accent color, with red only for warnings?Is the most important content at the top, everything visible without long scrolling?Is every number paired with a comparison that gives it meaning — a target or a previous period?The bottom lineA good dashboard isn't the one with the most charts but the one that answers fastest: the decision-maker opens it and knows within seconds whether things are fine and where to look. Start from the questions, be frugal with ink and color, order by hierarchy, and give every number its context — and you'll get that rare thing: a dashboard people open every day by choice.At Grid we design bilingual dashboards and interactive reports for companies and organizations — from data modeling to an interface that actually gets read. If your dashboards get built but never opened, get in touch.
Tokens as a contract between teams
Every digital product replays the same scene: a designer picks a shade in the design tool, a developer writes a close-enough value in code, and six months later the product has eleven different "blues" and nobody knows which one is right. Design tokens are the structural fix for that chaos — and the cheapest way we know to stay consistent as a product and a team grow. In this article we explain how we treat tokens at Grid: as a binding contract between design and engineering, not just a color file.What are design tokens?A token is a named design value: instead of writing #237F8C in twenty places, you define color-brand-primary once and reference it everywhere. The same applies to spacing, font sizes, radii, shadows, and motion durations. The value lives in one place; the name carries the meaning.The real power isn't the naming — it's the consequence: when the brand's primary color changes, it changes in one source and propagates automatically to the web, the app, and the marketing emails, instead of weeks of manual hunting.A token is a contract — and a contract has two partiesThe common mistake is treating tokens as a config file that belongs to developers. Successful tokens are a contract between design and engineering: the designer commits that every visual decision goes through a named token, and the developer commits that not a single raw value enters the codebase.Any visual value without an agreed name is visual technical debt — you'll pay for it at the first redesign.With that contract, the "is this the right gray?" debate happens in exactly one place, and code review turns from comparing hex numbers into reading clear intent.Three layers keep the chaos outFlat token lists collapse at the first dark mode or sub-brand. The structure we rely on has three layers:Core tokens — the raw palette: teal-600, space-4, font-size-16. Never used directly in interfaces.Semantic tokens — functional meaning: color-text-primary, surface-raised, border-focus. They point at the core layer.Component tokens — only where needed: button-bg pointing at a semantic token.With this structure, dark mode is not a new CSS file — it's remapping the semantic layer to different core values. A new sub-brand is a new core palette under the same semantic names.One source of truth — everything else is generatedThe contract breaks the moment it has two copies. We keep tokens in a single source (usually JSON files in the repository, or a tool like Tokens Studio wired to it) and generate every format from it automatically: CSS variables for the web, design-tool values, native platform constants. Tools like Style Dictionary make that generation an ordinary build step.The golden rule: edits happen in the source only. A manual tweak in any generated format is a breach of contract — and it will be erased by the next generation run anyway.Change governance: tokens have versionsChanging a token's value touches every screen in the product, so it deserves versioning discipline: changing only a value is a patch; renaming or removing a token is a breaking change that needs a transition window and a clear migration path. Token changes get a shared review — designer and developer together — because a contract is never amended by one side.A checklist for starting with tokensHave you inventoried the duplicated visual values in your current product (colors first)?Are tokens split into core and semantic layers — with interfaces consuming only the semantic ones?Is there a single source from which every format is generated automatically at build time?Does an automated CI check block new raw values from entering the code?Do token changes go through a joint design–engineering review?The bottom lineDesign tokens aren't a luxury for big design teams; they're the cheapest insurance against the consistency rot that hits every growing product. A clear contract, three layers, one source of truth, and lightweight governance — that's all it takes to keep your product's identity coherent across every platform, every team, and every redesign to come.At Grid we build design systems and token architectures for Arabic and English products alike — including the challenges of RTL and LTR. If your product suffers from accumulated visual chaos, get in touch and we'll help you build the system that stops it at the root.