This case is fictional. North, a small planning-software company, hears that its task alerts are numerous but not actionable. The challenge is not to add more notifications; it is to help people recognise a priority action without creating overload.

The team knows that alerts repeat and support receives questions about priorities, but not whether the cause is volume, language, timing, or configuration. It asks: “How might we help project coordinators recognise a priority task at the right time without hiding important information or increasing noise?”

Support, design, and development generate alternatives: group alerts, explain priority, adjust frequency, or show upcoming blockers. Their criteria are clarity, user control, feasibility, and learning. They prioritise a mock-up that states why an alert matters and offers one action.

Using fictional data, authorised participants explain what they would do after each alert. The priority reason is clear, but some messages contain too many actions. The team revises them so each has one primary action and access to further context.

What would happen if North reduced alerts without investigating? Which criterion protects user control? Which alternative prototype could answer the same uncertainty?

Reducing alerts could hide critical information. Control requires understanding and adjusting settings. A simulated priority view could also be compared with the current alerts.

North shows that creativity does not require spectacular technology: it requires reframing, diverse perspectives, exploration, and a hypothesis test before scaling. The next case keeps this process in a more sensitive professional setting.