Как да станеш интеракшън дизайнер?

Преди няколко месеца ми една девойка ми е написала следния въпрос:

Работя в една малка фирма за уеб дизайн и софтуер и съм единственият дизайнер и всъщност се опитвам да се изявявам и като information architect и UX designer. Въведох някои нови методи на работа във фирмата като използването на Visio за wireframing но обмислям и изпробването на Axure. Като цяло обаче смятам да се развивам в UX за софтуер и много ми се иска един ден да работя във фирма като Телерик или друга голяма такава. Имам малко информация обаче относно начина на работа и необходимите умения, а искам да знам на какво да наблегна още от сега тъй като опитът ми е главно в уеб дизайна. Та ще се радвам да споделиш какви точно умения се искат, какви tools използват UX дизайнерите в Телерик (Axure, Epression Blend, трябва ли да знаеш XAML?), и от друга страна дизайнерите на UI (изцяло Illustrator ли се ползва за създаването на дизайна на един интерфейс?)

Ето какво и отговорих:

Привет,
Първо да се извиня, че пиша с два месеца по-късно, но чак сега (случайно) видях това съобщение.

Иначе за туловете – общо взето всеки ползва каквото му е удобно. Сравнително популярно е Axure. Други ползват Expression Blend. На мен ми е най-бързо и лесно да ползвам HTML + jquery (когато е важно да се покаже интерактивност и как се разцъква даден интерфейс) и евентуално Fireworks (когато трябва да се покаже набързо как е подреден даден екран или когато набързо искам да пробвам с различни структури на данните). Та в заключение – няма стандарти. С каквото най-лесно си обясняваш идеите и другите те разбират – това е.

Иначе за умения – графичния дизайн е задължителен. не толкова да можеш сама да правиш, но да знаеш какво е добър дизайн и кои са основните принципи. Също да можеш да пишеш добре и разбираемо – ако можеш в кратък текст да обясниш дадена функционалност (Примерно в текст на бутон или чекбокс да обясниш какво прави съответната функционалност). И другото полезно е да имаш познания по когнитивна психология – как хората възприемат различни неща и как ги интерпретират. И понеже основна част от възприятието ни е визуално тука материята се припокрива с теорията на графичния дизайн. Но въпреки това когнитивната психология ти помага да обясниш защо даден човек би взел дадено решение.

На толкова общ въпрос, такъв общ отговор. Но според мен няма универсално обобщение – трябва ти това и това и вече ставаш. Всичко е до желание, практика и много мислене.

Три извода от events tracking в Google Analytics (втора част)

В поредица от постове разкривам скорошните си наблюдения за начина на ползване на някои интерфейсни компненти от хората.

Хората не разцъкват табове

В стремежа си да сложат възможно най-много съдържание на единица площ, уеб дизайнерите и собствениците на сайтове използват най-разлини подходи. Типични такива са падащите менюта и табовете.

За падащите менюта съм писал преди – не ги харесвам и не ги препоръчвам.

За табовете обаче съм чел само патърни за употреба – как да изглеждат и да се държат, но не и смислена критика дали са ползваеми или не. А винаги ми е било любопитно как се представят в истинския живот.

Важно е да отбележа, че става въпрос за онзи тип табове, които скриват и показват съдържание в малки карета от дадена страница, а не за навигационния тип табове.

На началната страница на сайта (и страницата с най-много посещения изобщо) на едно от най-видимите места има блок с новини, които са групирани в отделни категории. За всяка категория има отделен таб.

Предположението ми беше, че сравнително малък процент от хората ще кликат на табовете. И наистина статистиката показа, че по-малко от 5% от посетителите на началната страница кликат на някои от табовете.
На началната страница на спортната страница има сходен интерфейс и там процентите са 15. Разликата може да се обясни с това, че докато на началната страница хората идват по различни причини и имат много повече опции, то на вътрешната страница вече са доста по-съсредоточени и съдържавнието в табовете всъщност се явява голяма част от смисленото съдържание.

Което е по-интересно е, че общият брой на кликовете върху новините във всички скрити табове е една пета от броя на кликовете върху новините от показания дефолтен таб. Представете си че ако в показания таб хората цъкат на 100 новини, то в останалите 5 таба са цъкнали на общо 20. Показателно за ефективността. От друга страна обаче е по-добре от това да имаме само един таб и вместо 120 да получим само 100 клика.

