Проект «Лифт» помогает предпринимателям рекламировать свои услуги в лифтах Минска. Сам «Лифт» никакую рекламу не делает, только предоставляет площадку. Это как Яндекс.Директ, только в лифте и без таргетинга.

У «Лифта» было три проблемы:

1. Предприниматели не придавали рекламе в лифтах особого значения. Делали тяп-ляп, получали плохие результаты, а потом винили во всём «Лифт».
2. Менеджерам приходилось тратить время на то, чтобы рассказать предпринимателям о новых акциях, объяснить, где находятся дома, снять предрассудки.
3. Сайт сам по себе устарел и проигрывал на фоне конкурентов.

Чтобы всё это решить, мы собрали новый сайт и интерфейс заказа рекламы. Главная страница объясняет, как разместить работоспособную рекламу:

Главная страница lift.by

Кнопка «Рассчитать стоимость» переводит сайт в режим подбора рекламы:

Интерфейс помогает выбрать лифты и поиграть со стоимостью, акциями, вариантами размещения. Если поотмечать всякие лифты и случайно попасть под акцию, на блочке акций появится бантик, а общая сумма пересчитается.

Посмотрите сами:

lift.by

Старт проекта: 4 июля. Финиш дизайна: 19 июля. Пуск: 8 сентября.
Неправильно рассчитали время на вёрстку и внедрение, скатились в фичеризм и медленно докручивали проект лишние 4 недели.

Команда
Не слабо
Ведущий дизайнер — Вадим Юмадилов
Дизайнер — Анатолий Микалюк
Вёрстка внутренних страниц — Арсений Лобастов

Кодельная
Технологи — Альбина Токарчук, Кирилл Чернаков
Менеджер — Алексей Проворов

Спасибо Дмитрию Гринкевичу за помощь и консультации.

Подробнее о проекте на сайте: fuckgrechka.ru

Часто спрашивают, почему мы запускаем два приложения отдельно: «Тяжеловато» и «Койн». Есть три причины — проверяем механику, хотим запустить пораньше и ещё одна (о ней ниже).

Первая причина — проверяем механику

«Койн» — будет учить экономить, поэтому важно не обосраться: протестировать механику учёта трат, отладить подсказки и алгоритмы. Механика очень важна. Из-за какой-нибудь фигни вроде непродуманных больших трат, люди бросают приложение. «Тяжеловато» — наш прототип для проверки механики.

Чтобы быстро тестировать механику, мы решили собрать прототип в вебе. Не зря: логику приложения переписали уже раз 6. Если бы писали под АйОС, ковыряли бы до сих пор. У меня пока ещё маловато опыта.

Вторая причина — запускаемся пораньше

Механика — это хорошо, но пока мы пилим приложение, никто всё равно не экономит. А раз уж мы всё равно пилим прототип в вебе, почему бы сразу не подарить его всем. Кто-то начнёт экономить уже в понедельник, пока мы пилим основное приложение для айфона.

Я, например, уже вторую неделю пользуюсь :-)

Третья причина — хотим, чтобы про «Койн» знала не только моя мама

Было бы нечестно об этом не сказать. Чем больше людей поделится с другими «Тяжеловато», тем больше людей узнает о «Койне». Мы не хотим, чтобы приложение валялось где-то на днище Апстора — от этого никому нет никакой пользы. Ваша обратная связь нас мотивирует.

Осталось 2 дня:
fuckgrechka.ru

P. S. «Тяжеловато» будет жить на сайте Факгречка.ру и работать на любом смартфоне. Даже если нет интернета. Поддерживать и докручивать «Тяжеловато» будет Саша Беспоясов.

В июне я разрабатывал сервис для анализа генома. Это вторая часть рассказа о работе.

Отчёт   Интерфейс приложения и фильтров

Айбином — веб-приложение для анализа генома. Чтобы повысить доверие лабораторий к Айбиному, мы улучшили внешний вид приложения и упростили интерфейс.

Старая версия

Главная страница теперь не файловый менеджер с результатами анализа, а список пациентов:

Загрузка файлов и создание нового пациента:

В результатах анализа избавились от горизонтальной прокрутки и вынесли фильтры на видное место:

Старый фильтр

