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

Коллеги порекомендовали мне несколько книг, в том числе «Дизайн сайтов» , « Не заставляйте меня думать» и « Почему программное обеспечение отстой» , но мне интересно, что сделали другие, чтобы устранить свои недостатки в этой области?

Позвольте мне сказать это прямо:

Улучшение этого не начинается с руководящих принципов. Это начинается с переосмысления того, как вы думаете о программном обеспечении.

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

Типичная проблема, когда эксперт сталкивается с непрофессионалом: с какой стати нормальный человек может быть настолько глуп, что не может понять, что эксперт понял 10 лет назад?

Один из первых фактов, который признает, что невероятно трудно понять почти всем опытным разработчикам, это:

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

Теперь это невероятно тяжело для разработчика. Он гордится программным обеспечением, которое он производит. Он любит каждую особенность. Он может точно сказать вам, как работает код. Возможно, он даже изобрел невероятно умный алгоритм, который заставил его работать на 50% быстрее, чем раньше.

И пользователю все равно.

Какой идиот.

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

Они не.

Если разработчик программного обеспечения покупает автомобиль, он ожидает, что он будет работать без сбоев. Его обычно не волнует давление в шинах, механическая подстройка, которая была важна, чтобы заставить его работать таким образом. Здесь он не эксперт. И если он покупает машину, у которой нет точной настройки, он возвращает ее и покупает ту, которая делает то, что он хочет.

Многие разработчики программного обеспечения любят фильмы. Хорошие фильмы, которые пробуждают воображение. Но они не являются экспертами в создании фильмов, в создании визуальных эффектов или в написании хороших сценариев фильма. Большинство ботанов очень, очень, очень плохо действуют, потому что все дело в проявлении сложных эмоций и мало в аналитике. Если разработчик смотрит плохой фильм, он просто замечает, что он плохой в целом. Ботаники даже создали IMDB для сбора информации о хороших и плохих фильмах, чтобы они знали, какие смотреть, а какие избегать. Но они не являются экспертами в создании фильмов. Если фильм плохой, они не пойдут в кино (или не скачают его с BitTorrent;)

Так что все сводится к тому, чтобы: избегать обычных пользователей как экспертов - это невежество. Потому что в тех областях (а их так много), где они не являются экспертами, они ожидают, что эксперты других областей уже подумали о нормальных людях, которые пользуются их продуктами или услугами.

Что вы можете сделать, чтобы исправить это? Чем больше вы хардкор как программист, тем меньше вы будете открыты для обычного мышления пользователя. Это будет чуждо и невежественно для вас. Вы подумаете: я не могу представить, как люди могли бы использовать компьютер с таким недостатком знаний. Но они могут. Для каждого элемента пользовательского интерфейса подумайте: нужно ли это? Соответствует ли это концепции моего инструмента пользователю? Как я могу заставить его понять? Пожалуйста, ознакомьтесь с юзабилити для этого, есть много хороших книг. Это тоже целая область науки.

Ну, и прежде чем вы скажете это, да, я фанат Apple;)

Дизайн пользовательского интерфейса является жестким

На вопрос:

почему дизайн пользовательского интерфейса настолько сложен для большинства разработчиков?

Попробуйте задать обратный вопрос:

почему программирование так сложно для большинства дизайнеров пользовательского интерфейса ?

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

Кодирование сложно. Дизайн тоже сложный. Немногие люди делают оба хорошо. Хорошие дизайнеры пользовательского интерфейса редко пишут код. Возможно, они даже не знают как, но все же они хорошие дизайнеры. Так почему же хорошие разработчики чувствуют ответственность за дизайн пользовательского интерфейса?

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

Как стать лучше в дизайне пользовательского интерфейса

Для разработчиков, желающих стать лучше в дизайне пользовательского интерфейса, у меня есть 3 основных совета:

1. Признать дизайн как отдельный навык . Кодирование и дизайн являются отдельными, но связаны между собой. Дизайн пользовательского интерфейса не является подмножеством кодирования. Это требует другого мышления, базы знаний и группы навыков. Есть люди, которые сосредоточены на дизайне пользовательского интерфейса.
2. Узнайте о дизайне . По крайней мере, немного. Попробуйте изучить несколько концепций и приемов проектирования из длинного списка ниже. Если вы более амбициозны, прочитайте несколько книг, посетите конференцию, возьмите курс, получите диплом. Есть много способов узнать о дизайне. Книга Джоэла Сполки о дизайне пользовательского интерфейса - хороший учебник для разработчиков, но в ней есть гораздо больше, и именно здесь дизайнеры приходят к выводу.
3. Работа с дизайнерами . Хорошие дизайнеры, если можете. Люди, которые делают эту работу, имеют разные названия. Сегодня наиболее распространенными названиями являются User Experience Designer (UXD), Information Architect (IA), Interaction Designer (ID) и Usability Engineer. Они думают о дизайне так же, как вы думаете о коде. Вы можете многому научиться у них, а они у вас. Работайте с ними как можете. Найти людей с этими навыками в вашей компании. Может быть, вам нужно кого-то нанять. Или посетите некоторые конференции, посетите вебинары и проведите время в мире UXD / IA / ID.

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

