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

Доброго пожаловать в продакт менеджемент!
Здесь можно хорошо закопаться, почитать и понять куда гуглить:
https://www.productmap.pro/

Привет,
нужно тёмный задний слой сделать маской.
upd: clipping mask по англ.

Привет,
обычно этот стиль называют FUI: Future или Futuristic User Interface.

Подборку веду даже на бехансе и пополняю её:
https://www.behance.net/collection/25329517/Future...

Привет!

1) На самом деле платформа вторична, важны инструменты, которыми дизайнер умеет работать. Сегодня мобила, завтра Voice, послезавтра VR. Но инструменты работы-то те же: jtbd, IA, userflow и прочие варианты извлечения требований и понимания продукта. Это важнее.

2) Собеседую дизайнеров и мало обращаю внимание на конечные цвета, формы и пр. Важнее подходы и инструменты выше. Что толку в формах, если человек не знает что делать на co-creation сессии с клиентом, не имеет никакого опыта в качественных исследованиях? Важнее как он исследует продукт, систематизирует, приоритизирует и работает с информацией в целом. А экранчики вторичны. Процесс здесь первичней.

Поэтому я бы посоветовал сменить вектор чуть в исследовательскую сферу.
И ни в коем случае не игнорировать такой пласт работ как софт-скиллы.
Половина работы у проектировщиков сейчас про них.

Привет, немного знаю про таблицы.
Опускаем вопрос точно ли таблица нужна и перейдём сразу к данным.

Важно для начала понять, какой флоу у человека при работе с таблицей: это поиск, модерация, редактирование или менеджемент объектов? От главной задачи зависит дизайн таблицы, например,
- Если задача поиск массива объектов, то акцент на фильтрах, а не таблица.
- Если это редактирование одного объекта, то задача в поиске и быстром переходе к изменению.

В целом я бы посоветовал пойти так:
1. Понять задачу, для которой таблица нужна;
2. Определить самый минимум атрибутов для объекта, которые стоит вынести в таблицу (прекрасно помогает сессия с пользователями);
3. Оптимизировать их, проходясь по каждому: почему дата важна, зачем нужно время и тд, визуально трансформировать и делать индикаторы где уместно.

Под оптимизацией я понимаю такие вещи как аналитика ещё. Пример: было у нас поле симптомов и было это поле изначально textarea, куда забивали всё подряд. Просмотрев большой массив этих значений мы выделили список, превратив поле из 300 символов в 40, что сказалось на ширине исходной таблицы.

Ещё не забыть, про возможность кастомизации: вкл/выкл столбцов, смены порядка столбцов и сохранении этих настроек. Валидно при наличии многих ролей в сервисе.

Сдвигать вниз надо не при помощи Move, а в событии Show/Hide
Если я правильно понял, надо при клики на 1 элемент показывать и скрывать контент
Поэтому:
- Видимость лучше Toggle
- Затем двигаем всё опцией Push/Pull Widgets
- Указываем, что двигать всё, что ниже опцией Below

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

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

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

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

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

А можно скрин добавить со слоями?
Предположу что да, скопировать и инвертнуть маску (ctrl+I) и отдельно регулировать фон.

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

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

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

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

Скопирую свой ответ отсюда:

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

Насколько я понял, речь про закрытое производство и операторов.
Вывод первый: это профессиональная тула и речи про всякие воронки, конверсии не стоит вести.

Есть возможность найти исходные цели, с которыми проектировалось приложение?
Должны же были удостовериться, что сделали верно. По идеи, оттуда метрики и стоит взять.

Если этого совсем нет, звучит как дискавери фаза - надо заново понять несколько вещей:
1. Кто сказал что интерфейс неудобен? Кто сказал, что есть проблема? Почему её надо решать?
2. Затем - для кого решать? Хорошо, если этот оператор один, но обычно есть супервайзер, а над ним ещё и менеджер, который распределяет нагрузку. Это уже создание и работа с персонами.
3. Экраны - они часть процесса, нужно получить весь процесс. Мы делали целую AS-IS Workflow диаграмму, где искали узкие места и непонятные белые пятна. А это недели работы.
4. Условия работы - операторы могут работать в костюмах биологической защиты с баллонами кислорода и масками, а могут быть на заводе в пыли и температуре +40°С.

Блин, вопрос не средний на самом деле и ответ на него тянет вполне себе на статью\доклад на конференцию.
Дальше уже на аудит похоже будет - без доп контекста не взлететь.

А исходя из обычных метрик, всегда можно найти вторую сторону монеты:
Одно время лишь порождает кучу вопросов: критично ли оно? Завязано ли на количество ошибок? Лучше дольше, но без ошибок, чем быстрее и с бОльшей когнитивной нагрузкой? Насколько сложен процесс и сколько ему учат оператору? Какой изначально путь выбран в системе? Например, для оператора атомной станции время критично только при авариях, в остальном это мониторинг систем.

Я считаю без мат части и деталей нормально посоветовать что-то бОльшее сложно будет.

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

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