Чтобы подружить пользователя через прикладное программное обеспечение, нужно сначала его запрототипировать и запустить. Тогда, да и во многом сейчас, блокчейн вызывает ассоциации с криптовалютой, биржами, энтузиастами, майнинг фермами, ICO и сомнительными людьми с сомнительными целями. В этой истории блокчейн рассматривается как технология хранения данных. Технология не новая, но вошедшая в жизнь недавно. За короткий период, достойных инструментов для работы с ней не появилось. Аудитория, погружённая в предметную область, страдает или наслаждается профессиональной деформацией.
Ну а если коротко, то это о том как подступиться к непонятной задаче и перейти от мозгового штиля к мозговому штурму.
Как дизайнер, я должен исходить из вводных данных и контекста, но практическое применение обсуждалось лишь в общих чертах, а возможности технологии просили показать как можно скорее. Про потенциальных пользователей было известно следующее: они дееспособного возраста, используют современные устройства ввода, имеют доступ в сеть, не понимают что такое хеш-функция и принципы работы технологии.
При расплывчатых требованиях к навыкам и роду занятий пользователей, важно очертить достаточно узкий круг ограничений. Звучит на первый взгляд сложно и непонятно. Давайте подумаем: дееспособные люди вынуждены сталкиваться с делопроизводством, так устроено государство. Если они работают с современными устройствами ввода, то всё становится чуть проще.
Если делаешь программное обеспечение без доступа к разработке устройства ввода, то не формируй новые привычки за счёт заказчика. Используй распространённые паттерны и будешь в относительной безопасности.
Чтобы использовать распространенные паттерны правильно, нужно знать об устройствах ввода, иметь опыт и хорошую насмотренность. По этой причине многие разработчики не в состоянии собрать понятный интерфейс, молодые дизайнеры занимаются решением давно решённых задач. Три с половиной паттерна в голове ответственного всегда ведут к исследованиям, результаты которых трактуются.
Хорошая информационная архитектура — залог здоровья продукта. По этой причине не поручайте разработчикам, аналитикам, неопытным дизайнерам и коллективному разуму делать прототипы продукта, они заложат вам архитектуру, благодаря которой вы долгое время будете работать по следующей схеме...
Такой простой подход действительно работает очень эффективно на коротких дистанциях.
Мы сформулировали задачи, а значит половина дела уже сделана:
- Сейчас решение заставляет пользователя учиться, а решение должно быть похоже на то, с чем они имеют дело каждый день. Возможности проводить эксперименты и заниматься изобретениями нет. Образование новых нейронных связей в мозгу пользователя происходить не должно, иначе вероятность провала сильно возрастает.
- Всё что потребует выполнения пункта один нужно размазать ровным слоем под логикой фронта и доработками микросервисов, это дешевле, чем подниматься на крышу и уговаривать парней швырнуть тело в идеальную позицию. (см. картинку выше)
Конкурентный анализ на тот момент показал, что наиболее популярные решения для работы с данными, хранящимися в блокчейне, были сделаны под копирку. Можно было выбрать одно из них и без каких-либо тестирований понять, что для рядового пользователя это абсолютно бесполезная штука. Наиболее наглядным будет пример с блокчейн-эксплорером (это такой просмотрщик содержимого). Сделал снимок экрана с продуктом подобного класса.
Он позволяет пользователю оперировать категориями «адрес», «блок», «идентификатор транзакции». Мало того, в некоторых аналогах есть сленговые локализации где можно встретить «добыто», «хэшрейт» и «мемпул».
Очевидно, что это решение, сделанное (на тот момент) энтузиастами для энтузиастов. Это не продукт. Нам же нужен продукт для хранения информации, пользователь должен работать с данными и их атрибутами. Например, автор или отправитель, дата создания записи, размер и прочее.
Для этого необходимо перечислить все типы данных, которые можно хранить. Понять как и какими из них пользователь будет оперировать. У нас есть ограниченный набор транзакций, отправляемых в пул, т.е. в обработку и запись. Каждая из них имеет описание.
У нас была пара фронт-энд разработчиков, пара бэкенд-разработчиков, два аналитика, одна кофемашина и целое море идей что мы можем сделать.
Поскольку ядром был Waves, разработчики которого сидели недалеко, мы всегда могли обратиться к ним с запросом на доработку или спросить как работает тот или иной кусок кода. Ну а начали мы с описания типов транзакций и обработки ошибок. Последнее всегда даётся тяжело, если этой задачей долгое время пренебрегать.
Начали с описания типов транзакций:
- Операции с токенами.
- Транзакции записи данных.
- Создание (адресов) пользователей.
- Присвоение пользователям псевдонимов.
- Управление разрешениями как задел для ролевой модели.
- Операции с контрактами.
Нашей целью стало выстроить систему микросервисов и баз данных, позволяющих быстро отдавать данные. Пользователь, при поиске и фильтрации списка транзакций, должен оперировать значениями в полях транзакций. Моей задачей было придумать простой и лёгкий интерфейс.
Чтобы добиться минималистичности, пришлось потрудиться. Для экономии экранного пространства панель действий должна реагировать на контекст решаемой задачи, давать пользователю то, что ему нужно с учётом имеющихся на тот момент технических ограничений в реализации.
Компромиссом стало упрощение компонентной базы в пользу проработки микроэргономики, анимации, обработки ошибок, написания понятных текстов, общего очеловечивания в общем всего того, что воспринимаешь как данность не задумываясь. Иногда анимация лучше, чем набор кирпичей текста.
На этапе прототипирования определяемся с типовыми экранами и перестраховываясь на будущее, закладываем сетку побогаче.
Планировалось выпустить демонстрационный продукт с двумя типами смарт-контрактов. Контейнеризированные смарт-контракты и Смарт-контракты RIDE. Это принципиально разные решения, но функционально работающие в одинаковом направлении: запуск скрипта при выполнении заложенных условий.
Опуская технические детали, да простят меня разработчики, можно сказать что приходилось делать чуть более сложные запросы и выводить их результаты в порядке, который мы определили как гипотетически понятный для пользователя.
Делать свою интегрированную среду для разработки RIDE смарт-контрактов было решено ресурсами отдельной команды. На тот момент у меня было желание заняться и этой задачей самостоятельно, но сейчас, спустя время, понимаю насколько это было правильным решением.
К моменту релиза получилось, что подобных продуктов на рынке нет и это даёт конкурентное преимущество: неподготовленный пользователь может искать данные, фильтровать, выгружать, делать на основе них визуализацию в стороннем программном обеспечении без дополнительной подготовки. Шалость удалась!
Позднее, на основе этой разработки мы сделали прототип выпуска цифровых векселей. Подробнее об этом можно почитать в заметке Блокчейн-вексель.
Написано в самоизоляции 25 апреля, 2020
Дополнено 22 февраля, 2023
Пётр Лутов
Дизайн в разработке программного обеспечения