• Изучите фундаментальные концепции дизайна . Вы должны знать о возможностях, видимости, обратной связи, сопоставлениях, законе Фитта, покаках и многом другом. Я рекомендую прочитать «Дизайн повседневных вещей» (Дон Норман) и « Универсальные принципы дизайна» (Лидуэлл, Холден и Батлер)
• Узнайте о пользовательском опыте . Это становится общим термином для ориентированного на человека дизайна веб-сайтов, приложений и любых других цифровых артефактов. Классический учебник здесь - «Элементы пользовательского опыта» (Джесси Джеймс Гарретт). Вы можете получить обзор и первые несколько глав с сайта автора .
• Учитесь рисовать эскизы . Эскиз - это быстрый способ изучить варианты дизайна и найти правильный дизайн, в то время как юзабилити-тестирование - это получение правильного дизайна. Бумажное прототипирование быстро, дешево и эффективно на ранних стадиях проектирования. Гораздо быстрее, чем кодирование цифрового прототипа. Ключевым текстом здесь является Sketching User Experience: получение правильного дизайна и правильного дизайна ( Билл Бакстон ). Эскиз особенно полезен при работе с дизайнерами IA / ID / UX. Ваше сотрудничество будет более эффективным. Для хорошего ознакомления с тем, как и почему дизайнеры делают наброски, посмотрите презентацию « Как стать одной командой UX» Лии Були с саммита IA 2008 .
• Изучите бумажное прототипирование . Самый быстрый способ итеративного тестирования интерфейса перед написанием кода. Отличается от зарисовок и юзабилити-тестирования. Полная книга здесь - Бумажное Прототипирование (Кэролайн Снайдер). Вы можете получить хороший DVD об этом от Nielsen Norman Group .
• Изучите юзабилити-тестирование . Дисконтное тестирование легко и эффективно. Но для многих пользовательских интерфейсов юзабилити трудно сделать хорошо. Вы можете выучить основы быстро, но хорошие юзабилити люди бесценны. Если вы хотите книгу, классика - «Справочник по юзабилити-тестированию» (Джеффри Рубин). Он старше, но предлагает полный охват лабораторных испытаний. Знаменитая книга для начинающих - « Не заставляй меня думать» (2-е издание ) (Стив Круг). Я предупреждаю людей об этом: Круг звучит легче, чем есть. Но это хорошая отправная точка. Книги исследований пользователей, перечисленные в следующем пункте, также охватывают эту тему. И вы можете найти кучу об этом в Интернете.
• Узнайте об информационной архитектуре . Основная книга здесь - информационная архитектура для всемирной паутины (3-е) (Луи Розенфельд и Питер Морвилль). Хорошая книга для начинающих - информационная архитектура: чертежи для Интернета (Кристина Водтке). Для получения дополнительной информации посетите Институт информационной архитектуры или посетите ежегодный Саммит информационной архитектуры .
• Узнайте о дизайне взаимодействия . Основной книгой здесь является «Основы проектирования взаимодействия» (3-е) (Алан Купер и др. ). Хорошая книга для начинающих - Проектирование для взаимодействия (Дэн Саффер). Для получения дополнительной информации посетите Ассоциацию дизайна взаимодействия (IxDA) или посетите ежегодную конференцию дизайна взаимодействия .
• Изучите основы графического дизайна . Графический дизайн - это не дизайн пользовательского интерфейса, но концепции графического дизайна могут улучшить интерфейс. Графический дизайн вводит принципы дизайна для визуального представления информации, такой как близость, выравнивание и кратность. Я рекомендую прочесть книгу о дизайне не дизайнера (Робин Уильямс) и Envisioning Information (Эдвард Туфте)
• Научитесь проводить исследования пользователей . Там, где юзабилити тестирует интерфейс, пользовательские исследования пытаются моделировать пользователей и их задачи с помощью персон, сценариев, поездок пользователей и других документов. Речь идет о том, чтобы понять пользователей и то, что они делают, а затем использовать это для информирования дизайна, а не гадать. Некоторые методы - это интервью, опросы, дневниковые исследования и сортировка тележек. Хорошие книги по этому вопросу - « Наблюдение за пользовательским опытом» (Майк Кунявский) и « Понимание ваших пользователей» (Courage & Baxter)
• Научитесь проводить полевые исследования . Наблюдение за людьми в лаборатории в искусственных условиях помогает (например, удобство использования), но нет ничего лучше, чем наблюдение за тем, как люди используют ваш код в контексте: дома, в офисе или где бы то ни было. Идет под разными именами, включая этнографию, полевые исследования и контекстные исследования. Вот хороший учебник по полевым исследованиям . Здесь представлены две наиболее известные книги: « Быстрое контекстное проектирование» (Карен Хольцблатт и др. ) И «Анализ пользователя и задач для проектирования интерфейса» («Хакос и рыжий»).
• Читайте UX дизайн веб-сайтов . Некоторые из самых больших - Boxes & Arrows , UX Mag , UX Matters и журнал Digital Web .
• Используйте библиотеки шаблонов пользовательского интерфейса . Есть шаблоны для интерфейсов. Для веб-сайтов я рекомендую «Дизайн сайтов», 2-е издание (Van Duyne и др. ) И удобство использования домашней страницы: 50 веб-сайтов деконструированы (Jakob Nielsen & Marie Tahir). Для настольных приложений я рекомендую Проектирование интерфейсов (Дженнифер Тидуэлл), а для веб-приложений я рекомендую Проектирование веб-интерфейсов: принципы и шаблоны для богатых взаимодействий (Билл Скотт и Тереза ​​Нил). Интернет вы должны проверить библиотеку Welie шаблона , шаблоны пользовательского интерфейса , а также шаблоны веб - интерфейс .
• Посещать UX дизайн конференций . Вот некоторые хорошие ежегодные конференции: Summit Information Architecture Summit , Interaction '09 (IxDA) , Пользовательский интерфейс и неделя UX .
• Посетите семинар или вебинар . Вы можете пройти семинары, вебинары и онлайн-курсы. Это далеко не полный список, но вы можете попробовать виртуальные семинары UIE , Adaptive Path виртуальных семинаров и UX вебинары от Розенфельд СМИ .
• Получи степень . Степень магистра в области HCI является одним из подходов, но эти программы в основном посвящены написанию кода. Если вы хотите узнать о дизайне цифровых артефактов и устройств, то вам нужна программа для выпускников, которая не входит в CS. Некоторые варианты включают дизайн взаимодействия в Carnegie Mellon , d-School в Стэнфорде , программу ITP в NYU и информационную архитектуру и управление знаниямив штате Кент (раскрытие: я работаю на факультете в Кенте; мы видим, что все больше людей со степенями CS переходят в UX-дизайн вместо управления, что интересно, потому что управление - это традиционный путь для разработчиков, которые хотят отойти от писать код, оставаясь на своем поле). Есть еще много программ. У каждого есть своя точка зрения, области акцента и технические ожидания. Некоторые приходят из искусства и визуального дизайна, другие из библиотеки и информатики, а некоторые из CS. Большинство из них являются гибридами, но каждый гибрид имеет более глубокие корни в одной или нескольких областях. Если вас это интересует, посмотрите вокруг и постарайтесь понять разницу между этими программами. Некоторые предлагают онлайн-курсы и программы сертификации в дополнение к полноценным степеням.

