幸せになりたいモバイルUI・IA系の人が考えるプロトタイピング最終回

「とりあえず今現場まわしてんだけどどうしてんの？定義も分かるんだけどやり方の話もしたい」という数少ない人に向けたnoteも今日で最終回です。

参考までにこれを書いてる人のスキルセットは、グラフィックデザインできない、情報設計っぽいことはやっている、サービスデザインの人寄り、ノンプログラマーで、ちょっと化学が好き、となります。

ホワイトボード至上主義すぎると大変です

「全部ホワイトボードでやってるんですよー」と言う人いますけど、多人数開発だとかなりつらいです。2人とかで画面数少なく単純なもの作ってるならいいですけど、複数人で開発しててカスタマーサポートやQA別の人にお願いしたり、仕様を伝える必要がある場合は後々のためにもドキュメントを残しましょう。ホワイトボードでやってるとしても写真でログを残しましょう。ホワイトボード見ておいて、とか伝言ミスを誘発するので余程の実力者以外お勧めしません。経緯も合わせて伝えるの大事。何でそれになったかが分からないと、あとで振り返れません。機密保持的にも危ない。

進め方のおすすめは、ノート（not note）で情報設計案いくつか作って、UIデザイナーと議論して最後にCacooとかに清書し関係者にシェア。3人以上で話す時はホワイトボード上で議論するのがよさげ。

出したい情報のリストと優先度、やることやらないことをプロダクトオーナーが書き出して整理する。完全に手ぶらで「みんなでUI決めようぜー」をやっても僕の考える最強のUIがたくさん出てくるだけなので、プロダクトオーナーの事前の整理重要ですし、全くしてなかったらその打ち合わせはやっちゃだめです。

情報設計については段階がありますが、それはもうちょい後でお話しします。

どこから画面操作レベルで考える？

まずは何はなくともflinto（https://www.flinto.com/）。flintoは画面の画像ファイルをドラッグ＆ドロップするだけで画面一覧を作れて、画面間遷移も作れて、スクロールもできて、固定メニューもさくっと再現でき、簡単に実機でプロトタイプを再現できるツールです。

昔はCacooのワイヤーをここに突っ込んで遷移を確認してたんですが、結局最終的にデザイン詰めるところでマージンも魅せ方も普通に変わるのと、手間ばっかりかかることに気づいたので最近はやってません。そして普通のひとはワイヤーのプロトタイピングなんて興味ないので、現実的に入れた所であんまり実になりません。ひとりふたりで議論するなら、このレベルは大体紙でできるという。

先の議論で情報設計詰められていたらもうUIデザイナーにラフでもいいのでデザインつくってもらったものをflintoに突っ込んでもらったほうが色々二度手間感なくて早いと思います。大事なのはここまでに入れたい要素の話は決着をつけておくこと。デザイン作ってから「やっぱりこのボタンいらなくね？」みたいな話になるなら、もう一回情報設計に戻りましょう。たぶんまたそうなる。

なおflintoの特徴としては、URLだけでさくっと共有し、ブラウザの更新ボタンを押すだけで最新の画面見られるので気軽です。「画面最新の入れたんで見てくださいー」と言われたら更新すればOK。gifアニメも使えるので、ちょっとしたアニメーションも組み込め、画面遷移を使えば複数案見るのもすぐにできます。なおこれでお金をもらっているなどはないのであしからず。

決めやすくて手戻りしにくい座組み

まず前提として、多数決では決めません。

情報設計にはプロダクト責任者（notマネージャー。プロデューサーとかプロダクトオーナーの人）が関わるのは必須です。再度言いますが、この人が優先度決めきれてないならそこのUIは作っちゃだめです。

大体こんな設計、というものがIAとUIデザイナー間で共有できたら、そのUIを実装する人を入れて話しましょう。最後の詰めの段階で、実装する人も納得感を持って作ってほしい、というのと、意味の分からない実装難易度のUIをつくらないための会話です。

やりたい目的はこれで、動きのイメージはこれで、どういうシーンでこの辺に出したいのだ、と言う情報があると

「言われた見せ方だとAndroid死ぬけど、代案でこんなのあるよ。どう？」 「ここは画像じゃなくてCSSアニメーションでいけるし、むしろ軽くなる」

等の会話ができるので、結果的にUIデザイナーも実装者も幸せになりやすいです。何となくやっちゃいけなそうなことをIAやUIデザイナーが知っていたとしても、端末のシェアが変わっていたりすでにあるライブラリが改善されていたりすることもあるため、「それほんとに今の段階で難しいのか？」は専門家に聞いてみた方が早いと思います。

動きで言えば、単純なものはphotoshopでgifアニメ、複雑な時はAfterEffectsとかFlashでイメージ作ることもありますが、話せそうだったらそれらで作る前に相談。事例あれば事例見せちゃうのが大事です。話しにくくてそんなのできないよ、であれば、UI作る前にチームの雰囲気作りましょう。毎週1回振り返りの時間つくってざっくばらんに話すとか、お菓子食べ放題にするとか、やり方は色々あります。

一通り作った後に誰かにレビューしてもらうことがあると思いますが、その時は経緯を必ず伝えましょう。見た目の議論より先に解決したかったことを共有して、その結果今はこれをやっていると言う話の方が結果的に建設的です。少なくとも誰向けなのかとか、経緯なしにUIとかインタラクションの善し悪しを語れるスキルは僕には無いです。

結局きれいごとばかりになってしまったのでこの辺で終わりにします。あと、最近アプリの情報設計をしてて思うに、モバイルWebとモバイルアプリのUIは全然別物です。WebはWebなりにAndroid標準ブラウザが標準じゃないとかaudioはユーザアクションが無いと動かないとか考慮することは多いのですが、アプリは動きと音とOSガイドラインのことまで情報設計やUIデザイン時に考慮できない、引き出しに無いとまるで戦力になれないなと思いました。アプリって言ってもiOSとAndroidも全然違うものですからね。

----

おまけ：いつも使ってるノート→マルマン A5 ノート ニーモシネ 5mm方眼罫 70枚 N182 （http://www.amazon.co.jp//dp/B001A1VB74/）

タイトル元ネタ：幸せになりたいソーシャルゲーム系Webフロントエンドエンジニアが本気で考える HTML GUI ツール第一回（http://dameleon.hatenablog.com/entry/2014/04/29/030306）