vapa

Нейронная сеть, грубо говоря, есть имитация процессов в нашем мозге, адаптирующаяся к новым условиям. Полагаю, про это вы знаете. Собственно, из-за стремления разработчиков максимально приблизить нейронки к нашему, человеческому, мозгу, ее и называют нейронной.
Искуственный интеллект, как правильно выразился один из ответивших, есть имитация мышления, но это не значит, что она должна использовать нейронные сети в своей основе. ИИ, в идеале- искусственный разум, способный АБСОЛЮТНО самостоятельно принимать решения, осмысленно отвечать на вопросы. Но, поскольку человек еще не достаточно изучил даже свой мозг, возникает размытость в том, что, собственно, должен делать ИИ.
Машинное обучение - процесс самостоятельного обучения нейронной сети. Для обучения используются многие методы, например, обратного распространения, который находит разницу между ожидаемым ответом и выходным, производит с получившимся числом манипуляции и корректирует весовые коэффициенты, передавая их дальше, к началу.
Глубинное обучение - общее название обучения сети с нуля "понимать" что-либо и извлекать полезные данные для дальнейшего обучения.
Надеюсь, дал исчерпывающий ответ)

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

Зарубежные ресурсы по UX
uxmatters.com
uxdesign.cc
uxplanet.org
mashable.com/category/ux/
uxmag.com
uxbooth.com
https://www.nngroup.com/articles/
https://www.nickkolenda.com/blog/
smashingmagazine.com/category/ux-design

Русские ресурсы по UX
https://ux.pub
https://ux-journal.ru

Существует. Есть же такие позиции, как "UX Researcher", "UX Analyst". Да, обычно это достаточно крупные проекты, которые пришли к пониманию необходимости вовлечения в процесс такого чистого специалиста. но у него, помимо, UX, конечно, должны быть некоторые компетенции из смежных областей. Бывают заказы на юзабилити-аналитику. Иногда попадаются на "МоемКруге". Конкретные ссылки не смогу сейчас скинуть.

Быстрый гуглеж дал вот это https://habr.com/post/323156/
В моем опыте, даже фронты не занимались прототипированием, не говоря уже о фул-стек разработчиках. Этим занимались дизайнеры, именно для них есть Figma, Invisionapp, Ninjamock, Adobe XD
И да, если дизайнер умеет отдать макет в Avocode, Zeplin, Adobe Extract ну или опубликовать спецификации в Adobe XD https://helpx.adobe.com/xd/help/share-embed-design... разработка сокращается в половину

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

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

Возможно, но очень непросто.

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

Опровержение мифа - дело неблагодарное и чаще всего бесполезное

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

Ваш единственный маркер в такого рода вещах - A/B тестирование
И его результаты вам могут сильно не понравится
Также не стоит идти против течения, если у вас нет чуйки в данной области

Если тестовое задание занимает больше одного дня (4 часа), то даже рассматривать нет смысла. Не лишним будет уточнить, чем их не устраивает ваше портфолио.

Не совсем понятен вопрос. Google docs, или что-то вроде этого?

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

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

Если верстальщик отказывается верстать с Adobe XD или Figma - он не стремится вперед, так как за этими инструментами будущие, и оно не за горами.

Рекомендую пройти доступный и основанный на практической работе онлайн курс по UX-проектированиюот Александры Постоваловы, в фейсбуке у нее есть страница.
https://www.facebook.com/alexandra.postovalova

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

UX/UI – не sketch или figma. Это совокупность знаний из разных отраслей — технической, творческой + психология. Это большой объем знаний и умений.
Учите html/css/js (базовые понятия), читайте все что возможно по типографике (это основной пункт для дизайнеров), колористике, композиции, читайте исследования по UX (их масса, есть большие труды, но в основном англоязычные, начните с Купера, как вариант). И в процессе всего этого практика, практика, практика. Потому что, к сожалению, без нее никуда. Вы будете круты настолько — сколько кейсов запилите. Успехов!

Да, такое делали. Пришло просто как обновление.

а что лучше, дрель или лопата? думаю, зависит от целей.
Хотя на самом деле в 99,(9)% случаев адаптип лучше мобильной версии.

- адаптива

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

+ адаптива

• относительная дешевизна (работаем над одной версией, а не над двумя)
  
• удобство разработки (по той же причине)
  
• один урл, а это (не только 2 кг ценного мяса):
  

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

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

Заказчик хочет чтобы разработчик сделал сложное приложение.

Причина 1: обычно заказчик хочет, но не знает чего конкретно. Фишка в том, что разработка приложения, у которого ещё нет аналога - это... не только разработка приложения. Это ещё и выяснение того, что действительно нужно, начиная с пожеланий по UX, и заканчивая оптимизацией бизнес-процессов во всей компании (это когда заказчик внезапно говорит "слушайте, и правда, на кой чёрт мы печатаем эту накладную каждый раз").

КПД получается крайне низок.

Причина 2: вы не учитываете причину 1 при расчёте КПД и думаете, что проделали мало работы. Да, приложение ещё не готово или делается очень долго, но это не потому что вы мало работаете, а потому что работы намного больше, чем казалось.

но идёт на удаление или переделку из-за того, что что-то не так.

Причина/особенность 3: иногда это неизбежно: бизнес меняется, потребности - тоже.
Иногда этого можно избежать, не заводя требования слишком "далеко" - очевидно, нет смысла реализовывать то, что УЖЕ СЕЙЧАС кажется неподходящим под требования, НО это далеко не всегда вовремя замечают. Над проектом работает много людей, у всех немного разные представления о задаче, или ещё хуже: не все и далеко не всегда говорят о проблемах с системой, которые уже виднеются "на горизонте", говоря что "в ТЗ всё написано, а мы делаем по ТЗ". Можете погуглить статьи о стоимости ошибок на разных этапах разработки.

Причина 4: заказчик, разработчики или и те и другие не умеют останавливаться и выбирать необходимый и достаточный функционал для первого или очередного релиза. Я в последнее время убеждаюсь, что это целая наука - вовремя остановиться и не расширять список "супернужных" фич, из которых треть окажется почти невостребованными. Особенно часто это бывает, когда бизнес уже работает как-нибудь (например, на экселевских табличках или Access-овских базах), а теперь пришла пора автоматизации, но релиз постоянно откладывается, потому что "и это хочется, и то бы сразу сделать". Иными словами, иногда нужно решиться на гарантированные переделки в будущем ради релиза сейчас. Оценка возможности и стоимости таких "переделок" - т.е. подождать и переделать сейчас или зарелизиться и переделать потом (соответственно, с удорожанием "переделок") - и есть та самая наука. Разработчик обычно видит только архитектуру, и раньше понимает её недостатки/ограничения, ему сложно решиться на релиз того, что не будет идеально решать поставленную задачу.