「なぜこういうデザインになったのか」というデザインフローシリーズ。

まだまだ続きます。
複式家計簿をかんたんに入力して振り返れるようにしよう、ということで、シンプルな画面が求められます。

前回の基本設計編では、手書きでなんとなくできることを整理してみました。

前回までの話を読んでいない方はまずこちらからお読みください。

家計簿アプリの画面（基本設計編） ｜ ツクロア – DESIGN LAB

今回は、「入力したデータ一覧画面」を実際にSketchでつくりながら考えていきましょう。

【2】入力したデータ一覧画面

お決まりの、どういう要素が必要だったかというところを復習していきます。

A.入力したデータ一覧画面

【必要な要素】

• 金額
• 費目
• 日付
• そのお金がどこから出たものか（貸方）

【アクション】

＋データの入力画面へ移動する
＋その月のサマリー画面へ移動する
＋費目の一覧画面へ移動する

これらを画面に起こしていくのですが、今回はAndroidアプリ。
Androidで使うパーツを簡単に紹介しておきます。

【参考】Androidデザインで使うパーツ

Androidでは、今はマテリアルデザインというデザイン言語に従うことが原則とされています。

マテリアルデザインは、AndroidアプリではなくWebデザインにも展開されていますが、今回はAndroidに限定します。

ひまなときにぜひ読んでおきましょう。

Introduction – Material design – Google design guidelines

ツールバー

Androidではほぼ必要になるパーツで、画面の最上部に位置するものです。

Toolbars > Structure – Layout – Google design guidelines

その中でも、ナビゲーション、検索、アクション用に使われるものをアップバー（App Bar）と呼びます。
以前、アクションバーと呼ばれていたものです。

App Bar > Structure – Layout – Google design guidelines

タブ

ビューを行き来したいときに、使います。

Tabs – Components – Google design guidelines

スマホの場合は1画面内に3つのタブまでが固定できます。

それ以上になるときは、アイコンにすれば4つまではよさそうです。

もっと増える場合は、横方向にスクロールするタブになります。

Androidのタブで特徴的なのは、コンテンツエリアを左右にスワイプすると、次のタブのビューに進めることです。

ボトムナビゲーション

今までは、タブは上に置くように！iOSのように下に置いてはいけません！と主張されていましたが、つい先日、タブを下に置いてもいいよ、とガイドラインが変更されました。
それがボトムナビゲーションです。

Bottom navigation – Components – Google design guidelines

Google+のアプリを見ると、さっそくといわんばかりにボトムナビゲーションが使われていますが、タブも併用して使われています。
役割としては、

• メインの画面遷移→ボトムナビゲーション（iOSと同じ感じ）
• タブ→各画面の中で、出したいものを切り口を変えて見せたいとき

に使われているようです。

ナビゲーションドロワー

左上にハンバーガーアイコンがある場合、それはナビゲーションドロワーです。
左端からスワイプすると出てくるメニュー群です。

Navigation drawer – Patterns – Google design guidelines

タブで並べきれないぐらいメニューが多くなる場合は、ナビゲーションドロワーがよいのですが、これを使うアプリはたいがい機能過多なことが多いです。

リスト

いわゆるふつうのリストです。
アイコン付き、アイコンなし、1行のものや複数行のものなどあり、行の高さや文字の大きさも決められていますので、まずはこの原則に従うようにしましょう。

Lists – Components – Google design guidelines

フローティングアクションボタン（通称FABボタン）

各画面において、いちばん重要なアクションを行うときのボタンです。
コンテンツの上に浮いているような形になっていることから、フローティング（浮いている）という名前がついています。

「いちばん重要なアクション」ということですが、次のようなものが多いです。

• メモ帳やTodo、メッセージなどであれば、新しいものを追加するボタン
• 写真アルバムなどであれば、検索ボタン

これらはそのアプリのコンセプトにも大いに関係するので、いちがいに「これ！」という定義はできません。そのアプリによってなにがFABボタンに入るべきかは変わってきます。

Buttons: Floating Action Button – Components – Google design guidelines

【2-1】要素を組み立てる

さあでは、これらをもとに、実際に画面を作っていきます。

「いやいや最初に全体の遷移図を考えて、ナビゲーションから考えなあかんやろっ」と突っ込む方がいるかもしれません。
それはごもっともだと思います。
しかし、実際に全体図・ナビゲーションから考えようとすると、実際には各画面でなにをするかというのをもっと細かく洗い出して、ワイヤーのようなものを考えなければなりません。