Изводът е, че ако разчитате, че с помощта на табовете ще успеете да пробутате повече съдържание – не хранете излишни надежди. Полза както се вижда има, но тя е почти маргинална. В конкретния случай загубата на място не е голяма и не пречи (много) на останалата част от съдържанието в страницата. Т.е. хем сме изгубили малко място, хем малко хора кликат, но поне не сме навредили на останалата част от съдържанието.

PS. Тук отново трябва да направя уточнението, че резултатите са за този конкретен дизайн. В друг контекст табовете могат да имат и по-добри резултати.

Три извода от events tracking в Google Analytics (първа част)

От доста време вече в Google Analytics има възможност да се отчитат не само показвания на цели страници, но и отдлени интеракции в самата страница. Например, ако в дадена страница има видео плеър, човек може да следи колко от хората кликат на бутоните за плей, пауза и стоп.

Едва наскоро обаче реших да използвам тая функционалност в реален и сравнително посещаван  сайт (btv.bg), за да проверя с реални данни предположенията си за дизайна.

Как се ползва event tracking

Google Analytics има метод _trackEvent, който може да се вика и му се предават няколко параметъра по този начин:

_trackEvent(category, action, opt_label, opt_value)

Какво означават отделните параметри си пише в документацията на Analytics – супер кратко, ясно и пълно описание на event tracking.

Иначе с jQuery тракера се вика така:

$(document).ready(function(){
  $('#Logo a').click(function(){
    pageTracker._trackEvent("Navigation", "Click Logo",  document.title);
  });
});

Накратко това означава, че когато документът се зареди, javascript почва да следи за всеки клик върху линка и когато иам такъв ивент, записва в Google Analytics.

Резултати за някои интерфейсни елементи

Никой не споделя линкове по имейл

В тествания сайт под всяка новина, видео, анкета и т.н. има по няколко линка за споделяне в социални мрежи от сорта на Facebook, Twitter и т.н. Един от линковете беше „Препрати по имейл”, което означава да изпратиш на някой по имейл линк към съответната новина.

Предположението ми беше, че никой не ползва тази функционалност. И наистина – статистиката показа, че нищожен процент (разбирай хилядни от процента) от хората, които са заредили страница с новината, кликат върху този линк.

В интерес на истината едва два пъти повече хора кликат на линка за споделяне в туитър. Споделянето във Facebook e най-популярната опция, но не си представяйте нещо феноменално като цифри.

Факт е обаче, че ефектът от един линк споделен във Facebook или Twitter е доста по-голям, тъй като всичките познати на човека, споделил линка биха го видели и евентуално кликнали обратно към вашия сайт. Докато при случая със споделянето по имейл единствено получателят на имейла би кликнал и посетил вашия сайт. С други думи – макар и кликовете по линковете за споделяне в социалните мрежи да не привличат кой знае колко повече внимание, ефектът от тях е доста по-голям.

Нещо, което би могло да влияе върху този резултат е начинът, по който е кръстен линка. „Препрати по имейл” е един вариант. По големите български новинарски сайтове най-често се използва или иконка с писмо без допълнитлен текст, или иконка с писмо и текст „Изпрати”, или „Изпрати по e-mail”. В  англоезичните сайтове изглежда има възприет стандарт  – иконка на писмо и текст „E-mail”. На английски обаче “e-mail” може и да е глагол, за който няма превод с една дума на български  – „имейлнѝ”/”имейлване”. Честно казано обаче се съмнявам да има достатъчно добър вариант, който драстично да повиши кликанията върху този тип линкове (остава си добър повод за мултивариантно тестване).

Продължението следва

Цитат на деня: За резултата от работата ни

Мениджмънта на продукта трябва да изясни какъв резултат очаква. Под резултат имам предвид какво се случва след като софтуерът е пуснат на пазара. Каква е ползата за компанията? Кои клиенти и потребители допринасят за тази полза? Какъв според продуктовия мениджър е типът решение, което ще постигне този резултат?

Наскоро се опитвам да проверя думите, които използва един презентатор от Frog, който говори на IxDA 09. Той въведене следния език: продукция (output) – резултат (Outcome) – влияние (impact).

продукция: това е онова, което правим
резултат: това е какво се случва в света след като пуснем нашия продукт
влияние: това е какво се случва по-късно – често много по-късно.

