Windows Phone アプリ(&Win8アプリ)を作っていただいている開発者の皆様へ伝えたい、よりよいアプリにするための８のUIに関する提案（我流）

#wpdev_jp #win8dev_jp

まぁ、じつは Advent Calendar ネタに考えてた話ですが、自分の中の整理がまとめきれず別のネタにしましたが、ひとまず今段階での思いを本年中に出しちゃいます。

from 2014 to 2015

いよいよ Windows 10 がリリースされると、Windows Phone を取り巻く環境も一変します。それぞれのストアやアプリの距離は今のUniversal Application よりも、より近いものになるでしょうし、そうなれば多くのアプリが自分のまあ割りに現れてくるはず。長く使ってもらえるアプリケーションとして高い品質を実現するために、改めてチェックしてほしいところを並べてみました。

尚、これはあくまでも高橋の個人的な持論です。間違っているかもしれません。そして時にアプリ開発者には自分のアプリを否定されて嫌な思いをされるかもしれません。そのあたりはご了承ください。

ー

【UX】背景が黒のうちはβ版

まずこの話、ゲームは除きます。といってもゲームほど背景にこだわるものもないのでずっと全部意味もなくまっ黒というのはむしろないでしょう。

背景黒のいいアプリってありますか（あったらごめんなさい、ぜひ教えてください）？ Facebook, Twitter, LINE, Amazon, メジャーなアプリで背景が黒いもの（暗いもの)はありません。特に文字を中心としたコンテンツを表示するものは。特にコンテンツを読ませるようなアプリについてはほぼ背景城といっていいのではないかと思います。Windows のモダン（フラット）デザインは境界線さえも排除するスタイル。暗い背景に明るい線は必要以上に太さを与えます。これはモダンデザインと対極にある方向。

じゃぁ、標準アプリはどうなの？というと確かにカレンダーアプリやMusic/Video アプリは背景黒ですね。というかテーマに合わせて変わるようになっています。ただ、その中でもコンテンツを読ませるようなものの代表格であるメールアプリでは、ちゃんと最後にメールを読む画面では背景が白になっていることがわかります。

もちろん背景が黒でも良いと思うものもあります。それはメディアを大きく表示するもの。黒背景はほとんど少しだけの余白になるので。グラフィックツールも一般向けなら黒でない方がいい。それに合わせてアイコンの色も決まっています。

 

ではなぜ？Visual Studio の標準テンプレートは背景が黒なのか？考えたことがありました。そして自分なりの結論。黒で作っている間はそのアプリケーションはまだ完成品ではないんです。プロジェクトと作ってちゃちゃっとテストする間は黒でもいいんです。むしろ正式版出ないから黒でいいんです。そして本格的に開発を始めたらちゃんと背景を考えてつけるのです。だからむしろVisual Studio の標準テンプレートは黒背景でいいんだろうなー。って。

   ー 

【UX】情報を面で切る

これもデザインなところですが、必然的にどういったものにするのか決まれば決まってくるは無し。

例えば、LINEの会話は吹き出しのような形で区切られています。これは基本的に面でコンテンツを区切っています。Facebook もグレーの背景に白い線やブルーのメニューなど面で区切ります。メールアプリも各ペインは面で区切ります。色をほとんど使わない、そんなときだけ線で区切るデザインになると思いますが、そのときも許されるのは極細の線だけ。 場合によっては線で切らずに空間を使って分ける場合もあります。

強すぎる線は、やっぱりバランスを崩しやすい。黒い背景だとどうしてもそれが出やすい。なので、使うときも注意が必要。そして大事なことは、それをアプリ全体でちゃんと徹底すること。画面によって変わってしまうので意図がない限り不安にさせてしまいます。

ー

【UX】コントロールを使ってたらスタイルを作る

SDKにはたくさんの標準コントロールがあって、勿論ゲームでもなければ標準コントロールを全く使わない、なんてことはないでしょう。もちろん、ほぼ画面全部が古スクラッチで描画していてコントロールはリトライの時だけ、なんてゲームみたいなパターンは除いて、標準コントロールを使っていてスタイルを定義していないのはナンセンス。（リンクボタンとかしか使っていないのものぞく）

 

スタイルを定義していないってことは標準コントロールのデザインをそのまま使っているということ。ダメですよ、それ。リストを使えばリストの定義でスタイル（テンプレートを使うと自動的にスタイルが定義されてテンプレートが組み込まれます）テキストボックスだって、ボタンだってちゃんと画面デザインをすればそれぞれのデザインが決まります。それをちゃんと統一するにはスタイルの定義は必須。

