「サイボウズ・アドベントカレンダー」の12日目です（これまでの記事一覧）。
こんにちは。kintone 開発チームの神戸です。主にフロントエンドを担当しています、しかし、あまりコードを書かないプログラマです。ユーザーインターフェイスと呼ばれる、入力画面や表示画面のデザインや実装をしています。
「プログラマが画面デザイン？」と思いの方もいるかも知れません。サイボウズの一般的な開発プロセスでは、 PMから要件／仕様と共に画面デザインがPGへ渡される流れになっています。とは言いましても、渡された画面デザインをそのままコード化するのではありません。
今回は、フロントエンドにおける画面デザインを紹介したいと思います。
エンドのエンド
フロントエンドとは、最初のプロセスという意味もあります。そのエンドのエンドは、勝手に「プロセスが始まるきかっけ」と考えています。使いやすさの前に、「使ってみたい」と思わせる印象と言えばよいでしょうか。
エンジニアは作る人と同時に、作った物を最初に使う人にもなります。もちろん製品に合わせたターゲット像がありますが、まずは、自分が使ってみたい、使いやすいと思えるかを大事にしています。
例えば、このブログです。 公開された当時は以下のようなデザインでした ( 上 ) 。 斜体や文字間が窮屈に感じていました、そこでより読みやすくなるにはと考え、 色やフォントの調整を提案し ( 下 ) 、現在のデザインになっています。
画面デザイン
ここまで "デザイン" という言葉を使用してきました。“デザイン” と聞くと、一般的には “グラフィック” 面をイメージする方が多いと思いますが、 私は “グラフィック” 面も含めて設計と考えています。
HTML/CSSも バージョンが上がり、JavaScript のようにアプリケーション言語としての役割も増えて来るように、個人的には感じます。 CSSにおける設計思想は以前からあり、 OOCSS（Object Oriented CSS） という単語を聞いたことある方も多いかと思います。 以前はその設計を実現することが技術的に難しく感じていましたが、近年 Sass ( compass ) 等の登場により、実現しやすくなったと思います。
現在、設計面において Sass を効果的に利用するために、パターンの洗い出しをし、パーツ化を進めています。
パーツ化
パーツ化を進めているのは、2 つの目的があります。 1 つはユーザーに対して、操作性とデザイン統一感を提供すること。 もう 1 つは開発の効率化です。 チーム内では、このパーツ化をまとめている資料を、 ガイドラインと呼んでいます。
これにより似ているようで少し違うとか、アイコンが同じなのに意味が異なるといったデザイン上の問題を防ぐことが出来ると考えています。
ガイドラインを利用した画面デザインの確認
静的な画面デザインだけでは、気付きにくいデザイン上の問題などもあります。 また意識せずに、そのサンプルデータが綺麗に表示されるよう、レイアウトを組んでしまうことがあります。
実際の Web アプリケーションでは、コンテンツは用意されている物だけではなく、ユーザーにより入力されたコンテンツが様々なパターンで表示されます。そのパターンを漏れなく、属人的な確認にならないよう、ガイドラインには、画面デザインに対するチェック項目も用意してあります。
- 各ブラウザでの見え方
- 画面サイズが広い場合、狭い場合
- 初期表示の場合
- データ無い場合
- テキストが短い場合、長い場合
- 表示数が多い場合、数が少ない場合
- 省略表示する場合
- モバイルの場合
- アクセス権がある場合
- マウスがホバーされた場合
- etc..
さいごに
ガイドラインに合わせて、パーツを組み合わせていくだけでは、使いやすいとは限りません。表示する画面全体の色彩や余白などで、印象が変わる場合があります。正確な数値で揃えるより、なんとなく揃える方が気持ちよく見えることもあります。
ガイドラインは単に基準であり、ガイドラインに合わせる事が目的ではありません。その画面に応じて最適な画面デザインを提供できるように、また、時代、技術に合った、画面デザインになるように、日々改善していきたいと思います。
明日は「WalB こぼれ話: プロトタイプの性能問題解決」をお送りします。お楽しみに。