Ние не искаме софтуера (продукцията), а по скоро резултата – печалбата, по-доволните клиенти, клиентите, които се връщат, новите пазара – всички тия неща. В иделания случай ние се стремим към по-дългосрочно влияние съгласувано с визията на нашата организация – да доминираме пазарам или (не казваха ли от гугъл) “не прави зло”. Алп пуснем софтуер, който носи печалба, но вреди на репутацията ни, това би бил добър краткосрочен резултат, но дългосрочното влияние, което ще окаже би било съмнително. Знам една компания, която реши да сложи повече реклама на своя сайт. Това имаше добър кракосрочен резултат (повече печалба). Но след това се замислиха дали това решение няма да окаже негативно влияние върху тяхната марка в дългосрочен план (техните клиенти се оплакват от рекламите).

Резултатът и влиянието са това, което носи стойност на бизнеса. Ако не знаеш какви са желаните резултат и влияние, не знаеш каква е стойността на бизнеса ти. Не правете софтуер преди да сте си изяснили това – освен ако не се забавлявате докато го правите… дори и в този случай “забавление” е вашият целан резултат. ;-)

Собственика на продукта и екипът приоритизират работата съгласно тази логика.

Куул цитат от Джеф Патън в дискусия от Agile Usability групата.

Подобен начин на мислене може да е полезен в опита ни да отучим бизнеса да мисли (в голяма част от времето) от коя страна да е подравнен бутона за вход или коя точно снимка на шефа да избере. Ако този език и особено въпросите, които възникват и се задават успее да навлезе по-нашироко в нашата професия и сред клиентите ни. Ще сме по-ефективни имаме и съответно повод да сме доста по-доволни от работата си.

Семинар по ползваемост, София, април 2008

Днес цял ден бях на семинара, организиран от Лукрат и списанието .net. Дори и презентация направих.

Сутрешната сесия започна Димитър Симов, който е колега от Нетейдж и също основател на Лукрат. Презентацията му беше за това как се пише текст за уеб. Темата по принцип е много важна, защото съдържанието все още е номер 1 най-важно нещо за всеки уеб сайт, а текстовото съдържание е най-често срещаното и ползваното (все още). Основната препоръка на Джими беше да се пише кратко и изчерпателно. Нещо, което е валидно не само за уеб текста и нещо, което успях да се убедя в последната 1 година, докато пишех статиите си за списание .net.  Писането за печатна медия е доста дисциплиниращо, защото имаш ограничние откъм броя символи и трябва внимателно да премислиш какво искаш да кажеш и как да се вместиш в заделеното ти място. Имаше и добри препоръки за имената на линковете – да съдържат само ключовите думи, които характеризират страницата, която отварят. Друга важна точка беше за това, че текстовете не са само примерно съдържание на някоя страница, а въобще всичко, което потребителят чете по екрана – съобщения за грешки и предупреждения, навигация, описания на картинки…

След Джими говори Еленко – пак предимно за писането и по-скоро за създаването на съдържание в Интернет. Основната му теза беше, че всяка единица съдържание (примерно блог пост) трябва да осигурява достатъчно контекст. За да бъдеш полезна част от онлайн средата трябва не само да копираш, но и да оставяш собствената си гледна точка като допринасяш за диалога. Основните му примери бяха свързани с неговия блог и начина, по който той създава съдържанието си. Показа как използва Google Reader и Twitter, за да филтрира информацията и да добавя собствената си гледна точка. Написал е сам някакъв уиджет, в който комбинира фийдовете от двете услуги. Посочи за модерно създаването на съдържание да става в микроформат – например, че микроблог платформи от сорта на Twitter, а дългите постове като изразно средство за по аналитична информация.

Англичанинът Алистър Кембъл говори за достъпността и доколко това, че ако един сайт е достъпен от всякакви хора и устройства, той е и по-ползваем. Интерсното в презентацията му беше представянето на това как различните технологии, които подпомагат хората с физически и психически недостатъци да разглеждат интернет сайтове. Разбира се писането на правилен маркъп спомага точно за този вид употрбеа. Всъщност правилният маркъп е само страничен резултат от това как мислим структурирането на информацията в страниците си. Друго основно правило е отделните страници да са консистентни една с друга особено по отношение на навигацията. Аз лично винаги съм се интересувал повече от достъпността като средство да направиш съдържанието си ползваемо във всякакви устройства, отколкото за всякакви хора, но така или иначе в крайна сметка се постигат и двете.

Хората от НБУ представиха доста накратко изследванията си с проследяване на погледа. Според мен такива изследвания само потвърждават неща, които знаем. Вече са изживяли ролята си като по-смислен инструмент за тестване на ползваемостта и откритията, които са били направени с тяхна цел би трябвало да са част от арсенала на всеки нормален проектант.

