+
Вход

Въведи своя e-mail и парола за вход, ако вече имаш създаден профил в DEV.BG/Jobs

Забравена парола?
+
Създай своя профил в DEV.BG/Jobs

За да потвърдите, че не сте робот, моля отговорете на въпроса, като попълните празното поле:

68-35 =
+
Забравена парола

Въведи своя e-mail и ще ти изпратим твоята парола

Как се прави дизайн за стартъп клиент: Няколко съвета как да се справим с усещането за несигурност

*Текстът е предоставен от Devexperts

Казвам се Наталия Илина и съм UX дизайнер във финтех компанията Devexperts.

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

Защо харесваме стартъпите

Сред IT общността съществува едно упорито и романтично виждане за прохождащите компании като възможност да бъдеш част от вълнуващ проект, където малък екип създава нещо от нулата. Нещо, което не е съществувало преди това и вероятно има огромен потенциал за развитие. Както повечето от вас може би знаят, статистиката показва, че всеки 9 от 10 прохождащи компании се провалят. В същото време обаче можем да видим, че в САЩ през 2022 година е имало 33.2 милиона стартъпа, което е увеличение със 700 000 спрямо 2021 година.

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

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

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

Когато очакванията се сблъскат с реалността

Преди две години получих покана да се присъединя като UX дизайнер към проект за клиент-стартъп, който се занимаваше с финтех медийни услуги, базирани на блокчейн технология. Преди това се занимавах със средни и големи финтех проекти, където всичко беше вече уредено. Отговорностите бяха ясно определени и разпределени между членовете на екипа, изискванията бяха ясни и работните графици бяха планирани предварително, понякога за шест месеца напред. Често отнемаше цял месец и дори повече, за да може функцията на даден бутон от потребителския интерфейс да премине през фазата на разработване. Честно казано, цялото нещо ми се струваше доста монотонно и предсказуемо. Ето защо с радост приех поканата.

Първоначално визията ми беше ясна: ще изградя чисто нова система за дизайн от нулата. Целта ми беше да създам чисто нов работен поток и да разчитам на безценната помощ на екипа си при взимането на решения за дизайна. Изглеждаше като фасулска работа.

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

Пътят от първоначалната скица на модел телефон до пускането му на пазара и последващите подобрения е дълъг и труден. И все още вървя по него.

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

Съвет #1: Мислете за компонентите стратегически

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

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

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

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

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

Точно в този проект бях на 99% сигурна, че тези промени ще се случат. Обикновено работя по този начин, за да предвидя проблеми, които евентуално могат да възникнат по-късно. Полезността и гъвкавостта на компонентите за мен са с приоритет. Вероятно ще ме попитате: „Ама ти сериозно ли? Да не би да можеш да виждаш в бъдещето?“ Не съвсем, но ще обясня какво имам предвид.

Ако имах например панел с данни, които трябва да преработя за по-малък прозорец, да кажем мобилно устройство, се питам: „Този компонент ще бъде ли полезен и приложим другаде в приложението? Мога ли да го направя малко по-неспецифичен и лесно да интегрирам нови елементи и контролери?“ Мисля си как би могъл лесно да се промени изгледа на този компонент. Анализирам пропорциите му, за да се уверя, че повечето видове съдържание се вписват в него и че този компонент е достъпен за различни видове потребители, наред с други съображения.

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

Освен това този подход с използването на един разширен компонент за логически подобни или потенциално подобни типове данни също допринася и за процеса на разработка, а първоначално създадените компоненти изискваха само малко рефакторинг, тъй като все още работеха добре с новите изисквания. Този метод ни позволи да постигнем целите си за рефакторинг в рамките на доста кратък период от време.

Съвет #2: Научете се как да представяте идеите си
Днес те питаме…

Kаква нетна месечна заплата получаваш в IT сектора?
Loading ... Loading …

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

Трябваше да бъда убедителна и да правя впечатляващи презентации по време на ежеседмичните ни срещи с клиента. Трябваше да се вслушвам внимателно в обратната връзка и да я вземам предвид, за да подобря дизайните си.

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

Съвет #3: Общувайте

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

Получавах някои нетипични въпроси за дизайнер на потребителски интерфейс от страна на разработчиците. Питаха ме например какво е ограничението на знаците за потребителските имена, каква е минималната разделителна способност на умалената версия на изображението, кога да се показва умалена версия за видео файл и как работи обработването на плащанията. Първата мисъл, която ми идваше наум, беше: „Хора, не знам.“ Но в определен момент осъзнах, че задължително трябва да разбирам архитектурата на приложението и да бъда информирана за повечето технически нюанси. Трябваше да отговарям на повечето въпроси, с изключение на много специфични теми в областта на разработването на приложения, които вече бяха наистина извън моята област на експертиза.

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

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

Съвет #4: Тествайте сами и проверявайте използваемостта на продукта

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

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

Друго нещо, което си струва да се спомене тук, е проучването на потребителите и тестването – или поне тестването на използваемостта. Разбрах, че колкото по-рано започна да тествам хипотезата си, толкова по-малко промени и рефакторинг ще трябва да се правят в процеса на разработка.

Бяхме на път да пуснем напълно нов продукт на пазара и не бяхме направили никакви проучвания, което беше сериозен пропуск от наша страна. Екипът ми беше игнорирал тази важна част от разработката твърде дълго заради липса на време, поради предоверяване на авторитета на клиент, който уж знаеше по-добре от всеки друг какво иска и от какво има нужда, както и поради отсъствието на членове на екипа. Дадохме всичко от себе си в рамките на даденото ни време за работа.

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

Моите поуки

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

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

Струва ли си?

Аз съм свидетел от първа ръка на бързите темпове и променливата среда, присъщи на повечето клиенти-стартъпи. Това, което е било актуално вчера, може да е остаряло до момента, в който алармата ви събуди на следващата сутрин. Процесът на разработка е толкова бърз, че понякога не успявах да предложа по-прецизно решение. Това е един непрекъснат процес на генериране на идеи. Понякога няма време за провеждане на коректно A/B тестване на прототипи и функциите трябва да бъдат пуснати възможно най-скоро. Налага се да работите повече от обичайните осем часа на ден. Няма незабавна обратна връзка, която да покаже дали хипотезата ви е правилна или не.

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

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