https://marakestrel.example/writing Essays on designing calm software: night work, alerts, empty states, design tokens and showing uncertainty. en-gb https://marakestrel.example/writing/designing-for-3am https://marakestrel.example/writing/designing-for-3am Tue, 06 Oct 2026 09:00:00 GMT Most interfaces are designed at 11 in the morning by rested people. Some are used at 3 at night by exhausted ones. Here is what changes. https://marakestrel.example/writing/fewer-alerts https://marakestrel.example/writing/fewer-alerts Tue, 18 Aug 2026 09:00:00 GMT Alert fatigue is a design problem, not a discipline problem. Four questions I ask before any notification ships. https://marakestrel.example/writing/empty-state-first https://marakestrel.example/writing/empty-state-first Tue, 02 Jun 2026 09:00:00 GMT The first screen most people see is an empty one. Designing it first makes the rest of the product clearer. https://marakestrel.example/writing/tokens-are-a-contract https://marakestrel.example/writing/tokens-are-a-contract Tue, 24 Mar 2026 09:00:00 GMT A token named after a colour tells you what it looks like. A token named after a role tells you what it promises. Only one of those survives a redesign. https://marakestrel.example/writing/maps-and-uncertainty https://marakestrel.example/writing/maps-and-uncertainty Tue, 11 Nov 2025 09:00:00 GMT People trust forecasts more when you tell them how sure you are. Showing uncertainty is a design skill, and a public duty.