Замовники часто приходять із готовим рішенням, замість того щоб описати проблему, яку вони намагаються вирішити. Ось типовий приклад з адмінським UI:

Ситуація
Замовник каже: “Нам потрібен дашборд з таблицею, де буде 15 стовпців, 5 фільтрів і можливість експортувати все у PDF та Excel. Зробіть, будь ласка (тобто бігом).”

У чому проблема?
Замовник вже запропонував рішення: “таблиця з 15 стовпцями та фільтрами”. Однак він не пояснив:

• Чому саме 15 стовпців?
• Які дані найважливіші для користувача?
• Що насправді потрібно досягти з цим дашбордом?

Що потрібно зробити?
Замість беззаперечного виконання, потрібно повернутися до проблеми та зрозуміти вимоги:

Питання до замовника:

Для чого потрібен цей дашборд? — Щоб побачити ключові метрики чи знаходити певні аномалії?

Хто буде користуватися цим дашбордом? — Адміністратори, аналітики чи менеджери?

Які дії ви очікуєте від користувачів після перегляду цих даних? — Прийняти рішення, надіслати звіт чи щось інше?

З’ясувавши проблему, можна запропонувати більш оптимальне рішення:

• Замість таблиці з 15 стовпцями — зведені метрики у вигляді віджетів, щоб ключові дані були одразу видимі.
• Для глибокого аналізу — можливість фільтрації та розширення таблиць за потреби.
• Оптимізувати експорт, додаючи лише потрібні дані.

Результат:
Адмінське UI стане зручнішим, ефективнішим і буде вирішувати реальну проблему, а не “втілювати” готове рішення замовника.

Veggietales predicting modern memes