こんにちは、UI/UXデザイナーの城です。
前回の記事では、Yappliで提供しているアプリの機能刷新にあたって、調査の経緯と気づきについてお話しました。 この記事では、ユーザーインタビューで得られた情報をモデル化し、その結果を社内に報告したことについて書きたいと思います。
今回調査会社の方と一緒に分析ワークショップを行いました。 10名分のインタビューの中で得られた情報を切片にしてテーブルに並べ、そこからKJ法でグルーピングしていきます。 大量の情報を1つ1つ読み込んでいくのはなかなか根気がいりますがここで適当にまとめるといけません。大事な情報が潰れてしまって最終的に薄い内容にまとまってしまうためです。 なので複数人で確認しながら注意して抽象化していきます。 その後、ジャーニーにまとめ、ユーザーのメンタルと行動がどのように関連しているのかをモデル化していきます。
最終的に以下のような課題が分かってきました。
事実としての情報に触れ、ユーザーのメンタルと行動を分析したことで上記の課題を解像度高く理解することができました。 調査会社の方から教えてもらったことですが、こういったインタビューの見学や分析は関係者が参加するべきとのことです。 調査会社がまとめたドキュメントを読んだだけではどうしても「そんなの分かってたことだよね」という感想を持たれて終わってしまいがちですが、一次情報に触れ、自ら分析していくことで重要な情報を十分に咀嚼し「腑に落ちる」という経験ができるので、その後の意思決定に大いに役立ちます。
調査結果に関する報告会では、開発に関わるPdmやエンジニア以外にも、営業メンバーやお客さんのアプリビジネスをサポートするカスタマーサクセスチームといった様々なメンバーが参加してくれました。沢山質問が飛んだり真剣にメモをとっている様子が見られたりしたので中身の濃い報告会になった気がします。 またその後参加者アンケートを行ってみたところ、多くが仕事に役立つ部分があり満足したと回答していました。 以下抜粋コメントです。
- ジャーニーマップを含め、ユーザーの感じている「価値」を可視化されていたことが役に立ちそう。(お客さんへの)提案にも活かせる
- 思ったより○機能はユーザーへの動機が薄いなと感じました。逆に△機能はxxxしやすくするなど仕様考慮してもいいなと思うところが多く、かなりメモしましたw
これらの感想を得て感じたこととしては、情報を共有し同じ課題感をもつことで進むべき方向性を議論できるようになるということです。 誰か1人が情報をもっていても、それを他メンバーに根拠をもって共有できていなければ結局何も進みませんが、ファクトをベースにした情報を関係者に共有することで全員の理解が深まり、より建設的な議論をボトムアップで起こすことができます。
調査と分析をしたことで、主観や思い込みに左右されない議論を行うことができます。 ボトムアップでプロダクトを良くしていくための武器の1つとしてこういった調査は有用かと思います。 今回の話の場合は定性調査でしたが、案件や状況によっては定量調査も行うことでよりバランスのとれた判断が可能になりそうですね。
ヤプリのUI/UXチームはまだまだ未熟ですが、体験を良くするための取り組みを今後も強化していきます！
こんにちは、UI/UXデザイナーの城です。
UI/UXチームでは日々、Yappli（ヤプリ）というプロダクトのUI改善や新規機能開発の体験設計を行っています。 今回は最近実施した定性調査のご紹介とその有用性について前編・後編に分けてご紹介したいと思います。 前編は実施した調査の経緯と気づきについてです。
YappliはBtoBtoCサービスです。 アプリを作成したいと考える企業がYappliの管理画面でアプリをつくり、そのアプリをエンドユーザーが利用します。 UI/UXチームの主な業務は、この管理画面のUI改善を行ったり、アプリエンドユーザーの体験を考え端末側のUIをデザインすることですが、最近はユーザーを理解するために定性調査を強化しています。
Yappliで提供しているアプリの機能は20以上もあります。 今回はこの内の1機能について、UI面・仕様面の刷新を行うというものでした。 この機能はリリース以降長く利用されてきましたが、時代とともにUIが古くなってきたことと、お客さんからの追加要望が多いことから刷新を行うことになっていました。
しかし、ここで疑問がわきます。
要件はあるものの、機能のビジョンや方向性といったものがない中で、えいや！と開発したところでユーザーからの不満や新たな課題があがり、右往左往することは容易に想像できます。 特にアプリエンドユーザーについては私達プラットフォームのデザイナーからはとても遠い存在であり、ユーザーが何を期待しどのように機能を利用しているのか把握もできていないような状態でした。 そのため、今回は対象機能の利用実態とユーザーの価値観を調査し、今後の開発の意思決定の材料にしようと考えました。
今回は調査会社と連携し以下の設計で本調査を実施しました。
目的：ユーザーの利用状況や価値観を理解し、今後の開発検討を行うための基礎情報とする
調査手法：1on1デプスインタビュー(60分)
対象ユーザー：Yappliで作成された特定のアプリを利用するエンドユーザー10名
ユーザーインタビューを行ったことで多くの気づきを得ることができましたが、その中でも興味深かったのは、家族全員が同じアパレルブランドのアプリを利用しているというものでした。その家族は一家でそのブランドのファンであり、全員がアプリを利用しているようなのですが、お母さん、お父さん、お子さん、それぞれ利用のしかたが異なっていました。お子さんは自分の欲しい服をアプリで探して親にねだり、お母さんはクーポンやセール情報をチェックし、お父さんは家族で買い物に出た場合に店舗でアプリを出すといった使い方をしています。
スマホアプリはPCと異なりコンパクトな世界なので、基本1人で使われることを想定してしまいがちですが、グループ単位でのコンテキストが存在することもあります。会社のデスクで作業をするだけでは想像できませんよね。 ユーザーの家族構成や生活まで理解をすることで、点と点が1つの線としてつながってくような、複雑性をもった1つのストーリーが浮かび上がります。
もちろん今回調査した10名がアプリユーザーのすべてではなく、汎用的に使えるペルソナを立てるには別の調査が必要になりますが、少なくとも自分たちの「ユーザー目線」がいかに浅いものであったかを痛感しました。 私達がUIをデザインしているアプリの向こうには、想像していなかったユーザーのコンテキストが存在しており、その生活の一部にアプリが使われていることを知れたわけです。
次回の記事では、ユーザーインタビューで得られた情報をモデル化し、報告会を行った話を書きたいと思います。
こんにちは、株式会社ヤプリでAndroidエンジニアをしている岩端です。
もうそろそろ Android Qがリリースされそうですね！
Android Qでは折りたたみ式デバイスのサポートが強化され、Android Studioでは折りたたみ式デバイスシミュレーターを使えるようになったので、動かしてみました。
端末を二つ折りにできる折りたたみ式スマホ。
今年9月に数端末の発売が予定されていたり、OSとしてもサポートを強化し、今後の展開に注目が集まっている。
1.Android3.5 RC2(2019/8/13時点)をDLしてインストールして起動
2.Devices ManagerでCreate Virtual Deviceを押下 下記の端末サイズが用意されている
・7.3 Foldable
・8 Foldable
3.作成が完了したら実行
・色々な画面比率を想定して実装していれば、大きなデザイン崩れが起きることはなさそう
・スクロールするような画面の場合、開閉時で見える領域が異なる
・開閉動作で再描画が走る
構成の変更に対する対応方法 -> 実行時の変更の処理 | Android Developers
・折りたたみ(マルチウインドウ)非対応にもできる
android:resizeableActivityとandroid:minAspectRatioを設定すると制限することができる
折りたたみスマホ対応をする場合、下記２点の調整を行うと良さそうです。
１、デザイン崩れは無いか
２、各画面の折りたたみ開閉時の画面保持状態はどうあるべきか
元々多種の画面サイズ、密度、比率を想定して実装することが多いため、大きな画面崩れは発生しないと思います。
しかし、今後は更に様々なアスペクト比をサポートしていて、画面比率1:1を折りたたむと21:9のように大きく比率が変わるケースもある為、より幅広い使い道が生まれ、今まで以上に様々な端末サイズにあった調整が必要になっていきそうです。
こんにちは、ヤプリの三縞です。
Xcode 11 からはiOSプロジェクトを新規作成すると AppDelegate と同時に SceneDelegate も自動生成されます。
この記事ではこの SceneDelegate について、その役割や AppDelegate との違いについて調べたことを残しておきます。
SceneDelegate によって、1つのアプリに対して複数のUIのインスタンスを作れるようになります。
今秋にリリースされるiPadOSでは Slide Over / Split View 機能で1画面の中に同じアプリを2つ並べることができるようになりますが、これはこの「1つのアプリに対して複数のUIのインスタンスを作れるように」なることで実現可能となります。
Xcode 11 からはiOSプロジェクトの新規作成時に自動で SceneDelegate が作成されることから、今後はiOSでも複数のUIインスタンスを利用した新しい機能が導入されるのではないかと思っています。
SceneDelegate は iOS 13 から導入される protocol UIWindowSceneDelegate に準拠するクラスSceneDelegate は 必須ではない
Application Scene Manifest (キー名: UIApplicationSceneManifest) にSceneの設定があるときに必要となるSceneDelegate がある場合・ない場合のどちらでも AppDelegate は必要
@UIApplicationMain Attributeを用いてアプリのエントリーポイントとして指定するためSceneDelegate か AppDelegate のどちらかのメソッドしか呼ばれない
SceneDelegate が使用されている場合は SceneDelegate がAppDelegate がSceneDelegate がある場合・ない場合のどちらでも、アプリ全体に関わるイベントは AppDelegate のメソッドが呼ばれる
application:didFinishLaunchingWithOptions:applicationWillTerminate:SceneDelegate がある場合・ない場合のどちらでも、以下のような「ライフサイクルイベント」に関するNotificationは機能するNotificationCenter.default.addObserver(forName: UIApplication.didEnterBackgroundNotification, object: nil, queue: nil) { _ in print("notification didEnterBackgroundNotification") }
Copyright © 2018 Yappli, Inc. All rights reserved