実作業ではそれも必要になりますが、このブログでは伝えたいことととずれるのでそこは割愛します。
というよりは、「作っていきながら考える」というほうをお伝えしたいのです。
もちろん、あとで手直しも必要になりますが、そんな1週間まるまるかけてつくったような画面ではない（むしろ10分でつくった）ので、作りながらどんどんこわしていきましょう。

要素をおさらいしましょう。

【必要な要素】

• 金額
• 費目
• 日付
• そのお金がどこから出たものか（貸方）

複式家計簿ですので、これらがどんどんたまっていくことになります。
リストですね。
ガイドラインのリストのサンプルにならって、これらを並べてみましょう。

Specs > Lists – Components – Google design guidelines

この中の、「Single-line list」です。

ご丁寧にいろいろなスペックまで書いてあります。すばらしい。

まずはふつうの「Single-line list specs」のほうを使ってみましょう。

余白があらかじめ決められているので、ラクちんですね。
とはいえ、情報量に対してちょっと文字が大きいのか、野暮ったい印象があります。

左から、費目、貸方、金額、となりますが、
ひ、日付が入らん。。

文字の大きさを少し小さくしたからといって、日付が入るとは思えないです。

では、2行にしてみますか。

この2行のスペックにあわせて作ってみます。

うーん、でかい。。
というか、よく考えたら日付でまとめられるんだな。

1行のものに戻し、日付の見出しを入れます。

日付ヘッダを追加しました。
この日付ヘッダの仕様はガイドラインにはありませんが、30dpとしました。

あ！そういえばさっきから「dp」という単位はなんだ？と気になっている方、いますよね。
dpとは density-independent pixels で、密度非依存ピクセルといわれます。
Androidアプリのデザインをするときには必ず出てくる単位なのですが、通常の画面密度の場合には「1dp=1px」と同じです。
これが、Retinaディスプレイの場合は画面密度が通常の2倍となりますので、「1dp=2px」となります。

最近ではSketchのような便利なツールで、各画面密度にあわせた画像をいっきに書き出せたりしますので、画面密度はあまり気にせずに「通常の画面密度」でデザインをつくることが多いです。
なので、「1dp=1px」と考えておきましょう。
テキストの単位は「sp (scale-independent pixel)」というのが使われますが、これも「1sp=1px」で大丈夫です。

文字サイズの調整

このままだと少し文字が大きい印象があります。役割を考えながら調整していきましょう。

このリストの1行1行の中でいちばんサブ的な要素は…やっぱり「貸方」ですね。
「クレジットカード」など文字数が多いものも容易に想定されます。

これで、だいぶ見やすくなりました。

ちなみに、パソコンでこのまま確認しても、文字の大きさのバランスは実はよくわかりません。
実際に、Android端末とつないで確認をしなければならないところです。
わたしは、「Android Design Preview」というアプリをよく使っています。

envis precisely / Blog

このように、PCの画面をそのままAndroid端末につないでくれます。
（倍率などは自分で調整しなければなりませんが、重宝しています）

Android端末を持っていない人は、さいあく、iPhoneとつなぐのもありです。
Sketch Mirrorなどを使っている人は、それでつないでもいいでしょう。

Sketch Mirrorを App Store で

iPhoneでAndroid画面のデザイン。。いや〜ナシナシ！と思う方もいるでしょうが、パソコンで確認するよりは何倍もマシです。

わたしたち制作者は、スマホで実際にさわって見てみないと話にならないのはよくあるのが、クライアントの担当者の方にも、ぜったいにスマホでさわって試してみてほしいところです。

デザインした画面を、PCで確認いただくことがよくあるのですが、「必ずスマホで見て！」と言うようにしています。
よくあるのが、PCで見ていたときには何も意見がないのに、実際にスマホで動くようになって、スマホでさわってみてから「ここが…」と言い出されること。

Prottなどのプロトタイピングツールもよく使いますが、けっこうPCから見られちゃうんですよね。こういったプロトタイプでも、PCから操作するのとスマホから操作するのではずいぶん操作感が違ってきてしまいます。

いまはまだプロトタイピングの前の段階ですが、デザインだけでも、この段階から必ず端末で見てバランスや色を確認していくようにしましょう。

【まとめ】

なかなか進まない…ですが、少しずつ進めていきますのでぜひチェックしてください。

今回はAndroidアプリのいろはも入れたのでそちらのほうがボリュームが大きくなってしまいましたが、だいじなところですのでガイドラインも必ず確認しておいてください。

Introduction – Material design – Google design guidelines

＃このページの画像はこのガイドラインから抜粋しています。

次はこの一覧画面を完成させます！