Webの機能をアプリでサポートするときに気をつけたいこと

この記事は [CrowdWorks Advent Calendar 2017](https://qiita.com/advent-calendar/2017/crowdworks) の11日目の記事です。

##はじめに
はじめまして。
クラウドワークスのアプリ「Crowdworks for Worker」のプロダクトオーナーをしている @kanako16 です。

突然ですが、最近施策を考えたりするときにこんな悩みにぶつかった時がありました。

「Webのこの機能をアプリに展開したいけどWeb側使いにくい。そのままアプリに展開していいの？」

クラウドワークスでは、先行リリースしているWebの機能をアプリでサポートできていない部分があり、Webの機能をアプリに展開していく場面があります。

昨日の @tkoshida さんが公開した「[クラウドワークスのiOSアプリ会員登録を改善した話](https://qiita.com/tkoshida/items/9e9fc7c86ba326726443)」も、ブラウザに遷移させていた会員登録機能をネイティブ化した事例の一つです。さらに会員登録の前にも、今までアプリからはブラウザに遷移させていた報酬機能をアプリで使えるようにしました。

Webの機能をアプリでサポートしていくときに、クラウドワークスでよく出てのが、
**「Webのこの機能・UIって使いづらいよね」**
**「Webも一緒に改善する？それともアプリだけ使いやすくしちゃおうか？」**
という意見です。

正直な気持ちでは**使いにくいならWebも合わせて全部改善しちゃおうぜ！**と言いたいところですが、
PO目線で現実的に考えると、スケジュール、チームの状況などいろんなことを考慮するとすぐにやろう！とは言えない状況も多く心苦しいのです。

なので、今回は私が今までクラウドワークスアプリの施策を考えていく中で考えた「Webの機能をアプリでサポートするときにやっていいこと・ダメなこと」についてご紹介していこうと思います！

##Webの機能をアプリでサポートするときに気をつけたいこと

###**①アプリはあくまでもユーザー体験の一部だということを忘れない。**

クラウドワークスアプリには「アプリの使い使いやすさを求めたのに使いづらくしてしまった」という過去の失敗があります。Webとアプリの両方にお仕事を探す機能がありますが、アプリだけで体験を考えて個別に設計をしてしまったために、こんな失敗をしました。

* ユーザーが検索をしようとした時、Webとアプリで検索する仕事カテゴリが異なる
* ユーザーが仕事情報を見た時、Webとアプリで表示される項目が異なる
<img src="https://qiita-image-store.s3.amazonaws.com/0/152496/27ec56d4-4088-2a18-82d9-38d08ffbd1e2.png" width="500" >

もちろんユーザーさんからも使いにくいと厳しいご意見もいただきました。

この失敗から、私たちは <font color = "red">**アプリはサービスにおけるユーザー体験の一部にすぎないこと。全体として一貫した設計をしなければいけないこと**</font> を学びました。


※この失敗談については、弊社デザイナーの @ueda1023 さんが過去にイベントでさらに詳しくご紹介してます。よろしければ[イベントレポート](http://careerhack.en-japan.com/report/detail/841)もどうぞ！

###**②そもそも「Webの機能をアプリでサポートしよう！」から考え始めないこと**

これは実際に私が報酬機能をアプリでサポートしようとしたときに失敗しそうになった大きな原因です。

報酬機能は「ユーザーにとって報酬は重要な情報なのに、アプリで見ようとすると毎回ブラウザが起動する。UIもPCでみる表示と同じで使いにくい。よし！アプリで見やすいUIにしよう」というのがはじまりでした。

さらに①で紹介した失敗もあり"一貫した設計"を意識しすぎた結果、目的は「報酬をアプリで見やすいUIにすること。項目や情報設計はWebと一貫した設計にすること」になってしまっていました。

そのため、**「ユーザーはどういうシーンでアプリで報酬を見るのか？」** **「ユーザーが報酬画面をどう使うのか？」**を考えられない話は進み、ユーザーを置き去りにしたまま報酬画面のワイヤーフレーム作成まで進んでしまっていました。

ワイヤーフレームをチームでレビューした際に、「未出金の報酬金額をユーザーが各履歴を確認して、自分で手作業で計算しなければいけない」などのユーザーがどう使うかを考慮しきれていない課題が出てきてしまいました。今回はレビュー段階でユーザーが置き去りになっていることに気づくことができ、最終的にはユーザーファーストな報酬機能をアプリで実現することができたのではないかと思っています！

たとえWebの機能をアプリに展開するという場面でも、ただ機能同士の一貫性だけを考えるのではなく、 <font color = "red">**「私たちのサービスが解決できるユーザーのニーズやゴールは何か？」から考え始める**</font>と、ユーザーを置き去りにする失敗はなくなってくるのではないかと思います。

もし「このWebの機能をアプリでサポートしたほうがいい？」と悩み始めたり、一回立ち止まってユーザーについて考えてみてください。

もしチームに「Webにある機能をアプリでサポートしよう！」と言っている人がいたら、一回立ち止まって「私たちのサービスが解決できるユーザーのニーズやゴールは何だっけ？」と聞いてみてあげてください。私はチームのメンバーに聞いてもらって気づくことができました！

###**③サービスにおけるデバイスごとの利用シーン・役割を明確にすること**

①と②で色々話しましたが、個人的には**③サービスにおけるデバイスごとの利用シーン・役割を明確にすること**が一番重要だと思っています。

もちろん全ての機能を全てのデバイスで一貫して使えるようにすることも選択肢としてはありますが、その場合にもやはり以下のようなユーザーの利用シーンに適したデバイス、ユーザー体験でデバイス毎に優位な部分を考えながら機能に優先順位をつけて設計していくことが大事なのではないかと思っています。

例えば、

* アプリだとプッシュ通知でリアルタイムに気づいてもらえる
* アプリにしたら、ブラウザよりサクサク使うことができる
* PCだと画面が大きいので、スマートフォンよりも情報の一覧性が高い

とかが考えられます。

なので、Webの機能をアプリでサポートするような場面では、サービスにおけるデバイスごとの利用シーンや役割を明確にしていく必要があると思います。そして役割を明確にしていくことができると、①や②についても解決できるのかな？と思います。

実際にクラウドワークスでも、サービスにおけるアプリの役割を明確にするためにカスタマージャーニーマップを再定義しました！

ユーザーインタビューを行い、ユーザーの利用シーン・利用デバイス・具体的な行動・感情・課題などを付箋で洗い出しています。今は、さらにこのカスタマージャーニーマップを元に、デザイナーが中心になってクラウドワークスにおけるアプリの役割やコアな機能を絶賛見直し中です！

##おわりに
今回はクラウドワークスアプリの施策について、施策を考えるプロセスの中で悩んだこと、気づいたことなどを描いてみました。

アプリの技術的な部分のお話についても、エンジニアの @YusukeIwaki さん、 @tkoshida さんが描いてくださってますので、ぜひ「[コンポーネント指向でAndroidアプリを作ろう](https://qiita.com/YusukeIwaki/items/37a3148ee2287ef2db4e)
」と「[クラウドワークスのiOSアプリ会員登録を改善した話](https://qiita.com/tkoshida/items/9e9fc7c86ba326726443)」も見てみてください！

引き続き、 [CrowdWorks Advent Calendar 2017](https://qiita.com/advent-calendar/2017/crowdworks) をお楽しみください！