О проекте
Для начала кратко что такое ТРИЗ.
ТРИЗ – это Теория Решения Изобретательских Задач, методология, разработанная советскими учеными, инженерами, конструкторами, которая позволяет решать сложные задачи и проблемы в производстве, технологические проблемы, когда есть одно или несколько противоречий и с “ходу” найти решение не получается.
Часто в результате этого подхода побочным продуктом является то, что оптимизируется производство, сокращается цикл производство товара, улучшается качество продукции, устраняются дефекты, то что потребителям не нравилось, раздражало.
Методология очень непростая. Сотни, если не тысячи вариантов решения каждой задач. Тестировать все способы – нерентабельно, не хватит денег, нервов и времени.
Поэтому была придумана программа Solving Mill, которая позволяет провести “решателя задачи” по самому оптимальному пути и за минимальное количеcтво времени, сил, денег найти решение задачи/проблемы.
Задача
Программа Solving Mill предоставляется по лицензии для заказчиков и на момент проектирования интерфейсов основной заказчик был из Китая, им было тяжело ориентироваться в программе где все сразу было вывалено на пользователя на один единственный экран.
Это удобно для тех кто в “теме”, у кого большой опыт работы с ТРИЗ и самой программой (человек привыкает ко всем, даже к плохому интерфейсу, если у него нет выбора).
А вот если в программе пытался работать человек осваивающий методологию ТРИЗ, то ему было крайне сложно, даже с учетом того что были обучающие статьи, подсказки.
Вот как выглядела первая версия интерфейса (пример разбора задачи Николаем Шпаковским в старой версии)
Ограничения
1) Нельзя менять сильно структуру текущего сервиса
2) Нельзя добавлять много “воздуха”, в идеале – минимально возможные отступы между всеми элементами, так как к такому интерфейсу привыкли пользователи, решающие в них задачи и их раздражает когда на одном экране умещается мало информации. Интерфейс 90х для них идеальный вариант.
Исходные данные
Наше сотрудничество началось с того что заказчик хотел чтобы я провел всю работу начиная от аналитики, исследования, проектирования и дизайна. Но после того как я глубоко погрузился в проект (изучил более 500 страниц про методологию, прочитал книгу), собрал все требования, материалы, ограничения, мы не сошлись в цене и сроках на весь проект.
Заказчик принял решение, что программист сам сделает интерфейс как ему скажет руководитель проекта, а уже после ко мне придут что бы я “причесал” дизайн, сделал более удобным в использовании. На этом мы разошлись и через пару месяцев я увидел то, что было сделано. Ниже скриншоты новой версии, то как сделал программист, листайте вправо.
До-после
Страница с проектами
Делаем чище, проще. Так как проектов на практике может быть десятки, то все на одной странице искать неудобно будет, поэтому добавили сверху вкладки.
Процесс создание проекта.
Забегая вперед скажу что под конец проекта я предложил и заказчик принял идею отказаться от процесса создания проекта через модальные окна, а сразу делать это в решательной части. Чтобы пользователю по мере продвижения проекта открывались новые возможности по редактированию. Ничего лишнего, все показывается только в тот момент, когда нужно пользователю. Ему так проще будет запомнить что создать и отредактировать проект все на одной странице. Как вы видите на скринах ниже, некоторые поля, функционал убирался, некоторый добавлялся.
Решательная часть.
Было принято решение выделить правый блок с вспомогательным функционалом темным цветом, чтобы четко разграничить основную рабочую область от дополнительного функционала.
Верхнее меню и правая колонка должны оставаться при скроллинге чтобы в любой момент “решатель” мог воспользоваться необходимыми функциями системы.
Редактирование из выпадающих списков и модальных окон сделали сразу “на лету”. Меньше окон, меньши кликов, проще быстрее, удобнее, понятнее редактировать.
В решательной части слева все очень мелко и липнет друг другу, я лично против такого, но так захотел Шпаковский, поэтому делаем как хочет клиент. Вообще стоит между блоками сделать гораздо больше свободного пространства иначе при долгой работе, находить информацию станет сложнее, так как визуально блоки сливаются при скроллинге в одно большую “простыню”.
Функционал решения проблемных операций
Тут стояла задача просто сделать чтобы стало более “приятно глазу”, влезало как можно больше и было понятно что это древовидная структура.
Функциональный анализ
Также просто сделали “приятнее глазу” и понятнее.
Менеджер ресурсов
Если вы не знакомы с ТРИЗ, вы не поймете что это. Просто посмотрите как изменился внешний вид 🙂
Вы наверное уже заметили что я стараюсь все данные подставлять не “рыбой” текстом, не оставлять пустыми, а наполнять реальными данными. Это позволяет увидеть мелочи, например когда текст не помещается одной строкой в “идеальный” дизайнерский блок и тд.
Менеджер идей
Упростил, сделал “приятнее глазу”. Сделал интуитивно понятный drag&drop. Весь фокус на уникальный контент.
Комментарии
По-умолчанию комментарии сделаны так что они напрочь сливаются с информацией блока, куча ненужной “служебной” информации которой больше чем самих комментариев, читать что-то в такой “каше” крайне неудобно. Поэтому первое что было сделано – это выделение главного – самих комментариев. И наоборот убрали внимание со служебной информации, отделили комментарии от основного блока чтобы их было легко заменить.
По умолчанию была кнопка “вкл/выкл” все комментарии, но в проекте их может быть десятки, а с учетом того что проект на одной странице и если они все раскроются, то скролить просто замучаешься. Поэтому добавил к каждому блоку отдельную функцию “показать/скрыть комментарии”. Это гораздо практичнее.
Плюс иконки показывающие разные статусы: нет сообщений, все сообщения прочитаны, сколько новых сообщений. Что помогает быстрее ориентироваться и понимать ответили коллеги или нет.
Прочие блоки
Упрощаем и делаем все в корпоративных цветах. Кодируем цветовыми решениями: все что голубое – это “положительные эффекты”, все что красным “отрицательные”. Этот способ применялся по возможности ко всем элементам, где нужно было это показать. Человек работая в такой системе в дальнейшем будет гораздо быстрее ориентироваться и понимать какая перед ним информация. Не нужно тратить время, вчитываться.
Ui-kit
Для такого большого проекта важно чтобы все элементы были едины, так проще будет поддерживать систему, что-то дорабатывать и менять. Поэтому был разработан UI-kit, где показаны все состояния элементов (обычное/при наведении/при клике/выбранное/заблокированное). Это позволяет верстальщику/программисту не думать о том, как в каких состояниях должны работать кнопки, меню, чекбоксы, списки и тд, а просто брать готовые элементы и как конструктор лего собирать страницы. Если страница простая, то это позволяет часто обходиться без дизайнера и собирать необходимый функционал из заготовок. Экономит время и деньги компании.
Мобильная версия
Для большей части решательного процесса было решено также сделать адаптивную версию
