ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ
Upcoming SlideShare
Loading in...5
×
 

ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ

on

  • 826 views

Подборка постов для мобильных разработчиков

Подборка постов для мобильных разработчиков

Statistics

Views

Total Views
826
Views on SlideShare
826
Embed Views
0

Actions

Likes
2
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ Document Transcript

  • ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ:Flurry в ноябре прошлого года проанализировало аппы и вывела а-ляматрицу BCG для мобильных приложенийhttp://blog.flurry.com/bid/95072/Black-Holes-and-Superstars-in-the-App-UniverseДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ:За последнее время, по ощущениям, Apple несколько ужесточилиreview процесс (ну или поменяли внутренние инструкции и чеклист),поэтому делимся 3 топ проблемами за несколько последних ревьюApp in the Air: Explore Airports, In Flow - Explore your happiness иAirport Guru:1) In-app purchase - несколько раз нас задвинули с необходимостьюрегистрации (хотя бы iCloud) в приложении для "Subscriptions" типови restore функции для non-consumable инаппов2) Неправильное использование лого Apple - не забывайте проmarketing & advertising guidelines for developers:https://developer.apple.com/appstore/resources/marketing/index.html3) Side библиотеки - будьте внимательны к библиотекам, которыеиспользуют приватные APIНу и остальное смотрим тут:http://insights.empatika.com/blog/2013/02/21/for-mobile-developers-how-to-succeed-review-of-your-app-by-appstore/
  • ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ:Многие спрашивали у нас наши презентации с курсов по Androidразработке - Ilya Zorin вот выложил. Enjoy! :)http://www.slideshare.net/BayramAnnakov/android-hse-lecture1
  • ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ:Ситуация:Мониторя DAU (daily active users), вы отмечаете заметное снижениеактивности ваших пользователей. Исследуя ситуации и причины,приходите к выводу, что в вашем приложении перестали приходитьпуши и поэтому юзеры реже стали открывать приложения. Дляотправки пушей вы пользуетесь сервисом Parse (http://parse.com/). Выресерчите немного, вроде проблема не в Parse. Недавно в другомприложении была аналогичная проблема и там дело было всертификатах. Да и на stackoverflow-подобных сервисах пишут обэтом. Вы издаете новый сертификат, выпускаете внутренний билд,тестируете... а пуши все равно не приходят.Отчаявшись вы не знаете, что делать и пишите в Parse. Выясняется, чтоу них была ошибка, они ее исправили и теперь пуши приходят...Приходят на новый сертификат, то есть на новый билд, которыйдоступен только вашим разработчикам.. А production пользователитак и не получают пуши, и активность определенного сегментапользователей продолжает падать...Вопрос: какие уроки вы бы вынесли для себя? И в чем положительныйаспект этой ситуации?К слову диалог из фильма "После прочтения сжечь":- Чему мы научились агент?- Не знаю, но точно чему-то научились- Научились, по крайней мере, больше этого не делать- Ага, точно- Еще бы знать, что мы сделали!
  • ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ:В последнее время очень много говорят про onboarding - процесс,когда ваш пользователь впервые открывает приложения и проходитпервые экраны до тех пор, пока не совершит ключевое действие: дляIn Flow - отметить свое настроение; для App in the Air - добавитполет; для Foursquare - зачекиниться.В посте про воронку продаж я говорил, что мы тщательно следим заэтим процессом и за его показателями, чтобы убедиться, что каждый,кто открыл приложение, имел возможность прочувствовать егоценность. (Другой вопрос, что не для всех это может быть ценностью,но это вопрос идеи вашего продукта).3 типичные проблемы в onboarding:1) Cлишкоооом долгий - пользователю нужно преодолеть 100500экранов пока он доберется до главного... Не все такие терпеливые.Прикрепляю, к примеру, сравнительный анализ In Flow с Path,Instagra, Foursquare и Day One, который открыл нам многое в нашемпродукте - респект за это Nikita Kosholkin :)2) Cлишком вариативный - пользователю предлагается слишкоммного вариаций куда пойти и что делать, никто "не проводит заручку". В эту тему презентация:http://www.slideshare.net/BayramAnnakov/social-interfaces-2-onboarding3) Слишком "холодный" - чтобы прочувствовать ценность приложения,пользователю нужны в нем друзья или контент. Без этого приложениекажется мертвым. Именно поэтому в App in the Air мыпроанализировали отзывы, оставленные во всех аэропортах мира,обработали их и добавили в раздел Tips.Очень в эту тему рекомендую еще 2 спорные статьи:1) If you see a UI walkthrough, they blew it -http://blog.maxrudberg.com/post/38958984259/if-you-see-a-ui-walkthrough-they-blew-it2) Rethinking the Mobile App "Walkthrough" -http://techcrunch.com/2012/12/28/rethinking-the-mobile-app-walkthrough/
  • ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ:Я как-то уже share-ил наш чеклист для отправки билда в AppStore ивот наткнулся на аналогичный для Google PlayОсобенно мне понравились ;-)1) Tell your friends and family to download, rate and review the app2) Partner up with other app developers to cross promote apps3) Reply to any negative feedback you’ve received on the Google Playmarketplaceи обилие ссылок под ряд пунктов: от stackoverflow до документацииGoogle!https://s3.amazonaws.com/files.appannie.com/blog/pdf/Going_Live_on_Google_Play_Checklist.pdf
  • ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ:В далеких 70х в Стэнфорде проводили эксперимент, в ходе которогодетям предлагалось не есть зефирку и тогда те получали 2.. Основнаязасада была в том, что не есть нужно было тогда, когданаблюдающего не было рядом... Мало кто выдерживал! Ну почему жене слопать, если никто не видит?Интересно, что с программистами так же (я сам был таким): еслиникто не видит и не проверяет, то ты совершенно не паришься о"чистоте" кода. Ты пишешь, чтобы работало, а не чтобы былочитабельно и так далее, и тому подобное! Проблема в том, что потомэтот код никто не может понять, решения не очень адекватные, я ужене говорю о названиях переменных в коде, из-за которых Заказчикможет подать на тебя в суд (знающие - поймут ;-))Поэтому мои 3 пункта:1) Code inspection - только не классический и нудный, а интересный ив форме challenge-а2) Hackathon - умение делать простые и работающие, повторноиспользуемые решения3) Release lessons learned - когда команды обмениваются опытом изнаниями, полученными за релиз.Удачи!
  • ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ:Редко при разработке приложений можно обойтись безвзаимодействия с 3-сторонними API: Foursquare, Facebook, FlightStatsи иже с ними.Мы много повидали разных API и разных проблем и с Sergey Proninсоставили хит-парад основных ошибок:1) Пока не попробуешь, не говори, что это работает - часто тынаходишь API и думаешь "опа, я теперь смогу брать расписаниеполетов", а как только доходит дело до прототипа вдруг выясняется,что взять-то ты можешь, да только по полетам с вылетом не ранее 3дней.2) Пока не попробуешь, не говори, что это НЕ работает - есть такаяштука в психологии "фундаментальная ошибка атрибуции": это когдачеловек во всех бедах винит всех, кроме себя. Часто разработчикивинят во всем провайдеров API, но на деле выясняется, что ошибкимогут совершать и "боги"... ой, наши разработчики. Проблемуусугубляется слепой вере техлида в своих разработчиков и нежеланиеподнять свою попу со стула и залезть в код и документацию, чтобыразобраться в проблеме. У меня была история в жизни, когда я вот так"промахнулся" перед Заказчиком, а Заказчик как раз полез в код... Ячуть не сгорел со стыда и взял себе за правило перепроверять (и этосовершенно не относится к вопросу доверия, это скореепрофессионализм)3) Если чего-то нет в документации, то это не значит что этого вовсенет (обратное тоже верно) - кто работал с Foursquare API знает, каксложно порой взять аватарки - нужно догадаться или посмотреть наstackoverflow, что между префиксом и суффиксом нужно вставитьслово "original" :)4) Установите контакт с провайдерами - это вытекает из п. 3, норекомендую смотреть шире: сколько раз я убеждался, что достаточноспросить людей и выясняется, что это возможно. Ну и подпишитесь наDeveloper блоги провайдера, чтобы быть в курсе изменений и новыхвозможностей.5) Внимательно и почаще читай доку, чтобы понять все возможности -часто техлид отдает это "на аутсорс", не вникая в документация и незная всех возможностей API. Еще важнее знать возможности продакт-менеджеру, так как часто одна из возможностей может статьконкурентным преимуществом продукта, а "мы.. а мы не знали" :). Ещепример: возможность батчами отправлять пуш-сообщения черезParse.com6) Рассмотрите вынос взаимодействия с внешним API на сервер: не
  • надо переделывать клиент, единая точка входа, поддержка разныхплатформ.7) Оцените динамичность информации от провайдера, чтобы принятьправильное решение о кэшировании информации и т.п.Удачи!
  • ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ:Посмотрел первый выпуск Facebook Developers Live с Doug Purdy,Facebook Director of Platform ProductКлючевые пункты:1) Build. Distribute. Promote - эту мантру Doug повторил несколько разза передачу.Build при помощи SDK (Single Sing-On, Deep Linking);Distribute при помощи Newsfeed и Timeline агрегаций;Promoto при помощи mobile install ads и Facebook страничек2) в качестве удачных примеров приложений: Foursquare, RunKeeper,Nike+, BuzzFeed, Spotify, GoodReads3) В 2012 ключевым событие стало осознание необходимости идвижение в сторону native разработчиков4) Игры - 2.5 млрд выплат; 250 миллионов играющих в прошломмесяце5) Lifestyle - в прошлом году бум музыкальных приложений; в этомгоду ожидают (и хотят) много приложение про книги, фильмы ифитнесс6) Facebook сам придерживает и рекомендует разработчикам: для iOS& Android - нейтив приложения; для остальных - mobile web7) 3 ключевых компонента Facebook платформы: newsfeed, timeline иgraph search8) Совет стартапу: разрабатывайте с использованием Facebook SDK,делайте так чтобы юзеры рассказывали истории при помощи вашегоаппа, а их друзья видели ваш апп и скачивали :))Что вынес для себя?Мантра очень напомнила такую же простую и понятную мысль,которую Apple активно продвигала при выпуске iPhone: "An iPod. APhone. And an internet communicator". Задумался о таких же простыхслоганах для наших приложений. И надо повнимательнее посмотретьна deep linking.Ссылка: https://developers.facebooklive.com/videos/74/what-developers-need-to-know-in-2013
  • Байрам Аннаков (Empatika): 5индикаторов успеха мобильныхприложенийПроцент пользователей, которые появляются благодаряработе сарафанного радио. Ещё в 1969 году Фрэнк Бассматематически описал модель распространения нового продукта.Пока продукт никто не знает, работает реклама, потом еёэффективность снижается, и число пользователей либо падает,либо, если маркетинг и продукт хорошие, продолжает расти за счётэффекта сарафанного радио. Это как грипп: если пользовательвашего продукта подсадит на него больше одного человека,начнётся эпидемия. Как следить за распространением вируса?Когда кто-то делится ссылкой на приложение в соцсетях, мыможем потом увидеть, кто из его друзей перешёл на страничкуприложения и загрузил его, — есть специальные программы,отслеживающие пути распространения ссылки. Число устныхрекомендаций можно оценить, например, отслеживая, сколькодрузей найдёт пользователь при регистрации. Если хотя бы одного,значит, он, скорее всего, пришёл по устному совету.Количество активных пользователей — ктопользуется приложением хотя бы один раз в единицу времени. Взависимости от идеи приложения можно рассчитывать его за деньили за месяц. Для AppIntheAir мы, например, рассчитываем егопомесячно, потому что мало кто летает каждый день. InFlow,позволяющим вести статистику настроений, люди пользуютсякаждый день, так что этот показатель мы и рассчитываемежедневно.
  • Темпы недельного роста. Перед каждым проектом мыставим цель расти по количеству загрузок на 5% еженедельно — поотношению к предыдущей неделе. Если эта цель не достигается, мыдумаем и предпринимаем что-нибудь. У каждого сотрудника-сооснователя есть $50 в неделю, которые он может потратить налюбую идею, которая, как он думает, внесёт лепту в рост. Этоможет быть конкурс детских рисунков или тупая реклама,дискуссия на портале Quora с упоминанием нашего приложенияили дописывание статьи в «Википедии». Таким образом, каждыйсотрудник понимает, что рост — это и его цель тоже, а не какого-томаркетолога или PR-агентства.Длительность сессии — время, которое пользовательпроводит с приложением. Если я провожу в приложении час,больше вероятность, что когда я буду сидеть со своим другом, онувидит и спросит, что это такое. И таким образом заразится.Количество сессий на активного пользователя.Компания Flurry публикует статистические данные о мобильныхприложенях. Например, среднее количество сессий в месяц. Здесьидея та же, что и в предыдущем пункте: чем чаще человек импользуется, тем сильнее формируется привычка и вышевероятность заражения друзей.Когда вместо роста числа пользователей основной целью компаниистановится прибыль, к этим критериям добавляются стоимостьпривлечения одного пользователя и прибыль с каждого из них.
  • ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ:"Об отзывчивости и баскетбольных мячах"Если вы занимались баскетболом или ваш "физрук" в прошлом былтренером национальной сборной по этому виду спорта, то вынепременно помните такой мяч. Мяч этот не простой: он в разытяжелее обычного и часто используется для тренировок - послебросков со штрафной зоны таким мячом, вы обычным мячом легкопреодолеете половину поля (14 метров, как сейчас помню), а то ибольше.Аналогично и с мобильными приложениями: если ваше приложениебыстро загружается на стареньком iPod (@Sergey Pronin привет ;-), тооно точно будет летать на новеньких айфонах.5 распространенных хаков, как повысить отзывчивость вашегоприложения:1) Сносите в фоновый процесс инициализацию всего, что не виднопользователю при старте приложения (маркетинговые ианалитические фреймворки в первую очередь)2) Apple рекомендует вместо логотипа на сплешскрине показыватьскриншот экрана приложения: это создает у пользователя ощущение,что приложение загружается быстрее. Пруфлинк:https://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/IconsImages/IconsImages.html3) Если вы разрабатываете книгу, то подгружайте заранее следующуюи предыдущую страницу, чтобы быстрее было перелистывание (см.Narr8)4) Дайте возможность юзеру ввести комментарий без подгрузки всегоконтента, не блокируйте ввод (см. Facebook app)5) Подгружайте на сервак фотку, пока юзер пишет к ней комментарийи решает, в какие соцсетки расшэрить (см. Instagram)И, наконец, не стесняясь замеряйте responsiveness вашегоприложения, сравнивайте с конкурентами и лидерами отрасли. Ведьлучше иметь представление что улучшать в своих продуктах, чемдовольствоваться статус-кво.Приглашаю делиться своими "аппхаками" в комментариях - соберемBest Practices? Думаю всем будет полезно.
  • 1) Tech Lead должен обращать особое внимание на выбортретьесторонних библиотек, не отдавая это на откуп программиста.Особенно хорошо нужно разбираться в разного вида лицензионныхсоглашений и условиях изменения кода/последующегораспространения. Статья в тему:http://en.wikipedia.org/wiki/Software_license2) Часто (я надеюсь, если вы начнете этим управлять ;-) у вас встанетзадача выбора библиотеки из нескольких альтернатив: помимовопросов цены и лицензии рекомендую обращать особенноевнимание активности этого проекта (к примеру, до сих пор ли ониюзают UDID в iOS и вовремя ли выпускают обновления - ситуацияможет усугубиться отсутствием лицензии на изменения кода), обилияфорумов и вопросов/ответов, модификаций библиотеки.3) Для коммерческих проектов или стартапов перед продажейдоли/оформлением прав встает вопрос наличия документированногосписка используемых библиотек, подтверждения возможности ихиспользования. Если сильно пренебречь пп.1 и 2, то эта задачавыльется в nightmare.Немного "юридический" поcт, получился :)
  • ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ:На прошлой неделе мы встречались с инженерами Apple в Лондоне.Встреча условно называлась "From Good to Great": спецы из Cupertinoи Apple Europe провели аудит нашего App in the Air - Fly smarter идали ряд рекомендаций по улучшению.Несколькими аспектами с удовольствием поделюсь, в планах ещесделать чеклист, по которому самостоятельно можно будет проводитьаудит других наших проектов.1) Responsiveness - Apple стремится время загрузки приложениясократить до 1 сек. Не грузите в основном потоке больше, чем нужнопользователю на первом экране. Остальное - в фоне.2) Logging - не забывайте отключать логгинг в production версии - этоускоряет работу приложения, а также позволяет не логироватьлишнего ;-)3) Graphics - обратите внимание, как вы работаете с графикой,слоями и прозрачностью. На скрине красным показаны проблемы спрозрачкой, которые замедляют работу приложения. И статья в тему:http://astralbodies.net/blog/2012/01/30/fixing-layer-transparency-issues-in-xcode/4) Memory - Не забывайте реагировать на memory warnings(didReceiveMemoryWarnings)5) Frameworks - Аккуратнее работайте с 3есторонним софтом6) Bundle Contents - Просматривайте содержимое финальной сборкиприложения: там могут оказаться лишние ресурсы7) И посмотрите хотя бы эти 3 видео с WWDC:iOS App Performance: Graphics and Animations EssentialsiOS App Performance: Memory EssentialsiOS App Performance: Responsiveness
  • ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ:App in the Air: выдержка из чата :-)Вовремя оказанный саппорт может "по-человечески" вырулитьнедостатки продукта — с Никитой Кошолкиным.
  • ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ:1,5 месяца назад я впечатлился эссе Paul Graham-а про модель ростастартапов. Впечатлился настолько, что решил внедрить у нас в App inthe Air и In Flow: перед каждым продуктом была сформулированацель: 5% недельный рост количества даунлоадов по сравнению спредыдущей неделей. Если вы читали эссе, то знаете, что такой ростпозволяет за год вырасти в 13 раз.Скажу сразу, цель мы достигли и даже перевыполнили, но я хочуподелиться инсайтами:1) Каждый участник команды стал задумываться о задаче роста, а неделегировать это "какому-нибудь маректологу". Кто-то постилпровокационные вопросы на форумах по самоизмерению и просилколлег отвечать на вопросы с упоминанием In Flow, кто-то пробовалрекламу, а кто-то сгенерировал конкурс для детей.2) Будущее стартапа очень неопределенное, поэтому нужна хотькакая-то точка опоры, мини-цель, мини-шажок к большой цели.Вырасти в 13 раз в год - звучит круто, но неопределенно и тыожидаешь какого-то чуда, и обычно в конце года :)) Синдромстудента в действии... А вот вырасти на 5 процентов в неделю звучитболее понятно и сфокусированно. Напомню еще раз 1й принципДжобса: Фокус. Это то, чего не хватало нам раньше и не хватаетмногим стартапам, но это именно то, что теперь мы не упустим.3) В команде появилась какая-то синхронность и нацеленность нарезультат.Спасибо, Коллеги, и спасибо - Paul Graham :)
  • ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: получили доступ к crashlytics beta,очень легко ставится и хороший репортинг крашей! Рекомендую!
  • ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: рассказ основателя Instagram отом, как они масштабировались и преодолевали проблемы с этимсвязанные"scaling = replacing allcomponents of a car while driving it at100mph"http://ru.scribd.com/doc/89025069/Mike-Krieger-Instagram-at-the-Airbnb-tech-talk-on-Scaling-Instagram
  • ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: размышления о кнопках“Buttons are a hack. As in the real world, they’re often necessary,but they work at a distance—secondary tools to work on primaryobjects. A light switch here turns on a lightbulb there. Theseindirect interactions must be learned; they’re not contextuallyobvious. The revolution that touchscreen devices are working isthat they allow us, more and more, to use primary content as acontrol, to create the illusion of direct interaction. I don’t mean tosuggest that we throw out all of our familiar buttons entirely.Light switches shall remain necessary, after all, and so shallbuttons, espec...
  • ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: 10 типичных ошибок при дизайнемобильного приложенияhttp://mashable.com/2012/04/11/mobile-app-design-tips/ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ:Flurry недавно выкатили апдейт, в котором есть 2 суперполезныхфичи1) Funnels - можно строить воронки пользователей, их поведениявнутри приложения и тп2) Alerts - можно ставить алерты на ряд событий: например, еслиповысился уровень ошибок или снизился уровень новыхпользователей и тд и тпhttp://www.flurry.com/product/analytics/version3.2.html
  • ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: дарите своим юзерам физическиетовары за ачивки в приложенииhttp://techcrunch.com/2012/03/22/kiip-goes-beyond-games-lets-any-app-reward-you-with-real-life-prizes/ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: Eugene Lensky натолкнул на оченьинтересную презентацию про дизайн мобильных приложений, парапринципов оттуда:1) Никто не читает ваш текст2) Считайте клики3) Не копируйте webТам же про тренды: 5кнопочное меню, смерть таббаров, скрытаянавигация и многое другоеhttp://www.slideshare.net/theevank/sensational-ios-app-design-first-principles-and-new-trends-for-2012ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: "На мобилках люди сканируетстраницу по картинкам и обычный паттерн слева-направо более несрабатывает" - результаты eye-tracking-а на iPhonehttp://searchengineland.com/study-reviews-and-images-drive-clicks-in-mobile-109659ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ:если вы интегрировались с facebook, то обратите внимание навозможность тэгить друзей, локейшны и делать бОООльшие фотки,проставив соответствующий флагhttp://developers.facebook.com/blog/post/2012/03/07/building-better-stories-with-location-and-friends/ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: простой и полезный сервис дляорганизации нагрузочного тестирования сервераhttp://blitz.io/
  • ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: если пользуетесь TestFlight длятестирования до выхода в AppStore, то очень рекомендую встроить ихSDK:1) Позволяет отслеживать тестирование2) Позволяет в режиме реального времени собирать информацию обошибках (логи, описание окружения тестера и тп)https://testflightapp.com/ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: часто бывает задачапротестировать экран приложения до кодирования и мы в Empatikaпридумали небольшую процедуру: Design HoursВот она, собственно: каждый новый экран обсуждается согласно такойструктуре1) Что это за экран? Зачем он нужен пользователю?2) Какие действия возможны на экране?3) Как эти действия можно инициировать?Потом показываем скрин с результатом действия (если применимо)4) То ли это что вы ожидали получить?5) Опишите что вы видите?6) И далее сам дизайнер отвечает на все вопросы...Очень важно, чтобы "испытуемыми" были те, кто ранее не видел этиэкраны, а еще лучше - представителями ЦА. В том числе иразработчикам приложения будет полезно заранее узнать :)
  • для мобильных разработчиков: из внутреннего обучения - вдругпригодится кому.будут вопросы – welcomehttp://www.slideshare.net/BayramAnnakov/flurry-analytics