# Разработка, ориентированная на пользователя

- Published: 2025-06-26
- Language: ru
- Canonical: https://drimchansky.dev/ru/notes/user-focused-engineering/

Долго жил с мыслью о том, что всем очевидно, для чего инженеры проектируют системы и пишут код: чтобы разработать продукт, решить проблемы пользователя, а вместе с этим и помочь бизнесу заработать денег, ведь так?

Но чем больше общаешься с людьми из индустрии и смотришь на реализацию некоторых проектов, понимаешь, что мысли о чистом и правильном коде зачастую вытесняют всю эмпатию к пользователю. Да, продуманная архитектура и поддерживаемый код – это очень важно, но надо находить находить баланс с опытом пользователя, иначе зачем это всё?

Несколько примеров из статьи Addy Osmani [User-centric engineering](https://addyo.substack.com/p/user-centric-engineering) того, как инженер может больше думать о пользователе:

- **Оптимизировать производительность, воспринимаемую пользователем, а не сырые цифры.** Как раз недавно столкнулся с тем, что оптимизация Web Vitals ухудшала воспринимаемую производительность. Со старой версией Lighthouse такое было повсеместно, но сейчас гораздо лучше.

- **Проектировать системы так, чтобы при отказе части их функционала переставала работать не вся система, а только затронутая её часть.** Самый наглядный пример – использование React Error Boundary для изолированных частей приложения.

- **Приоритизировать технический долг исходя из влияния на пользовательский опыт.**

> "You’ve got to start with the customer experience and work backwards to the technology - not the other way around" — Steve Jobs

Еще несколько случайных мыслей о тезисах статьи:

- **Важно проводить интервью с пользователями.** Тут все не так очевидно, как кажется на первый взгляд. На эту тему можно почитать книжку [The Mom Test](https://www.goodreads.com/book/show/52283963-the-mom-test). Может быть когда-то опубликую свою заметку по этой книге, если дойдут руки.

- **Работа над продуктом должна руководствоваться данными.** Мне нравится использование термина _data-informed_, вместо популярного _data-driven_. Такое отличие принципиально: _data-informed_ предпологает, что решения принимаются с учётом данных, но при этом с учётом остального контекста. _data-driven_ же, в свою очередь, звучит как слепое следование метрикам, которые сами по себе могут быть сломанными, неправильно интерпретируемы или вообще бессмысленны.