Даже страница с технической информацией отражает подход компании:

Старт проекта: 17 июня. Финиш: 7 июля.
После 7 июля потратили ещё 3 дня на тестирование. В следующих проектах добавим обязательную неделю на тесты.


Отзыв Андрея Афанасьева о работе
Это первый проект iBinom с Вадимом Юмадиловым. В целом, нам понравилось и хотим работать дальше. Вадим оказался очень искренним и вовлеченным человеком, сразу рассказал о возможных недостатках работы и собственной неидеальной внимательности (что пару раз проявилось в проекте), а также продемонстрировал отличные когнитивные и коммуникативные способности. Разобраться в биоинформатике за пару недель и понять что важно, а что нет общаясь с пятью разными членами команды — такого я еще не видел.

В целом, была решена главная задача — сделать сайт солидным, понятным врачам и удобным в использовании. Было приятно, что появился даже тот функционал, который мы не обсуждали заранее.

Подход ФФФ нам понравился, все было готово с небольшим опозданием относительно договоренного срока.

Но с встраиванием написанного кода возникло много проблем — до сих пор правим баги в странной смеси ангуляра и jQuery. Правда, это скорее не к Вадиму, а к его партнеру.

Саша Беспоясов о вёрстке Айбинома

Команда
Дизайнер — Вадим Юмадилов
Технолог — Александр Беспоясов
Бекенд — Илья Китаев (Айбином)

Спасибо Андрею Афанасьеву, Александре Вачнадзе, Василию Ситнику и Владимиру Наумову за помощь и консультации.

В июне я разрабатывал сервис для анализа генома. Это первая часть рассказа о работе.

Отчёт   Интерфейс приложения и фильтров

Айбином — сервис для анализа генома, который помогает найти наследственные заболевания. Исследователь сканирует геном, запускает анализ и распечатывает отчёт с мутациями.

Первым делом мы улучшили отчёт — по нему судят о качестве сервиса. Уменьшили длину отчёта с десяти страниц до трёх, уместили данные из 40-колоночной таблицы на А4:

Таблица из старого отчёта

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

Оценка базы данных
У мутаций есть набор оценок от разных баз данных. Чтобы соотнести оценки было проще, мы отображаем их на шкале с шариками. Разброс оценок от 0 до 60. Чем выше оценка, тем правее шарик и опаснее мутация.

Распространённость
Распространённость мутации — это маленькие дробные числа от 0 до 1. Чтобы отличия между числами были заметными, мы придумали веерную визуализацию. Одна прямая — одно число. Угол наклона прямой — арксинус от числа. Чем меньше угол наклона, тем опаснее мутация.

Ещё картинка напоследок:

Дизайнерское решение без проверки не имеет ценности (не путать с бесценным). Проверять решение занудно и долго. Дизайнеру бывает западло это делать. Типа грязная работа.

Но это не грязная работа. Без проверки не узнаешь, работает ли решение. Например, в полиграфии надо выбрать материалы, напечатать варианты, повесить плакат на стене.

Это занудно и долго, а ехать в типографию вообще далеко. Зато точно знаешь: цвета не побились, плакат видно, а текст читается. Тебя ведь и для этого наняли, а не только ради макета.

Тут важно понять: не обязательно делать всё самому. Не нравится искать данные — дай задачу и проконтролируй. Не нравится пользоваться своим интерфейсом (ты странный, чувак) — собери людей, дай задачу и проконтролируй. Что угодно сделай, но не закрывай глаза на «грязную работу».

Кстати, проверять чужую работу нужно в два раза внимательнее. Исполнитель не всегда понимает задачу и видит ценность.

Но иногда отдать задачу не получается: нет денег или влияния, например. В таком случае есть секрет — заткнись, сядь и сделай. Ведь если у тебя не будет рабочих решений, то и работать с тобой никто не захочет. Зато чем больше решений работает, тем больше людей захочет сделать чё-нить такое вместе с тобой.

При оценке дизайна человек руководствуется ощущениями. Есть ощущение «чего-то не того» — плохо. Нет ощущения — хорошо. Задача дизайнера понять ощущение и сформулировать принцип.