そのまえに基本的にちゃんと基本的な色を決めたらそれを定義したほうがいいんですよね。そういう意味ではスタイルとリソースの定義も必要です。

ー

【UX】アニメーションの使いどころ

アニメーションを使うところ難しいと思っている人は意外に多いです。そんな人はシンプルにこう覚えればいいです。

「今あるものが消えるとき」と「今までなかったものが現れるとき」

 

ま、幽霊みたいなものですね。これ以外はまずは使わなくてもいいと思ってください。ピボット(ハブ)や画面遷移はわかりやすい例かもしれません。 今あるページが消え、今までなかったページが現れるときにアニメーションを使います。その次を考えるときは状態が変わるが位置は変わらないもの。ボタンやスイッチ系がこれ。ただし複数のボタンやスイッチに効果をつけるときその効果は統一すること。だからそんなときはスタイルを使ったり、ユーザーコントロールにしてしまったりするんです。     

ー

【実装】スクロールが最優先

多くのコンテンツを表示すると、コンテンツをいろいろ触れるようにしたくなりますし、そういった機能をつけます。が、絶対に守らなくてはならないのは「スクロールを邪魔しないこと」リストコントロールなどでスクロールしたり、タップしたり、ドラッグしたりできる場合、ユーザーが実際に行う行為の95%以上はスクロールでしょう。

 

ですからスクロールしたいのに他のイベントがハンドルしてうまくいかないとか、よくふいにタップされる、とかスクロールの初動が躓く、というのはNG。

ー

【プロセス】デザイン→プロト→デザイン→開発

以前は開発の仕様から入り、あとからUIデザインを設計するプロセスが多かったかと思います。

いまは（UXという概念が普及してきてからは）デザインから入るべきだと思っています。

１．ヒアリング

作ろうとしているものをデザイン・開発する人がよく知っている（＝ユーザーであったりする）のであれば一番いいのですが、たいていのユーザーは自分が何を求めているのかよくわかっていません。ですので、デザインする人は初めにこれから何を作らなければいけないのかしっかりヒアリングしないといけません。

２．プロトタイプデザイン

ヒアリングした内容を基に、問題点の抽出や期待されている点を絞りプロトタイプデザインに入ります。ここはデザインする人の店泥子ですが、作りこみ過ぎてもいけません。それが完成品と思われてしまいフィードバックが得にくくなります。その作りこみのボーダーラインは相手や案件によっても異なりますが。

３．プロトタイプテスト

まずはユーザーなり他の人にテストしてもらいます。使用するシナリオに沿って使うとフィードバックを得られることでしょう。

４．デザインと開発

大きなデザイン変更が必要ならばもう一度プロセスを踏んで、ある程度基本形ができたらいよいよデザインと開発フェースに映ります。もちろん開発の担当はここまで何もしなかったのではなく、想定される仕様に対しての基本技術の検証とサービス設計を進めておく必要があります。仕様上ネックになる点があれば早い段階で共有していく必要があります。

５．イテレーション開発

あとは、ある程度の機能単位や短いフェーズ単位に分けて開発、テストを繰り返していきます。あとは完成するまでずっと開発するといのは大きなリスクを生みます。短期開発ば求められる今は早い段階での問題発見と早期対応が必須になります。

そんなわけで、表に出てくるのはインタラクションデザイナーや、デザインナ―スキルを持つディレクター、もしくは開発に多少の知識を持つデザイナーであり今後ますますそういった人材が求められてきますし、クオリティの高いアプリを作るための必須な人材となるはずです。

ー

【その他】指摘してくれる人を大事に

みんな優しいから、あまり指摘をしてくれない。これではホントにいいのか悪いのか判断できない。これが使いづらい、これのデザインが気持ち悪い、こういったようにきちんと指摘してくれる人は貴重な存在。自分では気づかないほころびを把握するためにもこういった指摘をくれる人は大事にするべき。

 

ただし、指摘してくれる意見を受け入れることも大事ですが、場合によっては受け入れないことも大事。ときにあれもこれもリクエストされる場合もありますが、これがどういうアプリなのかは自分のもの。「それはこのアプリには必要ない機能」としてリクエストに対応しないことも大事です。ちゃんと自分の中で理由づけが出来ていればね。    

ー

【その他】ここまでのルールに沿わなくてもいい

8つのルールを出したものの、やってもいいことでもある。しかしそれには強い理由は必要。多少使いづらくなってもそうすべき理由が明確であればそれはそのままでいい。理由づけもなくデザインしている部分はある意味死んでいるデザイン。こうあってはならない。