Следобедната част започна с моята презентация. Самата презентация вече качих в интернет – в нея са както слайдовете, така и бележките ми към тях, които са 1:1 с това, което говорех. Т.е. се надявам да не липсва видеото, което забравих да запиша. За съжаления не мисля, че се получи нещо смислено. За в бъдеще ще правя само или чисто теоретични презентации, които запознават аудиторията с дадена концепция, или наситена с примери от практиката презентация. Неумелата ми комбинация от двете не се получава добре и по-скоро обърква хората, които за толкова кратко време не могат да разберат добре връзката между теорията и практиката. Струва ми се, че презентациите на добрите лектори, които сме свикнали да гледаме в чужбината са именно в една от двете крайности и затова са доста по-добри.

След мен Питър Мерхолц изнесе презентацията си Subject to Change. Който е чел книгата на Adaptive Path (ревютата в amazon също вършат доста добра работа) и гледал записите от предишните представяния на Питър знаят за какво става въпрос. Накратко – успешните бизнеси в днешно време разглеждат и правят продуктите и услугите си така, че самите продукти като технология и способности остават на заден план, а на преден е изживяването, което предлагат на потребителите. изживявенето е продуктът, който трябва да се проектира. Самото проектиране става при използването на системния подход, който разглежда продукта не само като сбор от неговите фийчъри, а като част от контекста, в който съществува.

По време на видео презентцията на Владо се разсеях. Говореше за това, че тестовете за ползваемост на мобилни приложения са доста по-различни от традиционните и за някакви методи за провеждането им. Освен това говори и за разликата в средата – за разликите в браузърите и в контекста на употреба (десктоп компютри, ползвани в офиса срещу мобилни телефони ползвани навсякъде), които са много важни фактори при проектирането на мобилни приложения.

Красен Хинков от Мтел пък показа някои успешни практики за оформяне на съдържанието в мобилния интернет. Основната му теза беше, че съдържанието трябва да се предлага в компактни модули, които само повърхностно обобщават някаква информация и препращат към страници където съответната функционалност или пълно съдържание е достъпна в целия си блясък. Стратегията на М-тел в тая насока е да предложи на потребителите си възможност за персонализация посредством създаването на лични страници с избрани от всеки потребител модули (уиджети) само с информацията, която интересува дадения човек. Радващото е,ч е спомена спецификацията на W3C уиджети, което за разработчицита на дадена услуга може да означава, че няма да правят кой знае какви усилия, за да създадат собствени уиджети за М-телската платформа, а ще могат да използват работата си за iGoogle или my.yahoo.com например.

Като цяло хубавото на семинара беше, че се получи известно застъпване в темите между отделни презентатори и по този начин се видяха различни гледни точки. Както обсъждахме с един тип от Ruby on Rails общността, обаче, трябват повече събирания на хората, които се интересуват от ползваемостта в България. Явно “релсистите” правят такива събирания регулярно (бях мяркал в юзъргрупата им нещо такова, но не съм ходил, че са малко специфични темите им за разговор). Което ме навжда на мисълта, че както юзабилистите има какво да научат от програмистите, така и обратното. Или най-малкото обмяната на идеиотносно процеса на работа  (дори и на чисто теоретично ниво) няма да навреди.

Още по темата е писано в:

Ползата от персоните

Статия от списание .net

Наскоро из различни блогове се получи една доста интересна и на моменти гореща дискусия относно ползата от използването на персони (от англ. persona) при проектиране на сайтове или продукти. Едната страна в (да го наречем с истинското му име) спора бяха ветераните експерти по ползваемост начело с Доналд Норман, а от другата – феновете на гъвкавите техники за разработка в лицето на пичовете от 37signals. 

Под персони в нашия случай се разбира измислени хора, които представляват група от потребителите на проектирания сайт или продукт. Колегата Димитър Симов – Джими превежда термина с думата „образ” именно защото персоната е обобщен образ с най-характерните черти на хората, които са част от някоя от нашите целеви групи. И както можем да имаме различни аудитории, така и персоните могат да бъдат различни. За един сайт на университет например, можем да имаме няколко персони – на кандидат-студентът, завършващ тази година гимназия, на третокурсника или на някой одъртял професор. Всеки един от тях има различни нужди и опит и съответно ще използва по различен начин сайта.