Почему дизайн интерфейса сложен?

Хороший дизайн интерфейса сложен, потому что он включает в себя 2 совершенно разных навыка:

• Глубокое понимание машины . Люди в этой группе беспокоятся о коде во-первых, люди во-вторых. У них глубокие технологические знания и навыки. Мы называем их разработчиками, программистами, инженерами и так далее.
• Глубокое понимание людей и дизайна : люди в этой группе сначала беспокоятся о людях, а потом - о коде. Они глубоко знают, как люди взаимодействуют с информацией, компьютерами и окружающим миром. Мы называем их дизайнерами пользовательского опыта, информационными архитекторами, дизайнерами взаимодействия, юзабилити-инженерами и так далее.

Это существенная разница между этими двумя группами - между разработчиками и дизайнерами:

• Разработчики заставляют это работать . Они реализуют функциональность вашего TiVo, вашего iPhone, вашего любимого сайта и т. Д. Они удостоверяются, что он действительно делает то, что должен делать. Их самый высокий приоритет - заставить это работать.
• Дизайнеры заставляют людей любить это . Они выясняют, как с ним взаимодействовать, как он должен выглядеть и как он должен себя чувствовать. Они проектируют опыт использования приложения, веб-сайта, устройства. Их главный приоритет - заставить вас влюбиться в то, что делают разработчики. Это то, что подразумевается под пользовательским опытом, и это не то же самое, что опыт бренда.

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