Формулировка проблемы — одно из основных умений дизайнера. Без формулировки дизайнер не может осознанно решить задачу. Задача «избавиться от чего-то не того» слишком размытая. Работа превращается в бездумный перебор вариантов. 

Перебор вариантов утомляет, появляется ощущение безысходности. Клиент не принимает уже десятый вариант. Отношения накаляются. Кажется, клиент придирается. На самом деле это ты не понял, что делать.

Приведу пример:

— Мне не нравится. Всё слишком нагромождено. Какой-то не тот эффект, я ждал другого.
— А так?
— Тоже не то. 
— А так?
(Прошло 4 итерации)
— Всё равно нагромождено. Тебе самому-то нравится?
— А так?
(ノಠ益ಠ)ノ彡┻━┻

Клиент не ответил — ушёл к другому дизайнеру. Попробуем по-другому:

— Мне не нравится. Всё слишком нагромождено. Какой-то не тот эффект, я ждал другого.
— А что значит нагромождено? 
— Ну заголовок не видно. Там самое важное, что мы хотим сказать.
— Что ещё?
— Кнопка «Перезвонить» потерялась. Мы же хотим, чтобы нам звонили в итоге.
— А что ты имел в виду под тем, что эффект не тот?
— Мы разрабатываем программы для лабораторий. При этом у остальных программы похожи на пульт от ядерного реактора. Мы как Эпл, только для исследователей. А сейчас всё слишком сложно. Разные стили, украшения. Не то впечатление.
— Давай тогда сделаем заголовок заметнее, а кнопку переместим в центр экрана и увеличим. При этом упростим типографику и избавимся от лишних стилей: уберём тени и плашки. Что думаешь?
— Давай.
┬──┬ ノ( ゜-゜ノ)

Во втором случае дизайнер знает, что делать. Придёт к решению на несколько итераций быстрее.

Именно поэтому вместо того, чтобы сразу дорабатывать макет, дизайнер уточняет своё понимание задачи. Со стороны это выглядит как бюрократия. Казалось бы, возьми и сделай. Но лучше сначала потратить время и уточнить задачу, чем потом пытаться наугад найти правильное решение.

Умение формулировать проблемы помогает выработать принцип. Чем точнее принцип, тем понятнее ход решения. Например, сверстать макет теперь проще благодаря принципам вёрстки из советов.

Дизайнера в заметке можно легко заменить на другого специалиста. Прежде чем делать, сформулируй.

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

Докладываю: это не важно. Все эти скетч или фотошоп, верстать дизайн или рисовать макеты, пилить прототипы или не пилить — это холивары ни о чём. В отрыве от задачи не несут никакой пользы.

Задача дизайнера — понять проблему и придумать решение. Потом решение как-то перенести в реальность. Для этого надо выбрать инструмент и сделать. Инструмент — часть решения. Придумал решение — придумай, как сделать.

И тут, блин, всё очевидно. Если в задаче нет ограничений, делай в чём хочешь. В фотошопе рисуй. В скетче рисуй. В блокноте рисуй. Не важно. Можешь вообще ничего не рисовать и объяснить на пальцах, а другие сделают.

Выбирать инструмент приходится, когда в проекте есть ограничения. Например, все технологи сидят на винде. Тогда лучше про Скетч десять раз подумать. Или про технологов подумать. Но холиварить тут всё равно не о чем. Ну не подходит тут Скетч, так не используй.

Короче, сначала задача, потом инструмент. А обсуждать инструменты неплохо было бы в контексте задач. Так полезнее.

Я раньше не понимал требования типографий. Эти «слейте слои макета в один», «удалите направляющие», «пришлите ТИФФ», «ПДФ нельзя». Типографская бюрократия.

Недавно случайно попал на типографскую кухню. Теперь понимаю: склеить слои — железобетонный способ защитить макет. Иначе жопа.

Оператор ПК издевается над макетом по полной: меняет шрифты, теряет детали, перетаскивает слои из одного макета в другой. Не следи я за процессом, печатали бы заново.

На разумное предложение Фотошопа склеить слои, оператор ПК ответил отказом

До сих пор не понимаю, почему они так тупят. Зато понял пользу типографской бюрократии. Теперь для меня требования — не бюрократия. Требования — защита от мудаков.