【新規サービス開発ウラ話】 みてねみまもりGPSがリリースされるまで
こんにちは。ノゾエ(@conoito)です。
みてねみまもりGPSがリリースされました。
この記事では、プロジェクトが立ち上がってからリリースに至るまでの過程を、デザインまわりのウラ話もりだくさんでお話しします。
みてねで初めてのハードウェア製品「みてねみまもりGPS」
プロジェクト発足!
みてねみまもりGPSは、みてねにとって初めてのハードウェア製品です。
自分たちだけでは知らないこと・できないこと・足りないことだらけ!
なので、外部企業と協力しながらの開発となりました。
本業であるアプリ・サーバー開発も外部委託メンバーにお任せすることになったのには2つくらい理由があるような気がします。
1つ目は、ハードウェア開発と一緒にアプリ・サーバー開発も依頼することで、開発における連携がしやすいこと。
2つ目は、ちょうどそのころ怒涛のプロジェクト発足ラッシュの時期で、純粋に社内の開発リソース全然足りなかったから。
(みてねアプリができてから数年間、2こくらいしかなかった関連商品が、一気に10こくらいに増えた2020年でした。強すぎる)
メインのデザイナーは2人。ペアで行いました。
・みてね初期メンバーのシニアデザイナー(← バディ)
UX設計(体験設計)がすごく得意
・新卒4年目、みてね3年目の私
UI設計(インターフェース設計)が得意
当時のわたしは、外部と協力してサービスを作るのが初めてだったり、そもそも新規アプリのUI(インターフェース設計)を丸ごと担当することも初めてだったりスペックです。
見た目を作り始めるまでがいちばん大事(だと思う)
プロジェクトが発足してすぐ、爆速でUX(ユーザー体験)を設計します。
ポイントは
・やり方を簡易化してでもUXを設計するのに必要な基本的なフローは必ず一通り行うこと
・フレームワークを使うのは、検討忘れが減るというメリットがあるから
・本来はチーム全員でやるべきだが、1-2人でもやる価値がある
今回実際に実践したフローは
デザイナー1名、ビジネス1名でほとんどの事項を実践。
● ユーザーニーズの抽出 & 抽象化
アンケート:ビジネスチームが事前に行い、ニーズがあるかどうかを調査
インタビュー:社内で対象ユーザーを募集し簡易的に実践。ターゲットが間違っていなければ、社内でも一旦大丈夫そう。なにより、楽!
共感マップ:抽象化を行わないと、個人の気になったセリフだけがクローズアップされたりしがちなので必須。
● 課題整理(インセプションデッキ or リーンキャンバス)
インセプションデッキ:複数人でしっくりくるまで書く。考えうる対象ユーザーやユーザーニーズによって複数枚書くことが多い。書きづらい箇所があればそこに問題がある。書きづらい部分が弱点だと認識しておく。
● UXフローの設計(ジャーニーマップ)
ジャーニーマップ:作るべき機能の取りこぼしがないか検討するのに大事。また、魅力付けのために検討しなければならないこともここで拾えたりする。
ターゲットは最初からある程度見えていたため、ペルソナなどは実践しませんでした。ターゲットが見えてない時はペルソナも立てると良さそう。
インタビューのサマリなどは、インタビューに参加できなかったメンバーにも大事なことがすぐ伝わるように、社内ドキュメントなどで即時共有。
ジャーニーマップを経て機能が洗い出せるので、プロダクトの方向性がなんとなくわかるくらいのワイヤーも作成。
メンバーに展開し、方向性に違和感がなさそうか認識合わせを行いました。
個人的にはここがいちばん大事な工程だと思っています。
なぜならここでミスると、この後何をどう頑張って作ってもそもそもの方針がミスっているのでアレなものが出来上がるから。。。
でも慎重になりすぎてコストや工数をかけすぎてもいけないところかも。
いつまでも出来上がらなかったり、方向転換しづらくなることになるので。。
手に取れる製品、作り直しが効かないプレッシャー
並行して、外部のプロダクトデザイナーと協力しながら、本体関連のデザインも進めていきました。
個人的なポイントは
・画面上のもので満足しないで、必ず手に取れる形に出力して確認
・いつ、どこで、どんな時に使うのかを考えると「こうあって欲しい」が出てくる
・とは言えやはり専門じゃないので、いつでも質問できる専門の人を巻き込むが吉
アプリ開発との圧倒的違いは、いちど決まると量産されて在庫がなくならない限り、作り直しがそう簡単には効かないところです。こわや・・・。
でも、少しずつ物事が決まっていってサンプルが上がってくると、みんなで考えたものが実際に手に取れるのがやっぱりなんだか嬉しいのでした。
ものづくりはたのしい!CAN MAKE TOKYO (∩^o^)⊃━☆゜.*
余談ですが、今でこそUI/UX畑でお仕事をしているわたしですが、実は大学ではプロダクトデザイン分野を専攻していたのでした。
その頃の学びがほんの少しだけ生きた気がした。(気がするだけかもしれないけど)
● 質感・材質
身の回りにある製品を質感の参考にしたりしました。
利用者、利用シーンのことを考えると、できるだけ汚れない材質がいいなということとかを考えていました。
左側の画像は材質の見本帳みたいなやつなんですが、こんなものがこの世にはあるんですね初めて知った。
● カラー
UX設計の段階で、カラバリ展開を行うことは決まっていました。
また、何色にするかもアンケートを元に絞りました。
普段は画面ばっかりで色を見ていますが、今回は手に取るプロダクトなので、実際の色味を手に取りながらの確認を行いました。
(画像にはないですが)それぞれの色ごとに大量のカラーチップを引っ張り出し、渾身の「白・ピンク・青・緑」を選定。
● パッケージ・冊子
会社の近所の電気屋や、オシャレ家電屋にデザイナー2人で出向き、たくさんの商品を見てパッケージを調査。
どんな製品がどんなパッケージなのか傾向を知りつつ、じゃあみてねみまもりGPSだったらどのパッケージにしたいかを考えました。
ついに実装された! → 全然終わりじゃない
まず、必要な機能とプロダクトの方向性がなんとなくわかるくらいのワイヤー(構成)を作成します。
(ごく一部を引用)
今のUIとはかなり差がある段階です。何が必要そうかわかればヨシ!
そして、↑を元に辻褄を合わせながらゴリゴリにUIを設計していきます。
UIを設計する上でのポイントは
・色・タイポグラフィ・GUI(iOS, Androidの標準UIアセット)は最初に用意しておく
・細かい要素もできるだけ最初からコンポーネント化することを意識
・実装されたらドッグフーディング(実機検証 & ユーザビリティテスト)は必須
● 色
Material Design Guideline の The color system を参考に、ひと通り用意すべきカラーセットを最初に作成し、Figma の Library に登録しておきます。
ちなみに、このセットはいちど作っとけば、他プロダクトにも流用できるのでとってもおすすめです。
● タイポグラフィ
タイポグラフィも同様に、 Material Design Guideline の The type system を参考に、ひと通り用意すべきタイポグラフィセットを最初に作成し、Figma の Library に登録しておきます。
● GUI(iOS, Androidの標準UIアセット)
インターネッツで配布されている、各OSのGUI(扱いそうなやつ)を探してきてインストールし、Figma の Library に登録しておきます。
車輪の再開発はしたくないので、GUIの中ですでに用意されているパーツと同じ機能のものを、オリジナルで作るようなことは極力避けます。
ルールに従おう!あるものは使おう!!!その方が開発もスピードアップします。
● 個人的おすすめ素材(Figma・Sketch・XD)
Material Design GUI (公式)
iOS 12 GUI (iPhone8用) (非公式)
iOS 14 GUI (iPhone12用) (非公式)
● 最初からコンポーネント化
2画面以上で繰り返し使うものはできるだけ最初からコンポーネント化しながら画面を作っていきます。
画面が増えていくにあたって「ここを修正したらあそこも修正しなきゃ・・・」な場面が爆増しますが、最初からコンポーネントにしておけば1箇所修正するだけで全部に変更が適用されるので作業効率が最高になります。
▼ とりあえず雑でもOK!
コンポーネントが増えてきたら、整理できるものは順次整理していきます。
「どのくくりでコンポーネント化すればいいかワカラナイ・・・」
そんな方は、MaterialDesignのGUIのコンポーネントの構造ががとても綺麗なのでぜひこちらを参考にしてください。激おすすめです。
▼ MaterialDesignのGUIのコンポーネントの構造を参考にしながら整理したコンポーネントたち
ただ、↑のMaterialDesignのGUIのコンポーネントの構造に絶対沿わなきゃいけないわけでもなく、「ここを修正したらあそこも修正しなきゃ・・・」が発生しそうな場所は深く考えずにコンポーネント化すればいいと思います。
そういうものは「Misc」というなんでもあり概念の箱に突っ込んでいます。(笑)
別記事で、コンポーネントの構造整理を頑張る話をしているのでこちらもどうぞ
● ドッグフーディング(実機検証 & ユーザビリティテスト)
必須です。(しかし当初わたしの頭にはなかった)
ここを怠ると、せっかく作ったものが小さなところで躓いてしまいます。
ちゃんとやれば、リリース後の危険を最大限に回避できます。
やり方としては、レビュー会を行い、修正対応を行うまでのスケジュールは必ず確保するようにします。
また、初見のユーザーを対象者に含めておきたいところ。
みてねではチーム内のパパママをこのために呼んだりしました。
今回のドックフーディングでは、
・説明が足りない部分
・せっかく作っても利用されない分かりづらい部分
などをあぶり出すことができました。
そして、
・初期不具合の発見
・ユーザークレームの一番多い問題の発見
にもつなげることができました。
ちなみにドックフーディングで出てくるつまづきポイント、こんなにあります。
その頃のわたし、体力を残していなかった(両OSのUIを作り切ることに100%の体力を注いでしまった & LP制作が大詰めだった)ので、ドックフーディング対応力が消しカスになってしまいました。ツイートする力すらなくなった(深刻)(ちなみにバディに助けられました😭いなかったら今頃アプリごと溺れ死んでいたであろう)
修正対応の体力を残すことを永遠に誓ったのでした 〜続〜
ちなみにLPのデザイン・コーディングは以下のような仕上がりに。
ポイント
・何ができるプロダクトなのか・どんな時に使うのかがひと目で分かる
・(他社製品と比較した時の)みてねみまもりGPSならではの強みをできるだけ早く分かりやすく伝える
コーディングは相変わらず得意ではないので、コードレビューが過酷でした
〜死〜
あとは、最近になってTwitterでOGPが出ないことが発覚したりもしました
〜恥〜
(心の中で、デザインは10000点だと思っています。腹を痛めて産んだ愛しき我が子よ・・・)
他にも
・アプリアイコン
・サービスロゴ
・ストア用スクリーンショット画像
・みてねアプリ内のLPデザイン・コーディング
・広告用ポスター
・広告用チラシ
とか、まだまだやったこと工夫したことはそれぞれたくさんあるのですがもう書き切れないのでやめます。
サービス1つ作るのは本当に本当に本当に大変。
でも出来上がりの喜びはひとしお〜〜!☝️☝️☝️
ついにリリース! → まだまだ終わりじゃない
ついにリリースを迎えました。
カスタマーサポート(CS)宛てに届いたお問い合わせから、アプリの改善ポイントを挙げることができました。
内容を確認し優先度をつけ、残された開発期間でできることを最大限対応していっています。(現在も対応中。あと少し・・・!)
アプリだけではなくLPも。
お問い合わせが多い項目は、LPでちゃんと伝え切れていない部分でもあるので、内容をアップデートしていきます。
すると、お問い合わせが多かった質問は対応後しっかり激減したりして、「知りたいことをユーザー自身が見つけられるようになった!よかった!」と嬉しい気持ちになったりします。CS対応の負担も減った。
ユーザーのつまづきポイントを知れるお問い合わせメールは宝の山じゃ!
さいごに
現在、限定価格だった初期ロットは早々に売り切れ、定価販売となっております。ありがとう、ありがとう、、、
ハードウェアのサービスのいいところは「在庫がみるみる減る」っていう物理的な喜びを感じられるところだとおもいました。
ポジティブな口コミ(エゴサスミマセン)がわたしの活力です。
(ひとりで気持ち良くなっててすみません。今だけは許して・・・!)
まだ新学期始まったばっかりなので、もしも小学校に入学したばかりのお子さまをお持ちの方がいらっしゃったら、是非とも購入をご検討ください!!!!!!!!!!!!!!!!!!!!!!!どうぞよろしくお願いします!!!!!!!!!!!!!!!!!!!!!!!!(大声)
- - - - -
最近のわたし日記
その時に満たしたい「寿司度」によってチャレンジすべきアイテムが何かを知るための図を考えたりしています。
意外と手頃なアイテムで合格点を叩き出せるなということがこの図の気付きです。
Twitterなどでシェアいただけると、もっと喜びます!!! https://twitter.com/conoito