tgoop.com/the_docs_is_the_code/303
Last Update:
Замовники часто приходять із готовим рішенням, замість того щоб описати проблему, яку вони намагаються вирішити. Ось типовий приклад з адмінським UI:
Ситуація
Замовник каже: “Нам потрібен дашборд з таблицею, де буде 15 стовпців, 5 фільтрів і можливість експортувати все у PDF та Excel. Зробіть, будь ласка (тобто бігом).”
У чому проблема?
Замовник вже запропонував рішення: “таблиця з 15 стовпцями та фільтрами”. Однак він не пояснив:
• Чому саме 15 стовпців?
• Які дані найважливіші для користувача?
• Що насправді потрібно досягти з цим дашбордом?
Що потрібно зробити?
Замість беззаперечного виконання, потрібно повернутися до проблеми та зрозуміти вимоги:
Питання до замовника:
Для чого потрібен цей дашборд? — Щоб побачити ключові метрики чи знаходити певні аномалії?
Хто буде користуватися цим дашбордом? — Адміністратори, аналітики чи менеджери?
Які дії ви очікуєте від користувачів після перегляду цих даних? — Прийняти рішення, надіслати звіт чи щось інше?
З’ясувавши проблему, можна запропонувати більш оптимальне рішення:
• Замість таблиці з 15 стовпцями — зведені метрики у вигляді віджетів, щоб ключові дані були одразу видимі.
• Для глибокого аналізу — можливість фільтрації та розширення таблиць за потреби.
• Оптимізувати експорт, додаючи лише потрібні дані.
Результат:
Адмінське UI стане зручнішим, ефективнішим і буде вирішувати реальну проблему, а не “втілювати” готове рішення замовника.
BY documentation is the code
Share with your friend now:
tgoop.com/the_docs_is_the_code/303