Разработчики должны рассчитывать на сложность разработки пользовательского интерфейса, точно так же, как и дизайнеры интерфейса должны ожидать, что написание кода сложно.

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

Удивительно, что вы поймете, когда увидите, как кто-то другой впервые использует ваше программное обеспечение.

В конечном счете, это действительно сопереживание - можете ли вы поставить себя на место пользователя?

Одна вещь, которая помогает, конечно, это «есть свою собачью еду» - использовать свои приложения в качестве реального пользователя самостоятельно и видеть, что раздражает.

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

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

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

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

Рассмотрим следующее; Хороший бэкэнд-дизайн основан на достаточно твердых принципах и элементах, с которыми знаком любой хороший разработчик:

• низкая связь

• высокая сплоченность

• архитектурные образцы

• лучшие отраслевые практики

• и т.д

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

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

• видимость

• affordance

• Обратная связь

• толерантность

• простота

• консистенция

• структура

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

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

Я рекомендую пройти курс по взаимодействию с человеком, проверить MIT и сайт Йельского университета, например, на наличие онлайн-материалов:

• Курс по разработке и внедрению пользовательского интерфейса MIT

Структурная и функциональная модель в понимании и использовании

Превосходный предыдущий пост Thorsten79 поднимает тему экспертов по разработке программного обеспечения против пользователей и как их понимание программного обеспечения отличается. Специалисты по человеческому обучению различают функциональные и структурные ментальные модели. Нахождение пути к дому вашего друга может быть отличным примером разницы между ними:

• Первый подход включает в себя набор подробных инструкций: первый съезд с автострады, затем через 100 м поверните налево и т. Д. Это пример функциональной модели: список конкретных шагов, необходимых для достижения определенной цели. Функциональные модели просты в использовании, они не требуют много размышлений, просто прямолинейное исполнение. Очевидно, что за простоту есть штраф: это может быть не самый эффективный маршрут, и любая исключительная ситуация (например, переадресация) может легко привести к полному отказу.

• Другой способ справиться с задачей - построить структурную ментальную модель. В нашем примере это будет карта, которая передает много информации о внутренней структуре «объекта задачи». Из понимания карты и относительного местоположения дома нашего и друга мы можем определить функциональную модель (маршрут). Очевидно, что это требует больше усилий, но гораздо более надежного способа выполнения задачи, несмотря на возможные отклонения.

Выбор между передачей функциональной или структурной модели через пользовательский интерфейс (например, мастер или расширенный режим) не так прост, как может показаться из поста Thorsten79. Опытные и частые пользователи вполне могут предпочесть структурную модель, тогда как случайные или менее опытные пользователи - функциональные.

Карты Google - отличный пример: они включают в себя как функциональную, так и структурную модель, как и многие спутниковые навигационные системы.

Другое измерение проблемы заключается в том, что структурная модель, представленная через пользовательский интерфейс, не должна отображаться на структуру программного обеспечения, а скорее должна отображаться на структуру пользовательской задачи или объекта задачи.

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

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

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

альтернативный текст http://www.stricken.org/uploaded_images/WordToolbars-718376.jpg

Теперь подумайте об этом:

Дизайнер знает, что достиг совершенства не тогда, когда нечего добавить, а когда нечего убрать. - Сент-Экзюпери

И примените это в своем дизайне.

Многие разработчики считают, что, поскольку они могут писать код, они могут делать все это. Разработка интерфейса - это совершенно другой навык, и когда я учился в колледже, его совсем не учили. Это не просто то, что просто естественно.

Еще одна хорошая книга Дональда Нормана «Дизайн повседневных вещей ».

Существует огромная разница между дизайном и эстетикой, и они часто путаются.

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

Создание полезных пользовательских интерфейсов требует понимания того, как люди взаимодействуют с компьютерами, некоторых проблем психологии (например, закон Фитта, закон Хика) и других тем. Очень немногие программы CS обучают этому. Очень немногие разработчики, которых я знаю, выберут книгу тестирования пользователей вместо книги JUnit и т. Д.

Многие из нас также являются «основными программистами», склонными думать о пользовательском интерфейсе как о фасаде, а не как о факторе, который может создать или сломать успех нашего проекта.

