#uxui #проектирование #системныйанализ #системныйаналитик #мойопыт #капитанНЕочевидность #моемнение
Я очень рада, что эволюция команд разработки пришла к выводу, что команде нужен аналитик, и не любой член команды может быть аналитиком, но и кроме классического набора специалистов, команде нужен специалист по UX/UI.
А что нужно знать и уметь аналитику при соприкосновение со специалистом по UX/UI?
Итак, попробую составить список:
👉1. Понимать, что такое UI kit. Уметь его читать и работать с ним. Чтобы набор элементов интерфейсов был у всех единый.
👉2. Разбираться, и я бы даже сказала, что вытаскивать из front разработки архитектуру построения веб-интерфейса. Если у вас несколько окон, важно понять, чтобы переключаясь между окнами пользователь видел элементы управления на одних и тех же местах. А вы понимали, где что можно менять и располагать.
👉3. В одной из команд у нас был фреймворк front разработки. И это наше ограничение и инструмент. Поэтому аналитику нужно было понимать, что его фантазия и фантазия проектировщика ux/ui ограничена строгим набором элементов и их сочетанием.
👉4. У многих аналитиков проблема в том, что они не знают основные элементы веб-интерфейсов. Какой элемент, как работает, как называется. Стоит записывать названия за разрабами и проектировщиками, изучать, запоминать. А то начинается радиобаттон, становится чек боксом...
👉5. Не знаю как назвать, скажу что- веяние моды - и наверное виток развитие дизайна, это то что многие свои интерфейсы делают под гугл. И бывает бесполезно просить дизайнеров убирать серый цвет, потому что гугл всё делает именно так)))
👉6. Насмотренность. Смотрите как работают ваши конкуренты. Замечаете Паттерны в тех интерфейса, где вы, как пользователь, достигаете своей цели без эмоционных взрывов))) Если вы делаете ERP систему, посмотрите SAP, 1C, презентации разных систем.
👉7. Портрет пользователя (многие о нем забывают), можно найти в фотобанке или в справочнике сотрудников)))) тоже хорошо работает, когда говоришь, кто наш пользователь. Как ux/ui специалисту, так и команде разработки.
👉8. Без сценариев поведения пользователя в интерфейсе никуда))) тут конечно здорово проводить тестирование интерфейса и наблюдать за поведением реальных пользователей, очень прочищает мозги, когда видишь, что пользователь ведет себя не так, как ты думал и проектировал))
👉9. Знать названия, или в идеале уметь работать в самых распространенных приложениях моделирования, в которых работают проектировщики интерфейсов. Но на практике хватает visio, balsamiq, draw.io, axure. Рисовать кликабельные интерфейсы это уже топ. Я бы за рамками оставила.
👉10. Создавать макеты веб-интерфейса, как способ выявления требований. Тут очень аккуратно нужно быть, чтобы потом пользователь понимал, что это не 100% результат, или если интерфейс кликабельный, что это не равно рабочий интерфейс. И да, иногда макетом можно себя подписать под жёсткую разработку, если мы говорим, например, про госы.
👉11. И без мобильного приложения сейчас никуда. Так что стоит понимать как работает Android, IOS, как работает пользователь в том или другом интерфейсе. Аналитик у нас как-то спас команду, когда нарисовал диаграмму User Flow, показывая переходы по экранам мобилки. Я когда-то работала в приложение marvel, и переводила фоточки от руки нарисованных макетов в кликабельный интерфейс мобилки. Занимательно)
В заключение хочу сказать, что проектировщики ux/ui тоже выполняют часть анализа и очень круто, если в вашей команде есть такой человек)
Я очень рада, что эволюция команд разработки пришла к выводу, что команде нужен аналитик, и не любой член команды может быть аналитиком, но и кроме классического набора специалистов, команде нужен специалист по UX/UI.
А что нужно знать и уметь аналитику при соприкосновение со специалистом по UX/UI?
Итак, попробую составить список:
👉1. Понимать, что такое UI kit. Уметь его читать и работать с ним. Чтобы набор элементов интерфейсов был у всех единый.
👉2. Разбираться, и я бы даже сказала, что вытаскивать из front разработки архитектуру построения веб-интерфейса. Если у вас несколько окон, важно понять, чтобы переключаясь между окнами пользователь видел элементы управления на одних и тех же местах. А вы понимали, где что можно менять и располагать.
👉3. В одной из команд у нас был фреймворк front разработки. И это наше ограничение и инструмент. Поэтому аналитику нужно было понимать, что его фантазия и фантазия проектировщика ux/ui ограничена строгим набором элементов и их сочетанием.
👉4. У многих аналитиков проблема в том, что они не знают основные элементы веб-интерфейсов. Какой элемент, как работает, как называется. Стоит записывать названия за разрабами и проектировщиками, изучать, запоминать. А то начинается радиобаттон, становится чек боксом...
👉5. Не знаю как назвать, скажу что- веяние моды - и наверное виток развитие дизайна, это то что многие свои интерфейсы делают под гугл. И бывает бесполезно просить дизайнеров убирать серый цвет, потому что гугл всё делает именно так)))
👉6. Насмотренность. Смотрите как работают ваши конкуренты. Замечаете Паттерны в тех интерфейса, где вы, как пользователь, достигаете своей цели без эмоционных взрывов))) Если вы делаете ERP систему, посмотрите SAP, 1C, презентации разных систем.
👉7. Портрет пользователя (многие о нем забывают), можно найти в фотобанке или в справочнике сотрудников)))) тоже хорошо работает, когда говоришь, кто наш пользователь. Как ux/ui специалисту, так и команде разработки.
👉8. Без сценариев поведения пользователя в интерфейсе никуда))) тут конечно здорово проводить тестирование интерфейса и наблюдать за поведением реальных пользователей, очень прочищает мозги, когда видишь, что пользователь ведет себя не так, как ты думал и проектировал))
👉9. Знать названия, или в идеале уметь работать в самых распространенных приложениях моделирования, в которых работают проектировщики интерфейсов. Но на практике хватает visio, balsamiq, draw.io, axure. Рисовать кликабельные интерфейсы это уже топ. Я бы за рамками оставила.
👉10. Создавать макеты веб-интерфейса, как способ выявления требований. Тут очень аккуратно нужно быть, чтобы потом пользователь понимал, что это не 100% результат, или если интерфейс кликабельный, что это не равно рабочий интерфейс. И да, иногда макетом можно себя подписать под жёсткую разработку, если мы говорим, например, про госы.
👉11. И без мобильного приложения сейчас никуда. Так что стоит понимать как работает Android, IOS, как работает пользователь в том или другом интерфейсе. Аналитик у нас как-то спас команду, когда нарисовал диаграмму User Flow, показывая переходы по экранам мобилки. Я когда-то работала в приложение marvel, и переводила фоточки от руки нарисованных макетов в кликабельный интерфейс мобилки. Занимательно)
В заключение хочу сказать, что проектировщики ux/ui тоже выполняют часть анализа и очень круто, если в вашей команде есть такой человек)