Персоните се използват по време на процеса на проектиране, за да подпомогнат дизайнерите във взимането на конкретни решения относно това как да бъде реализирана една или друга функционалност. „Какво би направил Гошо?” е въпросът, на който хората от екипа могат доста по-лесно да отговорят, когато знаят, че Гошо, за да продължим предния пример, е мързелив и не много умен студент, който основно се интересува от датите за поправителните изпити и вместо да работи с компютър предпочита да жули кафенца с колежки. С други думи абстрактните данни за потребителите ни „оживяват” и добиват доста по-конкретно изражение в лицето на един човек (макар и измислен), който можем да си представим и да преценим как би постъпил в дадена ситуация.

Та Доналд Норман и 37signals се скараха за това, че според вторите персоните са инструмент, за който дизайнерите само си губят времето. И наистина – в доста случаи персоните се описват в специални документи просто, защото така повелява процеса на работа и в края на краищата си остават едно абстрактно, измислено и изкуствено описание на аудиторията. „Да вземеш решения, основаващи се на истински мнения е по-добре, отколкото да взимаш решения, основаващи се на измислени мнения” – казват те. И донякъде са прави.

За мен обаче ценното в персоните е именно това, че кара дизайнерите да се замислят върху проблемите, които решават и да ги погледнат от друг ъгъл. През очите на потребителите. Защото колкото и естествено да звучи, малко дизайнери го правят и вместо това налагат собствените си виждания, вземат решения, базирайки се на собствения си опит. А това има лош резултат, защото рядко си приличаме с хората, за които проектираме. Колко дизайнери професори в университет познаваш?

За ролята на клиента в един софтуерен проект

Tru цитата, които ми харесаха от последните два дни:

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

От поста Серые будни: продавая Rails клиентам в Less is more.

и

I’ve written previously about using an envisaging team to scout out ahead. Not to design the solution but to understand the problem space – understand what the business needs, what users need, who the users are and what the technology ecosystem looks like – and report this back in a coherent fashion to the rest of the team. This isn’t Big Design Up Front by another name. The envisaging team’s work should be limited to discovery work only. This combined with regular rounds of user testing between each iteration – the results of which are fed into the next round of development – can mean that agile software development can be highly user focused.

От поста Making Agile User Centered в Derivadow.

Още: 

Обаче човекът, който си общува с клиента реално най-добре разбира какви точно са целите и какво е най-добре за проекта. Което естествено води до това да визуализира и проектира решението, което да бъде изработено. В състояние ли е мениджър без технически background да го направи? Като участник в проектите винаги съм се чувствал като “сляпа баба”, ако не мога да лесно поговоря пряко с клиента, да чуя изискванията от първа ръка, да разгледаме подробно болките му, и дори да предложим решение, различно от първоначалното.  

От поста Без “мениджър” в 3atwork.com

Ако някой не се оправя с превода – да свирка.

links for 2007-04-05

Връзка: Garrett Dimon / Documenting Interface Design

Garrett Dimon пише за документирането на интерфейс дизайна. Идеята му е, че стандартната документация, която познаваме и ползваме е безполезна и неизползваема. Решението му се състои в това да се проектират отделни модули (тухли) от функционалността и интерфейса, които после могат да бъдат описани на една страница. Ако описанието е по-дълго, значи са прекалено сложни и трябва да бъдат разбити на по-малки блокчета. Надявам се коментарът, който оставих под поста да бъде одобрен, защото там споделям една практика, която използвам отскоро за докумнетиране на interaction design-а.

Софтуерните разработчици са като колите

В една презентацията на същия Кен Швабър, за който писах преди известно време, той прави едно много интересно сравнение в контекста на това кой е отговорен за един софтуерен проект.

Швабър сравнява софтуерните фирми с коли, а клиентите с шофьорите на тези коли. Шофьорът кара колата там където иска да бъде. Шофьорът избира с каква кола да пътува – бърза, луксозна, с нисък разход, малка, голяма. Шофьорът сам решава как предпочита да стигне до крайната цел.

Може би защото доскоро бях на вълна купуване на автомобил и сега такова едно сравнение ми се струва удачно. Клиентите наистина подхождат към избора на софтуерен разработчик като избор на кола. Можеш да избереш доказаната марка (дори на старо) и да платиш повече, но със сиурност да стигнеш където искаш без да си се разбил от път. Или пък да избереш евтино ново, лъскаво возило, но пътуването ти да не е нито най-приятното, нито най-бързото.

Цялата презентация е много интересна също така, макар до известна степен да повтаря предишната, за която писах.