Кроме того, большая часть опыта разработки пользовательского интерфейса крайне разочаровывает. Мы можем либо использовать игрушечные конструкторы графического интерфейса, такие как старый VB, и иметь дело с уродливым клеевым кодом, либо мы используем API, которые без конца расстраивают нас, например, пытаясь разобраться в разметке в Swing.

Перейдите к Slashdot и прочитайте комментарии к любой статье, касающейся Apple. Вы найдете множество людей, рассказывающих о том, что продукты Apple не являются чем-то особенным, и приписывающих успех iPod и iPhone людям, которые пытаются быть модными или модными. Они, как правило, просматривают списки функций и указывают, что они не делают ничего, что раньше не делали MP3-плееры или смартфоны.

Тогда есть люди, которым нравятся iPod и iPhone, потому что они делают то, что хотят пользователи, просто и легко, без ссылок на руководства. Интерфейсы примерно такие же интуитивно понятные, как и интерфейсы, запоминающиеся и обнаруживаемые. Мне не так нравится пользовательский интерфейс в MacOSX, как в предыдущих версиях, я думаю, что они отказались от некоторой пользы в пользу блеска, но iPod и iPhone - примеры превосходного дизайна.

Если вы находитесь в первом лагере, вы не думаете, как это делает средний человек, и поэтому вы, скорее всего, создадите плохие пользовательские интерфейсы, потому что не сможете отличить их от хороших. Это не значит, что вы безнадежны, скорее, вам нужно явно изучить хорошие принципы дизайна интерфейса и узнать, как распознать хороший интерфейс (так же, как кому-то с Asperger'ом может понадобиться явно изучить социальные навыки). Очевидно, что просто ощущение хорошего пользовательского интерфейса не означает, что вы можете создать его; например, моя оценка литературы не распространяется на способность (в настоящее время) писать публикуемые истории.

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

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

Я думаю, что определенно возможно быть и хорошим внутренним разработчиком, и хорошим дизайнером пользовательского интерфейса, вам просто нужно поработать над этим, немного почитать и исследовать эту тему (все от # 7 Миллера до архивов Нильсена) и сделать конечно, вы понимаете, почему дизайн пользовательского интерфейса имеет первостепенное значение.

Я не думаю, что это необходимость творчества, а скорее, как внутреннее развитие, это очень методичная, очень структурированная вещь, которую нужно изучать. Именно люди, проявляющие «творческий подход» к пользовательскому интерфейсу, создают самые большие чудовища удобства использования ... Я имею в виду, для начала посмотрите на 100% Flash-сайты ...

Редактировать : книга Круг действительно хороша ... прочитайте ее, особенно если вы собираетесь разрабатывать для Интернета.

Есть много причин для этого.

(1) Разработчик не видит вещи с точки зрения пользователя. Это обычный подозреваемый: отсутствие эмпатии. Но обычно это не так, так как разработчики не такие чуждые, как это делают люди.

(2) Другая, более распространенная причина заключается в том, что разработчик, который так близок к своему собственному материалу, так долго оставаясь со своим материалом, не понимает, что его материал может быть не таким знакомым (термин лучше, чем интуитивный) для других людей. ,

(3) Еще одна причина - разработчик испытывает недостаток в методах.

МОЙ БОЛЬШОЙ ПРЕТЕНЗИЯ: читать любой пользовательский интерфейс, дизайн человеческого взаимодействия, книга по прототипированию. напр., «Разработка очевидного: подход здравого смысла к дизайну веб-приложений», «Не заставляй меня думать»: подход здравого смысла к удобству веб-разработки, разработка момента, что угодно.

Как они обсуждают потоки задач? Как они описывают точки принятия решений? То есть в любом случае есть как минимум 3 пути: успех, сбой / исключение, альтернатива.

Таким образом, из пункта А вы можете перейти к А.1, А.2, А.3. Из пункта А.1 вы можете добраться до А.1.1, А.1.2, А.1.3 и т. Д.

Как они показывают такую ​​последовательность операций детализации? Они не Они просто затуманивают это.

Так как даже у эксперта UI нет техники, у разработчиков нет шансов. Он думает, что это ясно в его голове. Но это даже не ясно на бумаге, не говоря уже о реализации программного обеспечения.

Я должен использовать свои собственные методы ручной работы для этого.

Я стараюсь поддерживать связь с дизайн-сайтами и текстами. Я также обнаружил, что превосходная книга Робина Уильямса «Книга дизайна не дизайнера» очень интересна в этих исследованиях.

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

Каждый может быть дизайнером время от времени, а также каждый может быть программистом.

Подходя к дизайну пользовательского интерфейса, вот несколько вещей, которые я имею в виду (далеко не полный список):

• Общение модели . Пользовательский интерфейс - это рассказ, который объясняет ментальную модель для пользователя. Эта модель может быть бизнес-объектом, набором отношений, что есть у вас. Визуальная значимость, пространственное размещение и упорядочение рабочего процесса играют важную роль в передаче этой модели пользователю. Например, определенный вид списка против другого подразумевает разные вещи, а также отношение того, что в списке, к остальной части модели. В общем, я считаю, что лучше всего убедиться, что одновременно сообщается только одна модель. Программисты часто пытаются связать несколько моделей или их частей в одном и том же пространстве пользовательского интерфейса.

• Консистенция . Повторное использование популярных метафор пользовательского интерфейса очень помогает. Внутренняя согласованность также очень важна.

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

• Зная свою аудиторию . Если ваши пользователи будут выполнять одни и те же действия снова и снова, они быстро станут опытными пользователями при выполнении этих задач и будут разочарованы попытками снизить начальный входной барьер. Если ваши пользователи нечасто выполняют много разных видов деятельности, лучше всего убедиться, что пользовательский интерфейс держит их руку все время.

Прочитайте Руководство по интерфейсу Apple для человека .

Я считаю, что лучшим инструментом в дизайне пользовательского интерфейса является наблюдение за первой попыткой пользователя использовать программное обеспечение. Возьмите кучу заметок и задайте им несколько вопросов. Никогда не направляйте их и не пытайтесь объяснить, как работает программное обеспечение. Это работа пользовательского интерфейса (и хорошо написанная документация).

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

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

duffymo только что напомнил мне, почему: многие программисты считают «* Design» == «Art».

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

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

Что я сделал, чтобы стать лучше в дизайне пользовательского интерфейса?
Обратите на это внимание!

Это как когда-нибудь, когда вы видите график в новостях или электронный автобусный знак, и вы удивляетесь: «Как они получили эти данные? Они сделали это с помощью raw sql или используют LINQ? (или вставьте здесь свое собственное любопытство).

Вы должны начать делать это, но с визуальными элементами всех видов.

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

Взято из другого ответа, который я написал:

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

Как бы вы это ни делали (и выше есть несколько замечательных моментов), это действительно помогло мне, когда я понял, что ТАКОГО ИНТУИТИВНОГО НЕТ ТАКОГО ...

Я могу услышать грохочущие аргументы на горизонте ... поэтому позвольте мне объяснить немного.

Интуитивно понятный: используя то, что чувствуешь, чтобы быть правдой или правдой, основываясь на бессознательном методе или чувстве.

Если (как постулировал Карл Саган) вы соглашаетесь с тем, что не можете постичь вещи, которые абсолютно не похожи ни на что, с чем вы когда-либо сталкивались, тогда как вы могли бы «знать», как использовать что-то, если вы никогда не использовали ничего удаленно подобного?

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

Даже простые вещи, которые кажутся нам интуитивными, совсем не будут интуитивными для людей из других культур. Если кто-то протянул руку перед собой и отмахнулся от руки вверх-вниз на запястье, сохраняя при этом руку неподвижной ... они отказываются от вас? Возможно, если вы не в Японии. Там этот сигнал руки может означать «иди сюда». Так кто же прав? Оба, конечно, в своем собственном контексте. Но если вы путешествуете с обоими, вам нужно знать оба ... дизайн интерфейса.

Я пытаюсь найти вещи, которые уже «знакомы» потенциальным пользователям моего проекта, а затем строю интерфейс вокруг них: ориентированный на пользователя дизайн.

Посмотрите на iPhone от Apple. Даже если вы ненавидите это, вы должны уважать количество мыслей, которые вложили в это. Это идеально? Конечно нет. Со временем воспринимаемая «интуитивность» объекта может расти или даже полностью исчезать.

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

Спросите своего среднего 9 или 10 лет, что они думают, что это. Вы можете быть удивлены тем, как многим детям сейчас трудно будет определить, что это за кинопленка, хотя это то, что до сих пор используется для представления Голливуда, или что-нибудь, связанное с фильмом (фильмом). Большинство фильмов за последние 20 лет были сняты в цифровом формате. А когда в последний раз кто-нибудь из нас держал какой-нибудь фильм, фотографии или фильм?

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

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

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

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

Я знаю, что Microsoft довольно несовместима с их собственными рекомендациями, но я обнаружил, что чтение их руководств по проектированию Windows действительно помогло мне. У меня есть копия на моем сайте здесь , просто прокрутите вниз немного ЗТБВО UX Guide. Это помогло мне с такими вещами, как цвета, интервалы, макеты и многое другое.

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

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

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

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

Поэтому переход из одного мира в другой, безусловно, труден, если переход по умолчанию в одном из них является полной противоположностью другого.

Сказать, что программы отстой в дизайне пользовательского интерфейса, значит упустить смысл. Суть проблемы в том, что формальное обучение, которое получают большинство разработчиков, идет вразрез с технологией. Взаимодействие человека с компьютером - не простая тема. Это не то, что я могу «смешать» с вами, предоставив простое однострочное утверждение, которое заставит вас понять: «О, пользователи будут использовать это приложение более эффективно, если я сделаю x вместо y».

Это потому, что вам не хватает одной части дизайна пользовательского интерфейса. Человеческий мозг. Чтобы понять, как спроектировать пользовательский интерфейс, вы должны понять, как человеческий разум взаимодействует с оборудованием. В Университете Миннесоты я прошел отличный курс по этой теме, преподаваемый профессором психологии. Он называется «Взаимодействие человека с машиной». Это описывает многие из причин, почему дизайн пользовательского интерфейса настолько сложен.

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

Кроме того, есть две части дизайна пользовательского интерфейса, которые многие люди пропускают. Существует эстетическая привлекательность и функциональный рабочий процесс. Если вы пойдете на 100% эстетическую привлекательность, наверняка люди будут, но ваш продукт. Я очень сомневаюсь, что эстетика когда-либо уменьшит разочарование пользователей.

Есть несколько хороших книг на эту тему и курс (например, « Зарисовка пользовательского опыта» Билла Бакстона и « Познание в дикой природе » Эдвина Хатчинса). Во многих университетах существуют программы по взаимодействию человека с компьютером.

Общий ответ на этот вопрос, однако, заключается в том, как людей учат информатике. Все это основано на математике, логике и не основано на опыте пользователя. Чтобы получить это, вам нужно больше, чем общая 4-летняя степень по компьютерным наукам (если только ваша 4-летняя степень по компьютерным наукам не была небольшой по психологии и не была подчеркнута в области взаимодействия человека с компьютером).

Давайте перевернем ваш вопрос -

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

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

Мнение Алана Купера «Заключенные бегут в убежище» заключается в том, что мы не можем успешно использовать обе перспективы - мы можем научиться правильно носить одну шляпу, но мы не можем просто поменять шляпу.

Я думаю, потому что хороший интерфейс не логичен. Хороший интерфейс интуитивно понятен.

Разработчики программного обеспечения обычно делают плохо на «интуитивном»

Полезное создание - активно рассматривать то, что вы делаете, как разработку процесса общения. В реальном смысле ваш интерфейс - это язык, который пользователь должен использовать, чтобы сообщать компьютеру, что делать. Это приводит к рассмотрению ряда моментов:

1. Пользователь уже говорит на этом языке? Использование уникального интерфейса похоже на общение на языке, на котором вы раньше не говорили. Так что, если ваш интерфейс вообще должен быть своеобразным, ему лучше всего представиться с простейшими терминами и с небольшим количеством отвлекающих факторов. С другой стороны, если ваш интерфейс использует идиомы, к которым привык пользователь, они получат уверенность с самого начала.
2. Врагом общения является шум. Слуховой шум мешает разговорной речи; визуальный шум мешает визуальной коммуникации. Чем больше шума вы можете вырезать из своего интерфейса, тем легче будет с ним общаться.
3. Как и в человеческом разговоре, часто это не то, что вы говорите, а то, как вы это говорите. То, как общается большинство программ, грубо до такой степени, что если бы это был человек, его ударили бы по лицу. Как бы вы себя чувствовали, если бы вы задали кому-то вопрос, и он сидел там и смотрел на вас несколько минут, отказываясь отвечать каким-либо другим образом, прежде чем ответить? Многие элементы интерфейса, такие как индикаторы выполнения и автоматический выбор фокуса, имеют фундаментальную функцию вежливости. Спросите себя, как вы можете сделать день пользователя немного более приятным.

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

Хороших комментариев уже много, поэтому я не уверен, что могу что-то добавить. Но все равно...

• Зачем разработчику ожидать, что он сможет разработать хороший интерфейс?
• Как много он прошел в этой области?
• Сколько книг он прочитал?
• Сколько вещей он придумал за сколько лет?
• Была ли у него возможность увидеть реакцию своих пользователей?

Мы не ожидаем, что случайный «Джо сантехник» сможет написать хороший код. Так почему же мы ожидаем, что случайный «Джо программист» разработает хороший интерфейс?

Эмпатия помогает. Разделение дизайна пользовательского интерфейса и программирования помогает. Юзабилити-тестирование помогает.

Но дизайн пользовательского интерфейса - это ремесло, которое нужно изучать и практиковать, как и любое другое.

Разработчики не (обязательно) хороши в дизайне пользовательского интерфейса по той же причине, по которой они (обязательно) не хороши в вязании; это тяжело, это требует практики, и не повредит, когда кто-то покажет вам, как это сделать.

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

Чтобы улучшить, просто посмотрите на существующие сайты. В дополнение к уже предложенным книгам, вы могли бы взглянуть на превосходную книгу Робина Уильямса «Книга дизайна не для дизайнеров» ( продезинфицированная ссылка Amazon )

Взгляните на то, что возможно в визуальном дизайне, и взгляните на различные материалы в The Zen Garden .

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

Но, по крайней мере, мы можем посмеяться над их попытками . Кстати, спасибо OK / Cancel за забавный комикс и спасибо Джоэлю за то, что он помещен в вашу книгу «Лучшее программное обеспечение, которое я пишу» ( продезинфицированная ссылка на Amazon ).

Пользовательский интерфейс не то, что может быть применено после факта, как тонкий слой краски. Это то, что должно быть там с самого начала и основано на реальных исследованиях. Конечно, есть множество исследований юзабилити. Оно должно быть не просто на начальном этапе, оно должно составлять ядро ​​самой причины, по которой вы делаете программное обеспечение в первую очередь: в мире есть некоторый пробел, некоторая проблема, и ее необходимо устранить. более удобный и эффективный.

Программное обеспечение не существует ради него самого. Причина существования программного обеспечения - ДЛЯ ЛЮДЕЙ. Абсолютно нелепо даже пытаться придумать идею для новой части программного обеспечения, не понимая, зачем это кому-то нужно. И все же это происходит постоянно.

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

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

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

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

Уловка с символами состоит в том, что должна быть четкая связь между символом и тем, что он представляет. То, что он представляет, должно быть существительным, и в этом случае символ должен ОЧЕНЬ сильно походить на то, что он представляет. Если символ представляет более абстрактное понятие, это должно быть объяснено в ADVANCE. Посмотрите непостижимые значки без надписей на панели инструментов msword или photoshop и абстрактные концепции, которые они представляют. Нужно учиться, что значок инструмента обрезки в фотошопе означает CROP TOOL. нужно понимать, что вообще значит CROP. Это необходимые условия для правильного использования этого программного обеспечения. Что поднимает важный момент, остерегайтесь предполагаемых знаний.

Мы получаем способность понимать карты только в возрасте около 4 лет. Мне кажется, я где-то читал, что шимпанзе получают способность понимать карты в возрасте от 6 до 7 лет.

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

Есть много книг. Два, которые я прочитал, и поэтому могу рекомендовать, это «Дизайн повседневных вещей» Дональда Нормана и «Человеческий интерфейс» Джефа Раскина.

Я также рекомендую курс по психологии. «Дизайн вещей каждого дня» немного говорит об этом. Многие интерфейсы ломаются из-за «народного понимания» психологии разработчиком. Это похоже на «народную физику». Движущийся объект остается в движении, не имеет никакого смысла для большинства людей. «Вы должны продолжать толкать его, чтобы держать его в движении!» думает физика новичок. Пользовательское тестирование не имеет смысла для большинства разработчиков. «Вы можете просто спросить пользователей, чего они хотят, и этого должно быть достаточно!» думает начинающая психология.

Я рекомендую документальную серию PBS «Обнаружение психологии», которую ведет Филипп Зимбардо. В противном случае попробуйте найти хороший учебник по физике. Дорогой вид. Не чушь самопомощи, которую вы можете найти в Borders, а плотный переплет, который вы можете найти только в университетской библиотеке. Это необходимая основа. Вы можете сделать хороший дизайн без него, но у вас будет только интуитивное понимание того, что происходит. Чтение некоторых хороших книг даст вам хорошую перспективу.

Если бы вы прочитали книгу «Почему программное обеспечение отстой», вы бы увидели ответ Платта, который прост:

1. Разработчики предпочитают контролировать удобство использования
2. Средние люди предпочитают удобство управления, а не контроль

Но еще один другой ответ на ваш вопрос: «Почему стоматология так трудна для некоторых разработчиков?» - Дизайн интерфейса лучше всего делать дизайнером интерфейса.

http://dotmad.net/blog/2007/11/david-platt-on-why-software-sucks/