Пользователь
0,0
рейтинг
24 февраля 2013 в 21:36

Дизайн → О бедном мокапе замолвите слово

На прошлой неделе появилась публикация Прототипируй это, определенная самим автором как «холиварная».
Раз уж разговор зашел о святом, почему бы не подкинуть пару веток в костер?

Я дизайнер интерфейсов. И я люблю мокапы.
Да и почему бы мне их не любить, если я только и делаю, что их делаю?

О прототипах или Называйте вещи своими именами

Для начала отметим, что мокапы и прототипы — отнюдь не одно и то же. В нерусском ИТ-словаре существуют несколько терминов для визуалов, соответствующих разным стадиям работы над ИТ-продуктом. Границы этих терминов размыты, но, тем не менее, увидев нечто интерфейсно-графическое, классифицировать его нетрудно.

1. Sketch (набросок, эскиз) — первоначальный моментальный набросок от руки того, что бредет в голову.
2. Wireframe (блок-схема) — схема или чертеж, представляющие «скелет» страницы сайта или приложения. Никаких украшений, только расположение и примерные размеры заголовков, текстовых блоков, иллюстраций, мультимедиа- и навигационных панелей.
3. Prototype (прототип) — модель для тестирования концепции или процесса. Могут быть вставлены картинки, появиться цвето-тональные градации и т.д.
4. Simulation (симулякр, симуляция, полнофункцональный прототип) — на сложных проектах тоже модель для тестирования концепции или процесса, но — Hi-Fi (high fidelity — высокой точности, в отличие от протопипа, который является моделью низкой точности — Lo-Fi). Для создания симуляций (или симулякров, если угодно) обычно используется программа iRise. Там используются библиотеки визуалов, позволяющие изобразить страницы очень близко к конечному виду, есть выпадающие списки, кнопки, меняющие свой вид при наведении, навигация между экранами, поп-апы и т.д.
5. Mockup или mock-up (макет) — неработающая модель, выполненная в натуральную величину и выглядящая так, как будет выглядеть работающий экземпляр. То есть, сделанная в фотошопе веб-страница, отданная на верстку — это мокап. А дизайном она станет, когда появится интерактивность. Вообще-то, мокапы могут быть относительно динамичными и интерактивными, но об этом — как-нибудь потом.

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

О принципах работы дизайнера или Почему прототипы — это хорошо

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

Но теперь ИТ-специализации выкристаллизовались, что говорит о взрослении отрасли. На смену былым чисто-понтовым сайтам идут реально работающие, сложные сервисы, растут сметы, усложняется структура рабочих групп, 21-й век стучится в черепные коробки менеджеров. И это — хорошо.

Но почему дизайнерам не нравится это разделение труда? — Да очень просто: из-за значительной потери контроля над процессом создания продукта. Раньше можно было готовить всё, что угодно, а теперь на «кухне» появилась еще одна хозяйка, которая лучше знает, как готовить полуфабрикаты, а задача дизайнера отныне — довести их до кондиции и красиво подать. Да еще эти чертовы «проектировщики взаимодействий» трубят на всех углах, что их работа важнее, чем графическое оформление, и все с ними соглашаются!

Разные ли это профессии — вопрос не стоит. Они разные, и это многократно доказано. Могут ли в одном человеке полноценно сочетаться таланты проектировщика взаимодействий (дальше для краткости я буду писать «UX») и графического дизайнера? Не всегда, но могут. Примерно так же, как некоторые пианисты могут сносно играть на гитаре. Остается вопрос, всегда ли следует отделять процессы создания UX и графики и отдавать их на откуп разным людям?

В общих чертах с этим всё просто: если у визуального дизайнера достаточно способностей, опыта и времени, чтобы заниматься UX, лучше всё отдать ему (спецы по UX с визуалами справиться не могут, если за плечами нет дизайнерского прошлого).
Но чем сложнее работа, тем настойчивее возникает вопрос о разделении труда. Рассмотрим два типичных крайних варианта.

