Меня зовут Дмитрий Подлужный, и на протяжении многих лет я занимаюсь проектированием интерфейсов для ведущих российских и международных компаний. Эта статья не только рассказ о конкретном кейсе, но и возможность поделиться накопленным опытом с теми, кто только начинает свой путь в мире UX дизайна. Хотя для меня многие аспекты моей работы кажутся очевидными, я надеюсь, что мой опыт окажется полезным для начинающих специалистов, желающих узнать больше о тонкостях профессии.

Эта статья посвящена интерфейсному решению, за счет которого компания получила небольшую прибавку в доходах по страховым продуктам. С одной стороны, здесь нет впечатляющих цифр, с другой стороны, это пример того, как работа дизайнера может влиять на доходы работая с пользовательскими сценариями.

На протяжении пятнадцати лет мне приходится оценивать работу по проектированию интерфейсов. Вначале это были оценки в формате «метания дротиков» — случайные показатели, значение которых должно было быть достаточным для выполнения работы. Но если бы кто‑то меня тогда спросил, «почему столько», я бы развел руками и смог бы только сказать » мне кажется, что этого должно хватить». Со временем стало понятно, что такая неопределенность не очень хорошо согласуется с потребностями бизнеса и нужно двигаться к большей конкретике. При этом, в начале проекта мы все еще знаем о нем слишком мало, и высоки риски неправильно оценивать предстоящую работу, но все‑таки у нас есть возможность балансировать между стремлением к точным цифрам и неопределенностью, чтобы сделать оценки реалистичными — как с точки зрения объема работ, так и сроков их выполнения. Свой подход к оценке работ по проектированию я изложил в этой статье.

Можно по-разному подходить к процессу разработки сервисов и приложений. Идеальной методологии не существует, многое зависит от особенностей команды и самого проекта. Тем не менее, некоторые практики показывают себя хорошо, и в ходе различных проектов могут распространяться на все работы, обеспечивая более предсказуемый результат. Это не означает, что для конкретного проекта и команды не будет существовать более эффективного пути организации работы, но согласитесь — лучше иметь постоянно работающий хороший инструмент, чем под каждый проект пытаться найти самый лучший.

Одним из таких инструментов, которые хорошо себя зарекомендовали в моей работе по проектированию интерфейсов, стало «Задание на проектирование».

GOMS это семейство методов, позволяющих провести моделирование выполнения той или иной задачи пользователем и на основе такой модели оценить качество интерфейса (точнее говоря оценить время выполнения задачи как основной критерий качества). GOMS — сокращение от английского Goals, Operators, Methods, and Selection Rules — Цели, Операторы, Методы и Правила выбора. Данный способ известен с 1983 году и до сих пор не потерял актуальности.

Когда кто-то сегодня говорит о UX, довольно часто он имеет в виду не проектирование пользовательского опыта, а визуальный дизайн. И это объяснимо. Сам по себе интерфейс (UI) уже представляет собой некий конечный продукт, и он прост для понимания. 

Но проекты давно перестали быть настолько простыми, что их может делать один человек. Иногда встречаются гении, способные делать всё на хорошем уровне, но это почти такая же редкость, как, например, единороги. 

Нам полезно вспомнить, что помогает команде сделать проект вовремя и на должном уровне. Мы попробуем описать ту работу, которая чаще всего скрыта от глаз внешнего наблюдателя, но которая обеспечивает достижение высокого качества проекта. И которая у нас проходит в рамках этапа проектирования.