Никита Гарейшин

Не очень прозрачен контекст задания,
но предложу ситуации, для которых совет Михаил Проскурин не очень подойдёт.

У SuperToster уже есть экраны в фигме, это даёт нам предположить, что общий флоу и сценарии основные готовы.
Вероятно это делал проектировщик, который, вероятно, подумал несколько раз.

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

А вот если реально требуется «раскрасить» макеты, создать и описать полноценный кит для системы, не сильно вдаваясь в сценарии - это хорошая работа для технического дизайнера. И опять же нюанс - всю его работу контролировать и проверять должен тот, кто делал исходные макеты.
И стоимость в $1500-2000 за 2-3 недели работы вполне себе неплохая.

По вопросу ТС:
я бы посоветовал искать через знакомых, либо через hh, выделяя интересные резюме.

Привет,
Тут напрашивается дискавери фаза, если есть только список фич.

Для полноценного сервиса, хорошо бы понимать:
- Общий подход к проектированию - для кого создаём? Для покупателя (Customer Centered Design), оператора (System CD), человека с улицы (Human CD), пользователя в целом (User CD) и пр;
- Определить количество ролей, описать их - проблемы, ежедневные задачи, боли и пр (Personas);
- Определиться с методологией производства (Waterfall, Agile и пр);
- Если это существующий процесс, то описать As-Is Workflow для понимая, если нет - описать будущий процесс;
Из этого всего можно прикинуть концепт (Proof of Concept) и смотреть что получается.
Когда будет этот минимум, можно садится и думать над MVP - какой сервис будет, из чего состоять, что делать в первую очередь, а что нет.

Более того, я бы в картах не путал фичи и объекты.
Отобразить товар и управление им - это разные схемки.
Ещё есть экраны, где есть некоторые экраны и некоторые фичи)

Для проработки каждого экрана надо понимать:
- Кто им пользуется;
- Какую проблему мы решаем в данный момент.
Вывалить всё и вся тоже можно - пусть человек сам разбирается, но спасибо вам не скажут)

Tour, wizard, steps, etc - это всё инструменты, частные варианты.

Этот процесс называется Onboarding.
Поэтому можно гуглить что-то из серии "web site onboarding best practice"

Так ответ в вопросе:

Убрать кучу лишнего функционала, которые не нужен обычным операторам

Идёте к операторам, смотрите как они работают, выписываете ненужный функционал, переделывайте функционал, тестируете, снова переделывайте (повторить нужное количество раз) — ура, готово!

Или только визуальная часть интересна? Стоит учесть, что с удобством тут ничего общего нет, только рюшечки.
В этом случае любые популярные на сегодня работы на Dribbble и Behance например.

Привет!
Если я правильно понял, то для такого поведения меню надо добавить проверку на видимость каждой соответствующей динамической панели.
Т.е. на каждый пункт меню на событие OnMouseEnter создаем проверку Visibility of widget для динамической панели как, например, false и вешаем событие Show MyMenuItem, которая по умолчанию скрыта. Тогда второй кейс для того же OnMouseEnter при условии ElseIfTrue будет Hide MyMenuItem.

И пара нюансов:
- для чего вам пустое состояние? Крайние состояние, такие как пустые и перегрузочные, лучше прорисовывать в конце когда основная архитектура готова и все (=большинство) требований устаканились. А иногда можно и на графического дизайнера это оставить);
- лучше сразу указывать нормальные названия всем состояниям, переменным и состояниям, в будущем запутаться не долго.

Если что-то я криво описал — укажи, переформулирую)

Есть подозрение, что вы не понимаете для чего и что такое UX в процессах и продукте.

Вы пишите про данные во главе угла, затем про наблюдение (видимо за пользователями) — вещи абсолютно разные.

Дело в том, что есть несколько методик разработки интерфейса, одни из них Data Centered Design, где основываемся на данных, без учета людей вообще, например чисто по статистике измеряем эффективность решения, а есть User Centered Design, где все решения идут от человека, за которым следим и на котором тестируем (не на одном само собой, больше разговоров и взаимодействия проектировщика с людьми). Вы же это почему-то равняете к одному знаменателю, это не верно. Совершенно разные подходы.

Есть ещё например Customer Centered Design, System Centered Design.

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

Юра Ветров хорошо рассказывает о продуктовом дизайнере, вот тут презенташка например:
www.slideshare.net/jvetrau/design-weekend-2014

В первую очередь это стратег, потом уже дизайнер (в простом понимании слова).
Ещё и менеджер ко всему прочему.

Один.
Рассказываю почему — прежде, чем нарисовать что-то в фотошопе, надо выяснить много всего, пройти несколько этапов, а именно:
1. Аналитика — что за фирма, узнать чем живёт, как продаёт, что продаёт и пр.;
2. Прототипирование — хоть на салфетке, но накидать примерную структуру будущего сайта. В идеале интерактивный прототип, если есть сложные формы и под подпись с утверждением;
3. Только сейчас поднимаем тему о цветах и прочей лабуде — показываем примеры, разговариваем много и долго о будущем оформлении, выясняем чем руководствуется человек и как ему помочь в выборе;
4. Рисуем концепт — мы уже не летаем в облаках, а рисуем обговоренный макет (трачу на это не более 7-8 часов);
5. Вносим поправки и дорабатываем детали главной страницы (20+ часов на это закладываю);
6. Рисуем внутренние (20+ часов).

Не надо гадать что понравится, выясните что нужно. Говорите, обсуждайте, зачем эти игры в напёрстки?
Доступно донёс?)