1. Вариант идеальный для дизайнера визуалов, с точки зрения UX простейший как амёба: веб-дизайнерское онлайн-портфолио.
Тут он сам себе — заказчик и исполнитель, и с UX справляется легко. Карьера обычно начинается с этого и других несложных сайтов, выполняемых командой из 2-3 человек, где дизайнер общается с заказчиком тет-а-тет и пребывает в полной уверенности, что все, не касающееся программирования — его дизайнерская епархия. Зачастую с этой уверенностью он и идет дальше по профессии.

2. Вариант взрослый: большое и сложное клиентское приложение, демонстрирующее во всей красе разницу между проектированием взаимодействий и визуальным дизайном, например, WPF проект, находящийся в разработке два-три года и более до первого релиза.

Обычно стейкхолдеры на таких проектах — персоны столь важные, что на беседы с проектировщиками у них просто нет времени. Поэтому за адекватность постановки задач отвечают директоры сервисов (service owners). Это специалисты из той же отрасли, что и стейкхолдеры, но с уклоном в ИТ. Они понимают, какие задачи и как должен решать продукт, но в начале работы окончательный вид приложения представляют смутно, особенно, если проект инновационный, не имеющий существующих аналогов.

Проект, естественно, разбивается на короткие отрезки — спринты (обычно длиной в месяц-полтора), и группа UX в плотном, ежедневном взаимодействии с директорами сервисов начинает от спринта к спринту постепенно формировать модели работы юзеров с разными модулями и основные принципы работы с продуктом. Группа UX может состоять из 2-3 и более UX-дизайнеров и дизайнера визуалов.

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

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

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

Большинство проектов находится где-то посередине между этими крайностями, и тому, кто руководит проектом, виднее — доверить UX визуальному дизайнеру или нет. Как правило, проектирование взаимодействий — более трудозатратная и более важная часть работы над продуктом, и если дизайнер хочет контролировать процесс создания интерфейсов, он должен мигрировать в сторону UX. Но при этом нужно быть готовым к тому, что в один прекрасный день тебя отодвинут от создания визуала и наблюдать за ним придется издали.
Мне такая перспектива как-то не улыбается. Я люблю прототипы, но мокапы люблю еще больше.

Я нахожусь на Хабре в статусе Read-only и не могу оставлять комментарии. Поэтому прошу вас, добрые мои читатели, пройдитесь по хабу интерфейсов и замолвите слово о бедном мокапе.

P.s. Ответы на вопросы, заданные не мне ;-)

Публикации Прототипируй это последовали Вопросы к посту Алекса Рублева про дизайн. Хотя спрашивали не меня, могу ответить из цеховых рядов.

1. Почему, когда дизайнеров просят что-то переделать, с ними приключаются истерики? Причем, чем существеннее доработки — тем более жуткие истерики.
— Ватсон, это элементарно! Дизайнеры, с которыми вы имели дело, не из высшей лиги и никогда в ней не будут. Если человек, делая интерфейс для тачскрина, рисует миллиметровые кнопочки, то это свидетельствует об отсутствии у него аналитических способностей. Быть хорошим графиком он может, хорошим дизайнером — нет. Дизайн — это не том, как красиво все должно выглядеть, а о том, как красиво все должно работать и решать поставленные задачи. И если дизайнеру в процессе работы указали на промах, он должен благодарить коллег за вклад, позволяющий сделать продукт лучше.

2. Прототипирование действительно несколько ограничивает свободу полета творческой мысли, но сильно снижает вероятность необходимости переделок. Таким образом, меньше вероятности дизайнерских истерик. Это не оправдывает применение метода?
— Вопрос риторический, не требующий ответа. Творческая мысль дизайнера должна лететь в заданном направлении как почтовый голубь, а не куда попало как мотылек. ;-)

Или, может быть мне не такие дизайнеры попадались?
Если вы не боитесь узнать страшнобеспощадную правду, то уровень ваших дизайнеров соответствует уровню ваших проектов: «От десятков до сотен человекочасов, денег, крови и пота — чтобы получить интерфейс, удобный людям. И пять часов работы дизайнера, до или после.»
— Расходы на визуал составляют полпроцента проектной сметы? — Значит, для вас качество визуала — дело стопятидесятое. Получите и распишитесь! Думаете, в эпплах и гуглах работают по тому же принципу — «ну, всё готово, ща наймем кого-нибудь, чтоб за 5 часов разукрасил»? — Отнюдь, у них там целые дизайнерские отделы сидят!

