22:00 Базовая теория 29:03 Ссылка на реальный пример исследования для вкусвилла 29:51 Подготовка к интервью 31:08 Подготовка гипотез 38:44 практика до 56:55 57:08 подготовка критериев к респондентам 1:02:15 пример описания пользователей 1:03:22 практика до 1:17:47 1:17:52 где искать респондентов 1:19:29 подготовка гайда (вопросы) 1:21:46 как превращать гипотезы в вопросы 1:31:12 принципы задавания вопросов 1:38:46 практика до 2:05:21 2:05:31 Проведение интервью 2:09:08 с чего начинать 2:11:59 как копать в глубину 2:17:30 МК по проведению глубинного интервью до 2:36:52 заметки с этого интервью 2:38:08 вопросы по МК по интервью до 2:44:12 2:45:02 пример кластеризации заметок с интервью до 2:45:54 2:45:54 вопросы советы, опыт до 3:15:09 3:15:09 Анализ и синтез 3:20:31 ссылка на примеры 3:20:58 практика
привет! не знаю, где задать этот вопрос, но может кто-то сможет подсказать.. какие информационные системы, сайты требуют улучшения в рамках интерфейса? я буду писать дипломную работу с тематикой человеко-машинный интерфейс. может у вас есть какие-либо мысли на этот счет с конкретными проблемами и примерами? буду очень благодарна за ответ🥹
дизайн до/ после обычно учат показывать на одном слайде :) замучалась мотать туда сюда чтобы сравнить. Встретить такое в лекции по веб-дизайну, который есть весь суть про удобство - парадоксально :)
❤Крутой кейс, крутое повествование и презентация. Почему так мало лайков и нет комментариев? Design Out и Ольга, спасибо большое за такую полезность. Если можно было бы, я бы 10 лайков поставила этому видео💯
Интересная тема, версионирование - это действительно очень важно. Понравилось сравнение с системой версионирования git и стратегиями версионирования, в частности с GitFlow, GithubFlow и GitlabFlow. Круто, что дизайнеры так же как и программисты используют инструменты для контроля версий, так как это сильно улучшает не только их качество работы, но и жизнь программистов. Лайк!
5:50 - "глупые" и "умные" компоненты есть не только в Angular, но и в React и Vue. Суть здесь не в зависимости от базы данных, а в возможности управления своим же состоянием. Глупые компоненты получают состояние извне, а умные могут изменять его самостоятельно, в т.ч. делая запросы к базе данных. Есть нюансы в проведении параллелей между концепциями "умных / глупых" компонентов в разработке и в дизайне. Концепция "глупого" компонента на 8:18 в целом соответствует этой же концепции в разработке, но стоит уточнить, что "глупый" компонент в разработке не содержит никаких состояний. В подобном случае в разработке в компоненте можно задать условие для отображения тех или иных его частей, в зависимости от входящей информации. Что касается концепции "умного" компонента на 8:50 - здесь вовсе нет пересечений с разработкой. Указанные компоненты с конкретной информацией/изображениями могут (и в общих чертах будут) являться глупыми, просто уже будут иметь какую-то конкретную информацию для отображения. То есть на том слайде (8:50) слева - "глупый" компонент до того, как в него пришла информация, а справа - с полученной информацией. Я бы немного переформулировал суть идеи того, что представлено в презентации. Вместо "Тупые и умные компоненты интерфейса" - "Компоненты и их инстансы (instance) в интерфейсах". Но смысл того, как необходимо подходить к разработке дизайна верный - компоненты должны быть продуманы так, чтобы их можно было использовать в разных частях проекта с разными входными данными. При этом должно быть несколько уровней: 1) Общий template (например, вверху header, затем контент, затем footer) - в случае с дизайном в фигме мы не будем делать всю страницу компонентом, но в разработке часто будет именно так, разработчик сделает template, в котором постоянно будет присутствовать один и тот же header и footer, и будет прокидывать в этот template динамичный оснвной контент. 2) Каждая часть общего template также является template, назовем условно section template. (Например, header будет состоять из логотипа, меню и иконки юзера). Здесь уже стоит делать компонент в фигме, внутри которого будут другие компоненты. 3) Каждая часть template из пункта 2 будет являться компонентом. (Например, иконка юзера будет отображать имя и фото юзера, если он выполнил вход на сайт, в противном случае будет отображать только надпись "Войти". То есть у этого компонента будет 2 возможные вариации (или два возможных типа инстанса) - "фото + имя" или надпись "Войти") И теперь, например, разрабатываем дизайн главной страницы в двух вариантах - юзер не вошел на сайт и юзер выполнил вход. И используем здесь тот самый компонент из пункта 3. В этом и будет суть переиспользуемых компонентов - мы не будем делать отдельные компоненты для этих двух случаев, просто используем продуманный существующий компонент, способный отразить нужную нам информацию при любом раскладе. p.s. Лайк за стремление связать дизайнеров и разработчиков. Чаще всего последние не шарят в дизайне, но хотя бы дизайнеры будут понимать, как слелать так, чтобы проект был лучше)
