Post #116

Старт дизайна и дизайнера. №3. Как не закопаться в тушах мамонтов Предыдущее тут Иногда задачи на входе бывают очень сложными по объему, и крайне сложно въехать в них «чисто», осмысленно. Например, сейчас я занимаюсь интеграцией трех информационных системы в одну, причем каждая из них содержит огромное количество разделов, функционала, и имеет своих пользователей, команды разработки и так далее (типичная задачка, когда происходит слияние и поглощение нескольких компаний), плюс к тому отсутствие документации и UX-процессов. Либо вам в наследие досталась работа над системой, которую делали другие годами, но видно, что их квалификация по UX и информационной архитектуре была не очень большой, плюс все артефакты хранились в голове ушедшего сотрудника. Думаю, каждый найдет себе знакомую ситуацию. В таких случаях легко провалиться в миллионах вопросов, неопределенностей и так далее — а ведь при этом ещё и ничерта не понятно, что к чему, зачем это, пользуется ли этим кто-нибудь и т.п. В общем, полная дезориентация, а коммерческие сроки давят. Как тут быть? Универсального алгоритма нет, но дам некую канву, по которой обычно в таких случаях двигаюсь я. Первым делом нужно признать, что хорошего («правильного») результата не получить эффективно — скорее всего, тут нужно мыслить стратегически, не месяцами, а скорее годами работы. Это избавит от кучи псхиологических препятствий. От мышления «правильным» нужно переходить к мышлению «улучшенным» (опять же, мы и сами не знаем пока, что правильно — ибо для этого нужно больше информации, а ее нет). Дальше стоит донести эту мысль до стейкхолдеров/руководства. Для них, особенно если они не имели дела с UX процессами, это может быть неочевидно — “да чего там, давайте перенесем блоки и страницы в одно место, добавим в меню” и т.п., но попробовать стоит. Если предыдущий пункт был выполнен удачно (и особенно если был неудачен), просим доступы к живым данным во всех системах — это поможет понять, что на самом деле применяется пользователями/кастомерами, а что является полудышащим легаси. Это очень важный пункт для развертывания дальнейшей деятельности, поэтому нужно стоять на своем, а если говорят «а как же защита персональных данных», то нужно предлагать и настаивать, чтобы в ваш контракт были включены какие-нибудь соглашения (все эти NDA, GDPR, доступ к персональным данным, санкции за утечки и т.п.), разрешающие вам этим заниматься . Теперь переходим к практике. Создаем пустой проект в Figma, достку в Miro и иже с ними. Что вам нравится. И совершенно тупо начинаем скриншотить всё подряд, выкладывая это в доску в иерархию имеющихся страниц и интерфейсов — для одной или нескольких систем отдельно. Не делаем больше ничего — если вы будете пытаться интерпретировать увиденное, задаваться вопросами что в нем не так, уходить в обсуждения, вы провалитесь и упустите главную цель — получить представление о том, что есть в системе, из чего она состоит. Конечно, мы все равно неизбежно интерпретируем то что видем, но экономя усилия на анализе (он еще предстоит далее), мы и знакомимся с системой, и все равно создаем какое-то общее впечатление о состоянии бедствия. Получив это всё, мы теперь имеем наглядный вид того, что можно разгребать, анализировать, видеть перекрестные связи (а это суперважно, именно поэтому не нужно анализировать до того, как закончили полный сбор и т.п.).