Да, заказчику виднее, влияет ли уровень исполнения визуала на прибыльность проекта. Но что значит «до или после»? Есть же общепринятая, тысячекратно проверенная методология разработки информационных систем, определяющая последовательность: запрос заказчика > бизнес-анализ > UX > визуальный дизайн > программирование > QA и т.д. И неважно, делается ли проект методом винтажного ватерфолла или эджайлом со спринтами — последовательность одна и та же. Можно, конечно, извернуться и двинуть телегу впереди лошади, но зачем? Видимо, затем, что руководству проектами визуалы по барабану: до сделают или после, тот дизайнер или этот — лишь бы эта возня творческих личностей съела поменьше денег. А нормальные дизайнеры почему-то любят, когда к их вкладу в продукт относятся серьезно. И обычно у них есть выбор, где работать. Се ля ви…
@starboard
карма
15,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Дизайн

Комментарии (46)

  • 0
    Искренний респект вам, Холмс! Честное слово, мне порой так не хватает вас… Теперь буду некоторых коллег в этот пост носом тыкать, в некоторых случаях. Не удаляйте его, пожалуйста.

    Плюсую от души.

    (автор «Вопросов»)
    • 0
      Спасибо на добром слове :)
  • +2
    1. Почему, когда дизайнеров просят что-то переделать, с ними приключаются истерики? Причем, чем существеннее доработки — тем более жуткие истерики.


    Обычно, в условиях суровой действительности поправки со стороны заказчика выглядят несколько иначе.
  • +1
    Симулякры все же означают совсем другое:)
    И да, первоначальный набросок часто удобнее набросать в каком-нибудь Pencil Project — так как потом значительно проще вносить правки.
    • 0
      Да, слово «симулякр» в данном контексте не является общепринятым. Но оно за свою долгую историю, начиная с платоновских времен, выдержало уже столько разных применений, что может вынести и это :)
  • +1
    И где ж всех этих людей этому всему учат?..
    • +2
      В СНГ почти нигде. Может немного в Британской школе дизайна (http://www.britishdesign.ru/), да и то я сомневаюсь. Люди учатся сами, это нормальный процесс в мире ИТ в постсоветских странах. Ведь есть интернет с кучей информации!

      Могу посоветовать почитать:

      ui-cloud.com/ — база интерфейсов (США)
      gui.ru/ — про юзабилити (РФ)
      www.usability.ru/links.htm — полезные ссылки по юзабилити (РФ)
      guicci.ru/ — еще немного юзабилити (РФ)
      www.birzool.com/ — проектирование, юзабилити (РФ)
      www.uxfox.ru/ — про дизайн интерфейсов (РФ)

      Большая статья: secl.com.ua/article-serjoznoe-proektirovanie-serjoznix-saitov.html — Серьезное проектирование серьезных сайтов

      Курсы по проектированию сайтов: vk.com/topic-23829748_27521897

      В общем: кто ищет, тот всегда находит! ;)

      • +1
        Дизайн сайтов с пометкой (РФ) — очень хорошо показывают уровень UX в РФ :)
      • +1
        Большая статья: secl.com.ua/article-serjoznoe-proektirovanie-serjoznix-saitov.html — Серьезное проектирование серьезных сайтов

        А вот и отличная иллюстрация проблемы.
        Анализ, сценарии, mind map, структура сайта — все отлично.
        А потом внезапно проектировщик, далекий от визуального представления информации, берется за прототип. И ожидаемый результат в конце статьи.
        Печально.
        • 0
          А кто, как не проектировщик должен делать прототип?
          • +1
            Дизайнер.
            Или хотя бы проектировщик с опытом в дизайне (или как это называет создатель статьи — визуальный дизайнер).

            Аналитика у вас классная, но ради эксперимента, дайте всю эту аналитику без прототипа хорошему дизайнеру с опытом в прототипировании — и посмотрите какой прототип получите на выходе.
            • 0
              Не соглашусь. Этим должны заниматься разные люди. Вот другой пример (может тот Вам не понравлся по каким либо причинам):

              secl.com.ua/work/fotoua_maket.html — прототип
              secl.com.ua/work/fotoua.html — дизайн

              Делали разные специалисты с разным опытом. Этот больше нравится или так же?
              • +1
                Боюсь что этот диалог скатится к банальной оценки чьей-то работы. Не думаю что это хорошая идея :)

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

                Лично мне, итог не нравится. Возможно он в чем-то правильный, но абсолютно безликий.
                • 0
                  Подождите, что значит «забыв»? :) Он не забыл, ему это даже запрещено! Есть технология проектирования, по ней проектировщик не имеет права применять цвета, они оттягивают внимание от сути макета. А дизайнер, в свою очередь, по сути разукрашивает, но никто ему не запрещает вносить предложения по самому расположению элементов и деталям. Не знаю как работаете Вы, но мы работаем только так.
                  • +1
                    Давайте по порядку.

                    Графический дизайн — это не только цвета. Это внешний вид, который включает в себя и расположение, и удобство, и навигацию, и цветовую схему, и эмоции и кучу других составляющих. Это то цельное, что в итоге видит пользователь и чем он пользуется и чем ему хочется пользоваться. Или не хочется.

                    Лично я не представляю возможным проектировать что-либо, забывая о какой-либо составляющей.

                    Красивая цветовая схема и убогая навигация — плохой итог. Плохая цветовая схема и отличная навигация — плохой итог. Так как эти две составляющие работают только вместе, в комплексе. Все составляющие интерфейса работают только вместе, в комплексе.

                    Вы же, вместо того, что бы объединить усилия, еще больше разделяете их. Проектировщика и дизайнера ограничиваете сводом каких-то правил. Это цепочка возможно выглядит отлично на бумаге: проектировщик спроектировал — дизайнер разукрасил и никто никому не мешает, но не приводит к отличным результатам.
                    • 0
                      Логика напомнила мне 90е) Тогда был один человек, который назывался «веб-мастер» и он делал сайт от и до. Мы, в SECL Group, считаем это в корне неправильным. Сайт всегда должна делает группа специалистов, у каждого человека своя узкая специализация, в которой каждый является гуру, лучшим. В связке с эффективным взаимодействием проектной группы мы всегда можем получить отличный сайт.

                      Есть и другой подход, его до сих пор некоторые «конкуренты» используют: когда сайт целиком делает один человек… Но результат этого очень печален.

                      Дизайнер — это во многом художник, особый тип таланта (кроме знаний). Проектировщик — это, прежде всего, аналитик и логик. Совсем разные специализации, которые делают интерфейсы с разной точки зрения и только плод их совместной деятельности будет качественным со всех сторон.
                      • +1
                        Ну вот вы и сами сказали:
                        Проектировщик — это, прежде всего, аналитик и логик.

                        А что такое дизайнер — можете на википедие почитать.
                        Вы описываете связку Проектировщика + Художника. В этом случае все ок. Это более дешевый способ, чем Аналитик + Дизайнер.
                        • 0
                          Это тоже самое, в идеале даже на 3 части разделить (мы к этому идем сейчас): аналитик, проектировщик интерфейсов, дизайнер.
                          • +1
                            Художник и дизайнер это не одно и тоже :)
                            • 0
                              Не спорю. Я говорил именно про дизайнера, но с талантом, который умеет не просто раскрашивать и аналитически мыслить, но и рисовать от руки, т.е. определенный талант. Это идеальный дизайнер.
                    • 0
                      Если у визуального дизайнера есть претензии к навигации, пусть аргументирует их и предложит альтернативу, — в чем проблема? Просто дизайнеры UX и визуалов должны работать в контакте.
          • 0
            Вот пример разработки дизайна сайта: http://www.artlebedev.ru/everything/mybook/process/
            Посмотрите на каком этапе вступает дизайнер.

            Что бы не разводить очередной холливар на любителей и не любителей Студии Лебедева, скажу, что финальный дизайн мне не особо нравится. Но подход и схема работы — отличная.
            • 0
              У нас другая технология разработки.
            • 0
              Да, нормальная схема работы, вовремя вступает дизайнер — после того, как блок-схемы шаблонов напилены.
              По второму варианту они выложили только графическую часть, видимо, убрав информацию о UX и проектном планировании, дабы не было слишком нудно. А схема работы может меняться в зависимости от нужд конкретного проекта.

              Не сомневаюсть, что они читают книги по UX так же, как читают Эдварда Тафти (о чем «маячат» тем, кто «в теме» :)
    • 0
      Если вас интересует UX, то черпайте информацию из сети и книжек. Хорошо, если есть возможность участвовать в конференциях. Ажиотажный спрос на специалистов по UX возник после того, как Apple натянула всем нос своими тачскрин-гаджетами, т.е. совсем недавно. Не хватает ни преподавателей, ни разработанных методик. В этом даже есть плюсы — эти вещи инновационные и создаются прямо на глазах. Но высшеее образование либо в ИТ, либо в дизайне иметь очень желательно.

      Хотя… Вот недавняя история, как человека без профильного образования и опыта работы взяли в UX-группу приличной фирмы. После двух телефонных интервью его вызвали на собеседование, которое оказалось 4-х часовым тестированием, вместе с его потенциальным конкурентом (тот был из программистов, с 6-летним опытом).

      После всяких вопросов им дали задание вместе разработать веб-сайт, причем, работодатели сидели и, что называется, пасли все их действия, включая поведение. Тут возник довольно тонкий этический момент, так как каждому из претендентов нужно было показать себя лучшим кандидатом, не топя конкурента.
      Взяли обоих, причем, поставили работать в паре, — оказывается, работодатели изначально рассматривали такой вариант и устроили им такой проверочный трюк.
  • 0
    Мокапы, прости господи… уже есть замечательное слово эскиз.
    • 0
      Эскиз это скетч, карандашом на салфетке например. Назвать наброски на салфетках мокапом язык не повернется.
      • 0
        Помимо свободных художников, эскизы есть еще и у инженеров в черчении:
        Эскиз – это чертеж, выполненный без применения чертежных инструментов, без точного соблюдения масштаба, но с соблюдением пропорций между отдельными элементами деталей.
        • 0
          Что и подтверждает, эскиз — это скетч.
          Мокап — прочтите ещё раз его определение. Это готовый графический дизайн интерфейса с обозначенными айдлами, ховерами, эктивами и прочими состояниями интерактивных элементов, который можно отдать на вёрстку (например, в .PSD).
    • 0
      en.wikipedia.org/wiki/Mockup
      В русском языке аналога слова mokup я не знаю. Наиболее близким было слово «макет», но макеты могут быть в любом масштабе и иметь сходство с реальным объектом только в общих очертаниях, например, макет застройки микрорайона.
  • 0
    Отличная статья. После всех холиваров недавних связанных с этой темой на хабре, долго в голове вынашивал подобный текст, но так и не решился выдать отдельным постом.
    А вообще, если говорить за отдельно взятый фриланс и заказчиков, которые недовольны дизайнерами, то мне кажется, что всему виной тут как раз таки те дизайнеры, которые впаривают свое под любым проектом, даже тем, который объективно не по зубам. А заказчики в свою очередь ведутся больше на слова и на обещания за демпингованые цены.
    • 0
      Спасибо за высокую оценку :)
      Честно говоря, прокрутив в голове ответы на статью о прототипах, я начал писать ответ почти сразу, но быстро надоело, бросил. Потом, дня через три, напрягся и, сильно сократив, домучил :) Жаль выбрасывать дополнителные аргументы и красочные примеры, но если есть ощущение, что иначе до конца не дотянуть, то приходится…
  • 0
    Проблема дизайнеров-художников и дизайнеров-проектировщиков видимо не разрешится никогда. О чем свидетельствует эта статья, отчетливо разделяющая визуал-дизайнера от дизайнера-интерфейсов.
    • +3
      Я по-прежнему придерживаюсь мнения, что UX дизайнер должен иметь неплохие навыки визуала. Может быть он не отрисует до финала, может быть он не сделает иконки, но композиция, построение, цвет — должно быть при нем.

      Моя претензия к подходу «UX отдельно, визуал отдельно» сводится к тому, что: UX без навыков визуала не создает впечатляющих проектировочных решений и даже сильному визуалу потом превратить в конфету то, что нарисовал UX практически невозможно. Да, то что делает UX без понимания визуала — эффективно работает, но не эффектно.
      • 0
        Каждый специалист своей области, должен обладать достаточным знанием в смежных. Это не вопрос «UX и рисовальщика», это вопрос компетентности вообще.
    • +1
      UX:


      UX с навыками визуала:
      • 0
        да ну, какие там навыки визуала. Ни за что не поверю, что на синем фоне будет тёмно-синий текст. И вообще в серо-зелёно-сине-голубой плашковый сайт. Тот же скетч, просто цветастый. Уверен, цвета не для этого эскиза подобраны, а шаблонные — выделяются логические группы и элементы внутри них. Причём здесь дизайн вообще?
      • +1
        Это скорее не навыки визуала, а обыкновенная тяга адекватного дизайнера сделать красиво даже в простом прототипе. И я считаю, это правильно, т.к. такое заказчик проще примет (%. Если, конечно, не начинает отнимать лишнее время, т.к. скорость в данном случае важнее.
      • 0
        Из этих примеров мне непонятно, как чужие вайрфреймы или прототипы могут мне помешать в работе. Я все равно применю те цвета и графические приемы, какие посчитаю нужными.

        Когда UX-дизайнеры приносят мне прототипы, в процессе обсуждения они должны обьяснить и обосновать свои решения. Например, навскидку — по второй картинке:

        1. Я вижу, что основной фокус внимания находится в верхнем правом углу. Два второстепенных фокуса — текстовая строка слева, (которая по мощи тянет не заголовок, но находится под информационным блоком — почему?) и оранжевый блок справа. Правильно ли я понимаю иерархию, и почему именно эти части важнее остальных?

        2. Я вижу круглые аватарки. Какими соображениями вызвано их размещение то в левом верхнем углу, то вверху посередине, то сбоку справа и применение 3-х разных размеров?

        3. В нижней части верхнего левого блока размещены ссылки в виде навигационной цепочки. Почему не в верхней, как это обычно принято? Почему массив ссылок справа тоже напоминает навигационные цепочки с движением слева направо?

        И т.д.
        • 0
          Как по мне, любому дизайнеру должно быть худо-бедно понятно что же на второй картинке.
          Интуитивно понятно, что на второй картинке пример прототипа блога-новостной ленты. «Навигационная цепочка», как вы назвали, обычные тэги. Круглые аватарки слева — авторы постов.Сбоку справа — последние комментировавшие. А аватар посередине — это аватар непосредственно залогиненого юзера.
          • 0
            Я спрашивал, почему ссылки имеют движение слева направо, как breadcrumbs, почему аватарки разных размеров и гуляют по инфоблоку, путая ментальную карту, и т.д… Если бы я получил подобный ответ от UX-дизайнера, это означало бы, что все это сделано просто ради композиционных пятен и может быть переделано по моему усмотрению…
      • 0
        Выбор между бальзамиком с комментариями и неясным набором прямоугольников без комментариев? Бальзамик победил (хотя я все предпочитаю axure, но это дело вкуса :)
    • 0
      И я абсолютно согласна с этим разделением. Хотя в удачном случае совмещать ничто не мешает, лучше не делать этого на одном проекте.
  • 0
    Часть терминов (sketch, mockup, prototype, etc.) была раскрыта в переводе статьи «Wireframing, Prototyping, Mockuping – What’s the Difference?».
    • 0
      Да, об этом пишут регулярно, но путаница с употреблением терминов продолжается, даже среди англоязычных разработчиков.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.