Меня зовут Алексей Куклин, и я в IT с 1999 года. Большую часть этого времени занимаюсь UX, Как говорится "до того как это стало мейнстримом". Я прошёл путь от промо-сайтов в рекламе и B2C на заре интернета до сложных внутренних систем в B2B: ERP, CRM, заказной разработки программного обеспечения и прикладных приложений.
За это время я проводил исследования, интервьюировал пользователей, клиентов и стейкхолдеров, разбирал бизнес-процессы с системными и бизнес-аналитиками. Наблюдал как люди на самом деле работают с системами. Спроектировать систему так, чтобы она была не объектом изучения, а инструментом-помощником, для решения своих задач. Но были и такие задачи, самые интересные, когда нужно было найти нестандартные решения.
Почти везде задача была одна — повысить эффективность.
Я верю, что лучший интерфейс тот, о котором не думают. Он не требует усилий, не перетягивает внимание и не навязывает себя. Он просто работает. Но не интерфейсом единым ограничивается UX. Это понятие очень широкое, включающее в себя и бизнес-процессы, и архитектуру продукта. UX надо проектировать как систему. Интерфейс - это просто видимое отображение. В какой-то момент я занимался преподаванием UX, и сейчас решил делиться накопленным опытом и выводами, и помогать бизнесу решать проблемы.
Название канала и циклов статей выросло из двух составляющих.
Светлая сторона — это интерфейсы: всё, что можно увидеть, потрогать и нажать. Тёмная сторона — проектирование, архитектура, внутренние связи и логика. То, что редко видно в интерфейсе, но именно это определяет, как система живёт и работает. Схемы, сущности, списки и структуры, вырастающие из бизнес-процессов и формирующие основу любого продукта.
· 15.01
Мне даже интересно, как архитектура системы и интеграций ложится в UX для потребителя)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 15.01
Я на эту тему хотел отдельно писать. Просто надо определиться с понятием Архитектуры. Для программистов, это своё понятие. В моём случае это выстраивание интерфейса для работы с данными. Допустим, мы имеем онтологическую модель хранения данных. У неё есть свой интерфейс, удобный для программистов, но совершенно неудобный для конечных пользователей. Соответственно делается надстройка, которая удобна для работы пользователю, и отвечает бизнес-процессами, и к этому уже подключаются данные и их обработка. Это если очень обще.
Другой пример, неправильно спроектированная ERP. При изменении её структуры, меняется программная часть. Потому что изначально неправильно была выстроена архитектура продукта. Не было системного и подхода
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 15.01
Еще остались недописанными 2 проекта, вот там как раз и сталкивался. В одном ERP, а в другом выстроить внутреннюю систему так, чтобы могли работать отраслевые эксперты и программисты. Они вообще не находили общий язык. И я решил эту проблему с точки зрения набора интерфейсов, который был удобен и тем и другим. Плюс автоматизировал создание экранов клиента на основе бизнес-процессов. В определённой степени применялись принципы BPMN, плюс некоторые доработки. Поэтому в итоге можно было быстро автоматически собирать экраны и проверять гипотезы. Ну и редактировать.
Потом уже я додумал как из этого можно продукт для разработки сделать.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён