かなり基礎的なお話になります。

では実際にバナーデザインを例に紹介します。

1.構成要素を全部置く

まずはプランナーやプロデューサーと話し合って決めた構成要素を、とりあえず全部キャンバスに置いてみます。（今回は構成ありきですが、時間があればプランナーと相談しつつ、デザイナーが構成を作るのがベストです。）

必須要素を全部置かずにデザインし始めると、後で追加するのはとても大変な作業なので、一旦全部置きます。ありがちなのは、プランナーが作ってくれた構成のレイアウトをそのまま利用して、構成に色をつけただけのいわゆるパワポデザインになってしまうこと。構成の完成度が高いほど、そのまま作らなければならないような気になってしまうので、構成はあくまで構成要素と割りきって、プランナーのセンスは無視してとりあえず要素を置きます。

2.ストーリーを考えて優先順位を決める

こんなやり取りを想像すると、優先順位が見えてきます。①インパクトの強い言葉で気を引かせ、②結論を先に言って興味を持ってもらい、③オトクな追加情報で落とす。と言う感じ。ここの優先度は、プランナーとも握っておくと良いと思います。

3.単色でレイアウトする

さて、優先順位が決まったら、実際に優先順に目立つようにレイアウトしていきます。ここを妥協して、色に頼って優先順位をつけ始めると、色とレイアウトの両方で優先順位を付けなければならず、色を変えてはレイアウトを変えたりと、行ったり来たりして時間がかかります。無駄に色数が増えて、原因になります。

あとは、いきなり細部から作り始めると、後で破綻します。例えばレイアウトを決める前に、鼻息荒くカッコイイボタンを作ってしまうと、

「超カッコイイボタンが出来た！！！このボタンに合ったレイアウトにしなきゃ！！」

というよく分からない使命感に駆られ、「ボタンに合ったレイアウトをする」という方向に走ってしまいます。結果的にページ内の優先順位はあやふやになり、俯瞰してみると何を伝えたいのかよくわからないデザインになります。結果先輩に駄目出しをくらい、イチからやり直しで時間がかかります。

これらは、バナーはもちろん、UIデザインなど、どんなデザインをする上でも同じ事が言えると思います。シンプルで美しいデザインは、レイアウトや、マージンのバランスで優先順位が付いているので、沢山の色を必要としません。

ですから極力単色、もしくは2色で根気強くベースデザインをすることをおすすめします。
要は下書きのようなものです。

この作業を、作っては壊しを繰り返し行います。作ってみなければわからなかったりするので、とにかく手を動かして、最良のレイアウトを模索します。ここの作業が早くなれば一気に時間が短縮されると思います。

こんな感じになりました。全体的に主張が強くなりましたが、「急げ！」や「今すぐ応募」が目立ち、何となく優先順位通りになりました。

4.色付けする

ベースが出来れば、あとは色をつけて、優先順位をより際立たせます。ここまでできていれば、あとはフォントを変えても、あしらいや色を変えても、優先順位は崩れません。

こんな感じにも。

こんな感じにもできます。

実際に上の2点は出稿済みのもので、1点目は、あまりCVRが良くありませんでした。そこで、1点目のバナーは、掲載ページと色が馴染んでいて目立たなかったのでは？という仮説を立て、思いっきりトーンを変えて、2点目の黒ベースに変えたところ、CVRが約2倍に上がりました。

このようなトーンを一気に変える作業も、ベースが固まっていれば瞬時に行うことができます。作業工数が短縮できて、汎用的にも作れます。

駆け出しデザイナーの皆様、是非お試し下さい。

内製カード制作の流れ

私たちのチームでは分業を行っています。設定資料をもとに
ラフ→線画作成→塗り
という流れで分業をしてイラストの制作をしています。

このように順番にまわってきたものを着彩していくのが僕の担当の部分です。

色を塗る

着彩は
1.色の選定
2.進化後の色のパターンの決定
3.塗り
4.仕上げ
の順番で考えています。

1.色の選定
まず色を選ぶ上で一番大切なのが、そのキャラクターらしさをわかりやすくすることです。
例として「暗黒騎士ヴァーリー」のカードをで考えてみます。
このカードは進化３段階目のカードになります。

まず、使う色を考えます。
「暗黒」というキーワードをもとに、
どのような色のを使えばそれらしさが出るか考えます。
暗黒だと暗い青や紫などが思いつくと思います。

そのパターンを基準に、線画にベースを塗って色のバランスをとります。

このヴァーリーの場合は一番メインに見せたい紫の他に、
色相の違う紫を使うことにしました。また面積の少ない部分にさし色として黄色をいれてバランスをとります。

2.色のパターンの決定

進化の色替えがある場合は、進化バリエーション色のパターンを決定します。
今説明しているヴァーリーは進化後のものなので、色のバリエーションは作りませんが、
進化前では２パターンの塗りをしています。

変わったということをはっきりわかってもらう必要がありますので、
キーワードとしていた暗黒騎士のイメージを損なわないようなパターンを作ります。

また、同じ色のパターンだとしても、
色の面積をかえることで印象を変えることができないかも考えたりします。

3.塗り
影をつけることで形をはっきりさせていきます。
まず光源を設定します。
どこから光を当てたら見やすくなるのかを考え決めます。

このようなイラストならば、手前と奥がはっきりしているので、
右を光源にしたほうが見えやすくなると考え、光源を設定しました。

その光源からずれないように意識しながら影をつけていきます。

光の方向をしっかりさせれば、要素の多いイラストでもすっきりします。
ブレイブナインのイラストの場合は、陰に焼き込みをいれています。
陰の中に明度の違いを入れることで、自然な反射光をいれられます。

<ショートカット紹介>
普段制作するときに使っているショートカットを少し紹介したいと思います。

ラバーハンド

・ペンツールを使うとき、このチェックボックスを入れると
軌跡が表示されて便利です。
command+enter
・パスを選択範囲に変更
alt+delete
・描画色で塗りつぶし
command+delete
・背景色で塗りつぶし
command+J
・選択範囲をコピーして新しいレイヤーの作成

4.仕上げ

最終的になると全体的な彩度等を調整していきます。手前にきている大きな部品があれば彩度を高めに設定してあげて、遠近感をだすようにします。
また一番見せたい色以外で抑えられるものは彩度を抑えて引っ込ませます。

最後に形の中で一番見せるべき流れを考えて、
それがはっきり見えるように黒い色で落とし見やすくするようにします。

そして最後にはカード枠にはまって完成になります。

最後に

絵は曖昧な部分が多くなってしまいがちですが、

今回は、コンセプトが大幅に変わった場合の
デザインをどういうプロセスでリニューアルしていったか、
センスフルの場合のケースについてお話したいと思います。

ダカイゼンとは？

サイバーエージェントでは、月に2度サービスの見直しと、抜本的な改善を進めています。
それが「ダカイゼン」（打開+改善）と呼ば れている運用制度です。

（渋谷ではたらく社長のアメブロ）
http://ameblo.jp/shibuya/entry-11347403598.html

サービスの成長を遮る問題が生じていたら、
発見し速やかに大なり小なりの打開策を投じて、サービスを向上させ続ける。
それがダカイゼンです。

まずはコンセプトを再定義。

まず大前提として、

デザインは「コンセプト」を体現するものであること。
それをいかにユーザーにとって使いやすく、分かりやすく、
そして魅力的にみせるか。
そこがデザイナーにとっての重要な役割です。

「センスフル」は、ダカイゼンにてチーム全体で話し合った結果、
「おもしろ画像バトルで楽しむメディア」から、
「スマホの画像をお題に投稿するコミュニティ」に
なる事が決まりました。
サービスの基本ループとなる「お題に画像を投稿して、他の人からのリアクションを楽しむ」という内容は変わりません。

「バトルで楽しむ」おもしろ画像メディアから、
「お題に投稿して楽しむ」なんでも画像コミュニティへ

上記のように、センスフルは軸となるコンセプトががらっと変わりました。
それに伴ってデザインや世界観を改変していく必要があります。

ロゴのリニューアル

今回のダカイゼンでは、軸となる方向性を変えたため、サービスの「顔」であるロゴからリニューアルすることになりました。

ロゴは、サービス全体の世界観の起点となるものなので、
決めるまでには数十個は最低でも案を出して、
チーム全体でミーティングを繰り返し、決定していきます。

メインユーザーを想定してトンマナを決める。

コンセプト設定のあとは、それを最大限に引き出す世界観を決めて行きます。

●2ちゃんやニコ動画好きな男性中心

から・・・・

●20代の女性中心とした オールリーチ

に変更することをチームで話し合い決定。

それを汲み取り、
力強く、男性的な色使いから、女性中心～中性的なポップで明るい色使いに変えて行くことにしました。
あくまでも中心は女性だけど、男性が使っていても全くおかしくない雰囲気を出すことが重要です。

※カラーパレットの比較

世界観をターゲットユーザー層にあわせる

ゲーム等と違いコミュニティはキャラ等がいないので、

※ヘッダの比較

※見出しの比較

※ボタンのリニューアル

デザインリニューアルのまとめ

ダカイゼン前のデザインはこのような感じ。

ダカイゼン後のデザインはこのような感じ。

「センスフル」ダカイゼンでのデザインリニューアルは以上です。

上のQRコードを読み取るか、下記リンクよりアクセスしてください♪
【スマートフォン】【PC】
http://senseful.jp/

（DECOLINKについて詳しくはスタッフブログをご覧ください。）

今回はこのDECOLINKの最大の特徴とも言えるデコがダウンロードし放題の「デコ広場」について、デコの特徴やUIなどを3つ簡単にご紹介したいと思います！

１．あえてごちゃっと！見てるだけでワクワクするTOPページ

デコ広場のTOPは特集ページとなっていて、イベントものやおすすめなど、色々なデコパックへの導線が並んでいます。

ズラズラ～と一見ごちゃっとした印象のトップページですが、
これはデコ広場を訪れたユーザーがとにかく「見てるだけで楽しい！」「デコがいっぱいある！使ってみたい！」と思ってもらえるよう、あえてあまり情報を制限せず多くの画像を並べています。
また何度訪れても楽しめて様々なデコに出会えるように、いくつかのバナーがランダムに表示されるようになっています。

２．3種類の特徴の違うデコたち

デコ広場にはそれぞれ特徴の違う３種類のデコがあります。

①伝えたい感情をキャラクターの表情や表現で表す「スタンプ」
一覧ではキャラクターに興味をもってもらえるよう、それぞれの簡単な性格も一緒に表示。

②様々なモチーフやキャラクター＋文字・アニメーションで思いを伝える「メッセージ」
一覧では動くイラストとタイトルのみでメッセージの楽しげな雰囲気を伝えています。

③吹き出し内に文字と一緒に入れて、動く絵文字として使える「チビデコ」
一覧ではとにかく多くのデコを並べ、チビデコ独特のゴチャッとしたかわいらしさが伝わるように。

これらをタブで整理し、またそのデコの中でも人気順や新着順、コラボものやカテゴリで探せるようになっています。

・時間のない時には特集ページからサッとダウンロード。
・ピンポイントに探したい時や時間のある時には色々なページを回遊して楽しみながらダウンロード。
そんなシチュエーションを想定して、このような構成になりました。

３．ダラダラ探せてどんどんダウンロードできる仕組み

デコ広場を作る際にチームのメンバーと話していたのが、「ダウンロードを待つだけの時間を作りたくない。次々と色んなデコをダウンロードしたい！」ということ。
せっかくたくさんのデコがあっても、１つずつに時間がかかっては意味がありません。
そのためデコ広場では１つのパックをダウンロードしている間にも別のページを回遊してデコを探し、またダウンロードすることができます。
そしてダウンロードが完了したものから順にトーストを表示しお知らせします。

以上、とても簡単ではありましたがデコ広場の特徴の中から3つご紹介いたしました。
まだリリースしたばかりのDECOLINKですが、これからユーザーの動きや意見を元にどんどん改善していく予定です。

おわりに

最後まで読んでいただきありがとうございました！
実際にデコを送り合うのはとっても楽しいので、まだの方はぜひ体験してみてください♪
ダウンロードはこちらから⇒ http://deco-link.jp/

また、スタンプのキャラクターでもあるデコりんが、twitterでデコの情報や日常をゆるくつぶやいているので、こちらもぜひチェックしてみてください☆
＜ よろしくリン♪https://twitter.com/DECOLINKbyAmeba

これからも多くのユーザーに愛されるサービスを目指して努力していきます。
引き続きDECOLINKをよろしくお願いします。

まずはたくさんのキーワードを用意する。

よく「かわいいデザイン」って聞きますが、「かわいい」という言葉を聞いてイメージするものが、全ての人にとって全く同じとは限りません。

「かわいくて〇〇」をキーワードで表現する

自分が持っている「かわいい」というイメージを表現するには、たくさんのキーワードで表現するとわかりやすくなります。
まずは、「20代の美を追求する人たちが使うアプリ」というテーマから連想する、〇〇に入りそうな言葉をたくさん並べてみました。
ガーリー、キュート、ラブリー、シック、クール、スタイリッシュ、ポップ、暖かいなど…

キーワードからロゴタイプをイメージする

フォントが持っているイメージはとても強いので、キーワードに合った適切なフォントを使ってロゴタイプをデザインしましょう。
有名なフォントとロゴに関しては、こちらが参考になります。

出した言葉から２つの軸を作りました。
軸1は「スタイリッシュ・力強さ・シック」←→「ポップ・キュート」、
軸2は「クール」←→「暖かい」です。

その後、色々なフォントからGIRLS UPと書いて、それを直感でグラフの上に並べました。GIRLS UPではポップでキュート、暖かい感じのCalibriというフォントのBoldを選びました。

もしここでスタイリッシュでクールな方向性になったら、スタイリッシュすぎて却下になりそうなデザインです。コミュニティサービスというよりはファッション誌的な印象を受けるこのフォントはDidotです。

デザインムードボード

ロゴタイプを決めたので、チームの人にどういうデザインにするか共有しましょう。しかし、デザインの方向性は決まったものの、アプリの画面はまだ１つもありません。
こういう時に、他の人にデザインのイメージを伝える方法でよく使われるのが「ムードボード」という方法です。
キーワードだけだとどうしてもズレが発生してしまいます。このズレを最小限にするため、既存の写真、ブランド、雑誌などがもっているイメージを借りてきてお互いが思ってる「カワイイ」を合わせる作業です。

GIRLS UPのムードボード

花柄、ドット、レザーテクスチャー、ハートや小物などでできています。なんとなくすごくピンクなアプリになる予感ですね。わたしはこういうデザインをするんだよと、あらかじめみんなに言っておくことで、ムダなやりとり・修正がなくなります。

カワイイ色味

その次は、実際アプリで使うメイン色を決めることです。ムードボードに使われている色からメイン1色を持ってくると便利です。
わたしは、このサイトを配色の参考にしました。Web配色のセンスがあふれる人は直感でやっても良いんですが、世の中の優れた人たちが良い配色の例をすでにたくさん出しているので、そちらを参考にすることもいいと思います。

この３色がGIRLS UPが考える一番かわいい色です！
ここで設定するメインカラーは２つ～３つくらいが適切です。
これを元にアプリ全体の画面を構成します。

アプリ構成

メインの色、フォント、デザインの方向性が決まってから、ワイヤーフレームに沿ってアプリアイコンと画面をデザインしていきます。これがGIRLS UPのアプリアイコンと主な画面です。

かわいい要素

①テクスチャー

女性のユーザに大切に使ってもらいたいという気持ちを込めた、かわいいピンクの革製の手帳をモチーフにして作っています。かわいくてさわりたくなります！！
そして、アプリの中身は、クレヨンで塗ったような、手描き感をイメージして作っています。

②装飾と説明

スタイリッシュで直感的なUIをしているかっこいいアプリもたくさんありますが、GIRLS UPでは「わかりやすい」「簡単にできる」を目指してデザインしています。初めて来た人がいかに使いやすいかを考えたデザインです。初めて来た人に簡単にツイートを促して、初投稿には目立つようにアイコンをつけて、「ほめてあげよう」という文言でたくさんほめられる一連の流れになっています。見た目だけではなくて、使う人を考えるかわいいUIです。

まとめ

GIRLS UPを参考に、かわいいアプリの制作過程について書きました。ぜひかわいいアプリ作りに挑戦してみてください！
ここまで読んでいただき、ありがとうございました。

最後に、GIRLS UPの宣伝をさせてください。

GIRLS UPってなに？

まだまだ改善していくので、楽しみにしてください＾０＾
【GIRLS UPの制作ブログ】
http://gupdesign.tumblr.com/

【GIRLS UPのスタッフブログ】
http://ameblo.jp/girlsup-staff/

Author : @abibibibi

ちなみに運用とは

ガールフレンドは2012年11月にリリースされました。

晴れてリリースされたサービスですが、ユーザーをいかに楽しませられるか、いかに飽きずに続けてもらえるか、常に改善と新しさが求められます。それに対して、ゲームをよりよくしていく為に行う事を運用と呼びます。

運用デザインの主なものは下記の点です。

・既存ゲームの改善と機能追加
・新カード(ガチャ)の追加
・イベントの開発と運用

今回はその中から「新カード(ガチャ)の追加」を、デザインの視点からいかにユーザーをわくわくさせるような魅せ方ができるかを私なりにご説明させていただきます。

カード追加やイベントをもりあげるロゴ

ガールフレンドでは登場人物の女の子が色々なテーマに沿って登場します。
クリスマス、お正月、節分、チアリーダー、ネココス、バレンタイン等等。
そのテーマに沿った世界観をロゴ等で表現します。

毎回違ったテーマとキャッチフレーズに、きちんとロゴを付けてあげる事で、新鮮さと、特別感、そして楽しさをユーザーに感じてもらえるようにします。

ただし、ガールフレンドの世界観から逸脱しないように制作するのがポイントです。

ロゴだけ見てもカードの世界観が伝わってわくわくできるような工夫をしています。

一瞬で伝えるバナーの制作

ゲームの情報を伝える上で欠かせないゲーム内バナー

バナーは「情報の看板」の役割を果たしています。そのため、バナーの制作で大事なことは、小さい枠の中でユーザーが一瞬さっと見ただけですぐそれが何なのか頭に入るよう、伝えたい事の優先順位づけをしっかりと大げさにすることです。「伝えたい事」は２通りに分けられると考えています。

①イベントの世界観を優先して伝える
②ユーザーにとってオトク情報を優先して出す

※この二つをどう出し分けるかというと、
上記で作ったようなロゴがある時、(ガチャ追加時、イベント)は①の世界観を前面に押し出すようにしています。特別感を感じてもらう為、オトク情報が一緒にあったとしても、世界観を優先します。

逆に、そういったものがなければオトク情報をとにかくめいっぱい出してあげます。
またこの２パターンを分ける事で、多く並ぶバナーの差別化をはかります。

パターン1　イベントの世界観を伝える
例）にゃんこのお願いキューピッド

①世界観→にゃんこのお願いキューピッド
②オトク情報→追加SR4倍
③オマケ情報→期間限定

パターン2　ユーザーにとってオトク情報を優先して出す場合
例）2012年大感謝キューピッド

①オトク情報→元気炭酸12個
②世界観→2012年大感謝キューピッド
③オマケ情報→10連限定

一番大事な「元気炭酸12個」を目立たせるため、他の情報は小さな文字だったり、イラストのみで表示しています。
強弱をつけずにたくさん情報を載せすぎると、大事な事が一瞬で頭に入ってこないのでNGです。

表現の方法は様々です。

例えばこのように、わくからはみ出したように見せたり、
gifアニで「レア鬼出現」のところを点滅させました。その理由として、要素が多くてごちゃごちゃして静止にすると情報の優先度がわかりづらいということと、また、世界観を大事にした上で大事な情報として目立たせるためです。

全部伝えるわかりやすいランディングページ

バナーという看板から入って来たら、メニューを見せてあげる場所がこちらランディングページ、通称「LP」です。
ここですべての情報を提供しますが、情報を羅列するだけではありません。デザインの見せ方のポイントが３つあります。

①上に大事な情報を持ってくる
②要点で区切る
③文字は少なく、目立たせたい情報は大きく表示

例）にゃんこのお願いキューピッド

①ヘッダー
世界観を全面に出し、ページのタイトルを表します。女の子達はみんな、バラバラの状態で描かれているので、距離感や角度等気をつけて、同じ空間にいるようにみせたり、配置を施します。

②ボタン
ファーストビューに一番大事なボタンを配置します。これはとても重要なことで、ユーザーを迷わせないようにするためと、煩わしさをなくすためです。

③報酬
メインでもらえるものを一番大きく配置します

④一覧
もらえるものを一覧で見せます。

⑤もらえるおまけ
オマケのオトク情報を記載します。文字をたくさん書くより、絵やメインとなる文字を端的において、わかりやすくする工夫をしています。

この他にも、キューピッドのページ自体にも、上部にLPを凝縮したヘッダーをおいたり、アイコンをイベント用に変更して、変化を感じてもらう工夫をしています。

最後にまとめ

長くなりましたが、以上がガールフレンド(仮)における運用デザインの一部です。
この他にもイベントの開催や、常にユーザーがより楽しく使いやすいゲームになるべく、日々UIの改善や、機能追加を行っております。

最後までお読みいただき、ありがとうございました。


ガールフレンド(仮)はこちらから⇒http://vcard.ameba.jp/

スマートフォン版Amebaとは

スマートフォン版Amebaとは、Amebaがスマートフォン向けに展開しているサービスの中心となるプラットフォームサイトです。

Amebaにはたくさんのゲームやコミュニティサービスがあり、プラットフォームサイトはそのハブになっています。
それぞれに一覧や特集ページが用意されている上に、掲示板などプラットフォームサイト独自のコンテンツも持っているため、全体として非常に大規模なウェブサイトになっており、そのページ数は優に200を超えます。
この膨大な数のページのデザインを作成していく際に、1ページ1ファイルで管理していくのは効率が悪い、というかほとんど不可能に近いです。
そこで、Amebaのデザインチームでは、Fireworksを使ってサイトデザインを効率良く作成・管理しています。

Fireworksの長所

Amebaで使用しているのはAdobe Fireworks CS5.1です。
Webデザインの現場ではPhotoshopを使っている人も多いと思いますが、AmebaではFireworksを採用しています。
Fireworksは、大規模サイトのデザイン制作に非常に向いているからです。

Fireworksを使うメリットは大きく2点あります。
1点目は、リッチシンボルの活用によるデザインパーツの一元化が可能であること。
そして2点目が、ページ機能とステート機能によって複数のページを1ファイルで管理できることです。

この2点のメリットについて、実際のデザインファイルを例に説明していきたいと思います。

デザインパーツを一元化する

Amebaは膨大なページ数を有するサイトですが、全体を通してデザインのテイストは統一されていなければなりません。
そこで自然と、同一・類似デザインのパーツを何度も使うことになります。
この時に便利なのがシンボルです。
よく使うデザインパーツをシンボル化しておけば同一パーツの管理・デザイン変更が楽になります。
例えばAmebaで頻繁に使っているこのボタン。

このボタンも、背景をシンボル化しています。
この画面内のボタンの背景と枠線の色を変更してみます。

1つのシンボルをいじるだけで、

そのファイル内のすべてのボタンに変更が反映されます。

このシンボルに応用性を持たせたものがリッチシンボルです。
リッチシンボルとは、簡単に言うと、色やテキストなどの設定をいじれるようにしたシンボルのことです。
デザインパーツをリッチシンボルにしておくと、複数の類似パーツを単一シンボルで管理することができるようになります。
再びさっきのボタンを例に見てみましょう。
Amebaでは同一デザインのボタンにカラーバリエーションがあり、用途に応じて使い分けています。

デザインファイル内ではこれを1つのリッチシンボルにまとめて管理しています。
選択ツールでボタンのシンボルを選択すると、シンボルプロパティウィンドウに変更できるプロパティ（設定）が表示されます。

今回の場合は、プロパティ「type」を変更することで、ボタンの色を変えることができます。

このように、普通だったらカラーバリエーションの数だけシンボルを作らなければならないところを、リッチシンボル化することによって、たったひとつのシンボルで管理することができます。

複数ページを1ファイルで管理する

複数のページや条件分岐を1ファイルにまとめることができる機能がページとステートです。
【ゲーム】のページのデザインファイルを例に実際に見ていきましょう。

game.pngを開きます。

ページウィンドウを見ると、01～08の8つのページに分かれています。

これらは、それぞれが独立したページのデザインです。
このファイル内だと、ページ03【game_top_normal】が【ゲーム】のトップページです。
そして、このページの中の「恋愛」ボタンをタップして遷移した先のページのデザインが、ページ07【game_category_list_renai】に入っています。

このようにページ機能を使うことで、関係する複数のページを1ファイルにまとめることができます。

ファイル内の各ページはステートを活用することで、更に細かい場合分けが可能です。
ページ04【game_top_app】を見てみましょう。

ステートウィンドウを見ると、このページには【default】と【popup】の2つのステートが設けられていることがわかります。
ここでは【default】で通常時、【popup】でポップアップ広告表示時の状態を見ることができます。

このように、ステート機能を使うことで、より細かい場合分けを管理することができます。

※注意点
ページとステートを多用するとファイルが複雑化します。
混乱を防ぐために、「ページは遷移」「ステートは条件分岐」など、ルールを設けて使うことをおすすめします。

ページ、ステート機能の応用例

ページ、ステートは、場面に応じて工夫することで更に便利に使うことができます。
最後に、Amebaのデザインチームで実際に使っているステート機能の応用例をご紹介します。

■ A/Bテスト

A/Bテストとは、1つのページを、デザインや内容が微妙に異なる「Aパターン」と「Bパターン」に分け、どちらのUIがよりユーザーに使いやすいかをテストする手法です。
それでは数ヶ月前のgame.pngを開いてみましょう。

今の【ゲーム】のページと全然違いますね…。
Amebaは日々改修の連続で、UIもどんどん変化しています。
この頃は特に怒涛の改修ラッシュで忙しかった…。

さて、このページはステートで【01_ranking】と【02_vs】に分かれています。
この2つを見比べてみると、上段の一部コンテンツだけ
別々のものが入っていることがわかります。

この2つを同時に公開し、ユーザーの反応が良かった方を採用する、
の繰り返しでUIの改善を進めていきます。
ステートを利用することで、A/Bテスト用のデザインを効率良く整理することができます。

最後に

このように、大規模なウェブサイトのデザイン制作においてFireworksはすごいパフォーマンスを発揮します。
スマートフォン版Amebaでは、これからもツールのポテンシャルを活かして、スピード感のあるUI改善を進めていきたいと思います。

最後までお読みいただきありがとうございました。

今回はミルチョの中で最重要とも言えるボタン「きいてよ！ボタン」の制作エピソードをメインに、UIデザインについて考えていることやポイントなどをお話できたらと思います。

「UI」って何？

UIとはユーザーインターフェース（User Interface）の略です。
ユーザーが何か行動を起こす時に使えるボタンなどを提供してあげて、
その行動の結果をユーザーに見える形で表示してあげる。これが役割です。

といったかんじで説明すると何だか難しいかんじですが、
ミルチョの場合はもっと簡単に考えています。

ミルチョの住んでいる畑（？）と僕たちが今生活している世界。
この間に挟まってて、ミルチョの世界と僕たちの世界をつないでいるのがUIです。
間にあるものだから、きちんと操作できるのはもちろんのこと、ミルチョの独特な世界観も踏襲して、ユーザーが世界に入りこんでいけるようなデザインになるように心がけています。

きいてよ！ボタン

僕がミルチョチームに入って1番最初に苦戦した作業が、きいてよ！ボタンの作成でした。
 きいてよ！ボタンは、押すとテキスト入力画面が立ち上がり、どーでもいいひとりごとを投稿すると、ミルチョや他のユーザーがきいてくれます。

ミルチョというコミュニティサービスを成立させるためには、
1番使われるべきボタンだと思います。

社長との会議で「コアな機能だから、もっと目立たせた方がいい。」という話があり、
本格的にデザインの改修に入りました。

改修前のきいてよ！ボタンはこんなかんじ↓

ルールを破る

とりあえず考えつくだけのボタンのパターンを用意しました。

しかし、どれもわざわざ変えて効果が見込めるほどの違いのあるボタンにはなりませんでした。

そんなダカイ策が見つからないでいる僕に、
先輩デザイナーのサトウさんが声をかけてくれました。

「こういうプラスチックみたいなボタンが、真ん中にどーんと置いてあったら押すよね。」

た、確かに…

でも、ミルチョのUIでは今までそんな処理やパースをかけたことはないし…。
いわばミルチョのUIの中ではルール違反のボタンです。
しかし、ミルチョの世界の中にたった１つだけルールを破ったボタンが置いてあれば、
ユーザーが一番気になるボタンにはなると思いました。
その「異物感」を不快なものでなく「良い意味での異物感」になるようにするのは
デザインの課題でした。

きいてよ！ボタンを作る

まずは、パースや処理でルールを破る分、
ボタンの形自体は、ユーザーのひとりごとをフワフワ浮かべている雲から引っ張ってくることにしました。ボタンの形は、イラストレーター上でパスで作ります。
（拡大縮小に影響を受けず、編集にとっても便利！） 

ボタンの上面と側面でかける処理が異なるため、パーツを分けておきます。

作ったパスデータをフォトショップ上に持ってきて処理をかけます。
モチーフを参考にしながらたくさん処理をかけて、
目で見ながら濃さを調整したり効果的でない処理を削ったりしていくやり方が好きです。
（少々時間はかかりますが...）

ここでプラスチックっぽい質感に見せるポイントは、
エッジにかけた光沢処理とパッキリとしたハイライトです。
これがないと立体的ではありますが、質感はプラスチックっぽくありません。

そして、出来上がったボタンに最後のひと工夫、押したときの処理を加えてあげます。

この２枚をユーザーが画面をタップしたときに切り替えてあげることで、
ギュッと押した感（リアクション）が出て、ユーザー体験が向上します。

最後に

こうして完成したきいてよ！ボタンは、
30万人を越えるユーザーに、通算280万回押されているボタンになりました。
（※累計きいてよ数参照 2012年12月現在）

ゆる～いデザインのミルチョですが、
ユーザーにそのゆる～い体験を続けてもらえるように
今日紹介したきいてよ！ボタンをはじめとして日々様々な改良を続けています。

「ど～でもいいひとりごとでゆる～くつながる新感覚コミュニティ きいてよ！ミルチョ」
これからもよろしくおねがいします！→ http://mirucho.me
（まだの人はこれを機に始めて、きいてよ！ボタンを押してみてください！）

最後まで読んでいただきありがとうございました！

CSS開発のアプローチ

ほぼ同時期にモダンウェブ開発に欠かすことが出来ないと言われるようになったJavaScriptと比べると、CSSにおける設計、という話題はなかなか出てきません。

単純なウェブサイトを作る際にはあまり気にしてこなかった部分ですが、ウェブアプリを制作している我々の仕事には欠かすことが出来なくなってきています。

ほかのプログラミング言語に比べると圧倒的に非力な言語だからこそ、ほかのプログラミング言語でも重要と考えられているDRY(Do not Repeat Yourself)や、メンテナンス性、そして柔軟性を考慮した設計がより重要だとも言えると思います。

今回はそれらの原則を実行するために必要なコンポーネントについて紹介していきたいと思います。

コンポーネント

コンポーネントイメージの図

オブジェクト指向CSS(OOCSS)、Scalable and Modular Architecture for CSS(SMACSS)という単語を聞いたことがあるという方も多いでしょう。
今回紹介するコンポーネントとは、CSSにおけるオブジェクトあるいはモジュールと同じものだと考えてください。
※CSSにおけるオブジェクト、モジュールについては、Scalable and Modular Architecture for CSS(SMACSS)という本もあります。こちらについては現在私の方で和訳をおこなっています。

90年代のウェブサイトと比べると現代のウェブサイトには非常に多くのパターンを見つけ出すことができるようになりました。
コンポーネントとはそれらのパターンと言い換えることが出来ると思います。

ウェブサイトに限らず、人間はパターンを好む生き物です。心理学、神経科学のジャーナリストであるジョナ・レーラー氏は著書『一流のプロは「感情脳」で決断する​』でこのように述べています:


ドーパミンは快楽と結びつきが強いと考えられているホルモンだということなので、人間はパターンを好むという意見の裏付けにもなっています。
コンポーネントアプローチはユーザにとっての『使いやすさ』を補強するだけではなく、我々開発者にとっても有益に働くことが多いWin-Winのアプローチです。

1. ヴィジュアルパターンを抽出し、抽象化することでコードの繰り返しを避けることが出来ます。このことがDRYの原則を守ることにつながり、結果的にコードの絶対量を減らすことが可能になります。




2. 抽象化されたコードは拡張性に優れていることから、柔軟性も高くなり、結果的にモダンウェブ開発では欠かせないイテレーションを素早く回すための基礎として優れていると言うことが出来ます。




3. 1)と2)であげた特性はメンテナンス性を高めるために必要な要素です。またこの後で紹介するコンポーネントアプローチを行うためのワークフローを活用することでより強固なメンテナンス性を得ることが出来ます。

ビジュアル言語とも言えるCSSに効率性を求めるのは非常に難しいとされてきましたし、そのCSSの基礎である記述性が失われたわけではないため簡単なことではありません。
どんなコンポーネントがウェブサイトにはあり、それらをどのようにコード化していくのかを見ていきましょう。

コンポーネントリストとコード化

コンポーネントの最もわかりやすい例はボタンだと思います。
試しにGoogleで「CSS ボタン」と検索してみてください。驚くほどに多くの情報があるはずです。ボタンには様々なバリエーションがあります:

• サイズ
• 色
• 形
• 状態(:hoverや:focusなど)

などがバリエーションの糧となる好例でしょう。

小規模のウェブサイトにも状態を含めたボタンのバリエーションは20くらい、最低でも10はあるはずです。CSS3の登場により、それらのバリエーションをコードだけで実現できるようになった代わりに、すべてのバリエーションを個別のコンポーネントとしてコーディングしてしまうと無駄の多いコードを生み出すことになってしまいます。

典型的なボタン(:hover、:activeの状態を含む)のCSS例: 

.login {
  padding: 10px 15px;
  background: #4479BA;
  color: #FFF;
  -webkit-border-radius: 4px;
  -moz-border-radius: 4px;
  border-radius: 4px;
  border: solid 1px #20538D;
  text-shadow: 0 –1px 0 rgba(0, 0, 0, 0.4);
  -webkit-box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.4), 0 1px 1px rgba(0, 0, 0, 0.2);
  -moz-box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.4), 0 1px 1px rgba(0, 0, 0, 0.2);
  box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.4), 0 1px 1px rgba(0, 0, 0, 0.2);
  -webkit-transition-duration: 0.2s;
  -moz-transition-duration: 0.2s;
  transition-duration: 0.2s;
  -webkit-user-select:none;
  -moz-user-select:none;
  -ms-user-select:none;
  user-select:none;
}

.login:hover {
  background: #356094;
  border: solid 1px #2A4E77;
  text-decoration: none;
}

.login:active {
  -webkit-box-shadow: inset 0 1px 4px rgba(0, 0, 0, 0.6);
  -moz-box-shadow: inset 0 1px 4px rgba(0, 0, 0, 0.6);
  box-shadow: inset 0 1px 4px rgba(0, 0, 0, 0.6);
  background: #2E5481;
  border: solid 1px #203E5F;
}

この例では、ログインボタンそのものと:hover、:activeの状態バリエーション、合計3つのバリエーションを作りました。
もし赤いボタンがあったら、または緑のボタンがあったら、例ではコンテンツに応じてサイズが変わるボタンとなっていますが、固定幅サイズのボタンがあったら、と考えると、コードには無駄な部分が多いと言わざるを得ません。私の経験から言うと、間違いなくそれらのバリエーションは開発のどこかのタイミングで発生します。

それではこのコーディングのどこに問題があるのか、抽象化の作業を順を追って見ていきながら説明していきましょう。
まずはクラス名.login。

HTML5の仕様書のクラスに関するセクションでも:

・・・著者はクラス属性をコンテンツに求める見た目を説明する値ではなく、 コンテンツ自体の特性を説明する値を利用すること。

とあるように、セマンティックであることをベストプラクティスであるとしています。

クラス名.loginは確かにセマンティックであると言えますが、.logoutボタンがあったとして(ほぼ確実にあるはずですが)、それら2つの要素に共通するパターンはないでしょうか？ユーザもその直接的に関連する2つの要素に対して一定のパターンを期待するはずです。
しかし、コンテンツ派生のセマンティック性にこだわったクラス名を付けてしまうことで、その2つの要素には共通のコードを存在させることは重複したコードを記述することを意味してしまいます。
もちろん、CSSプリプロセッサのSassやStylusにあるextendという機能を使ってこの問題の回避を行うことは可能です。しかし同様にCSSが元々持っている機能でも回避することも出来ます。

単純に.buttonクラスに共有するコードを定義すればよく、バリエーションを2つ目のクラスで定義しすることでも問題を解決できます。

.button.login、.button.logoutのようにすることで、.loginと.logoutが持つ共通のコードは.buttonに担わせることが出来るわけです。
先ほどの.loginボタンから.bottonのベーススタイルを分離してみましょう。

.button {
  padding: 10px 15px;
  background: #808080; /* デフォルトカラーとしてグレーを定義 */
  -webkit-border-radius: 4px;
  -moz-border-radius: 4px;
  border-radius: 4px;
  text-shadow: 0 –1px 0 rgba(0, 0, 0, 0.4);
  -webkit-box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.4), 0 1px 1px rgba(0, 0, 0, 0.2);
  -moz-box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.4), 0 1px 1px rgba(0, 0, 0, 0.2);
  box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.4), 0 1px 1px rgba(0, 0, 0, 0.2);
  -webkit-transition-duration: 0.2s;
  -moz-transition-duration: 0.2s;
  transition-duration: 0.2s;
  -webkit-user-select:none;
  -moz-user-select:none;
  -ms-user-select:none;
  user-select:none;
}

.button:hover {
  text-decoration: none;
}

.button:active {
  -webkit-box-shadow: inset 0 1px 4px rgba(0, 0, 0, 0.6);
  -moz-box-shadow: inset 0 1px 4px rgba(0, 0, 0, 0.6);
  box-shadow: inset 0 1px 4px rgba(0, 0, 0, 0.6);
}

今回ベースとなるコンポーネントは色の違いによって拡張されるという定義にしています。.loginボタンが青だとしたら、それに関連するスタイルのみを定義すればよいことになります。こうすることで.logoutボタンの拡張も簡単に行うこと出来ます。
DRYであり、拡張性も高く、メンテナンス性にも優れたアプローチだといえるでしょう。

3バリエーションのボタン例

ウェブサイトが変わってきたのであれば、ワークフローにも転換が必要

今回は例としてボタンというもっともわかりやすい例を取り上げましたが、ウェブサイト、あるいはウェブアプリケーションにはボタンのほかにも様々な再利用できる要素があります。
それら要素をコンポーネント化し、コード化するのにもっとも優れた方法がコンポーネントリストページを作成することです。

HTMLもバージョンが変わり、CSSも同じようにバージョンが変わりました。JavaScriptも初期のウェブに見られた単純なトリック的な要素を扱う言語から、アプリケーション言語として転換を果たしています。しかし、ウェブサイトを制作するフロントエンドのワークフローそのものは大きく変わっていないのが現状です。

ウェブサイトを支える技術に転換があったのであれば、それに即したワークフローが必要だと考えています。

その1つがコンポーネントリストページです。
コンポーネントリストページとは簡単に言うと、ウェブサイト、ウェブアプリに必要なコンポーネントを一枚のページにまとめてコーディングしたものです。

メールマガジン発行ツールを提供しているMailChimpの例(画像の例ではありますが)がその好例です。

スタイルガイドというように呼ばれることも多いですが、この記事ではコンポーネントリストページと呼ぶことにします。ガイドラインというとどうしても作る方も見る方も構えてしまいますが、リストページであれば、単なるリストとしてとらえて考えることが出来ると思うからです。(最終的にスタイルガイドとよばれるドキュメントになっていくのですが。)

デザイナからベクターデータが届いたら、まずそのデータ通りにページをコーディングするのではなく、コンポーネントリストページにコーディングをしていきます。
初期の段階ですべてのパターンや拡張性について考える必要はありません。文章を書くのと同じで、まずは考えていることを書き出してしまうことが大切なことであり、文章と同じく推敲を重ねることがパターンとしての抽象化を適切に行うもっとも効率的な手段です。

アーネスト・ヘミングウェイ氏が言うとおりに『第一草稿はどんなものでもいまいちである』なのです。

すべての要素を1ページに収めてコーディングを行うことにはいくつかの利点があります。

1. CSSの結合時に問題が起こらない。1ページにすべての要素があるわけですから当然ですが、ページごとにコーディングを行うことに比べて、クラス名の衝突などが起こらないため、仮にCSSファイルが分離されていても問題なく結合することが出来る。HTTPリクエスト数を減らすことはページロード速度の最適化にとって基本となっていますので、思っている以上に効率がよい方法です。
   


2. CSSのテストが可能なページを作れる。どんな熟練の開発者でもCSSのカスケードを完璧に制御することは出来ません。どんなプログラム言語でも、実装に伴うテストの手法が確立されているものですが、CSSではなかなか難しいのが現状です。コンポーネントリストページを作ることで、その『当たり前』をCSSに取り込むことが出来ます。

私自身このコンポーネントアプローチを数年実践して来ていますが、すべてのパターンを見いだすことは当然出来ませんし、今後それらのパターンを瞬時に見極められるとも思いません。

まずページとしてコード化する前に、コンポーネントリストというプロトタイプを作ることで、『ああ、またこのパターンがあるのか、でも面倒だからこのままでいいか』という部分を減らすことが出来ると思います。

ウェブサイトはもはやページの集合体ではなく、様々な機能を有するシステムとして捕らえるべき存在です。ウェブページがシステム全体を構成する1つの機能であるとしたら、そのウェブページを構成する要素はシステムを構成するために必要不可欠なパーツとなります。
パーツのみを上手にデザインできてもシステムとして正しく動作するかは保証されませんし、機能だけが単品で存在していてもシステム全体としてのフローの中に組み込まれなければ意味をなしません。

最後に、これからのフロントエンドデベロッパにはどんなパーツを作る方法を知っているか、というトリビア的な技能だけではなく、どんなパーツが手元にあり、それらをツールとしてどう活かしているかが求められると考えています。
上手に抽象化されたコンポーネント/パターンはどんな種類のウェブサイト、ウェブアプリケーションにも適応することが出来ます。ある要素を『どう作るか』よりも、より本質的な『何が問題となっているか』そして、『どう解決するか』にフォーカスをすることがよりよいサービスを作るために必要な質問ではないでしょうか？
そんな質問をし始めるのに必要なきっかけがこのコンポーネントアプローチという考え方だと思っています。ものすごく概念的な話に終始してしまいましたが、手元の作業に集中するだけではなく、全体を俯瞰して開発を考えるきっかけになれば幸いです。

参考リンク

• OOCSS and Preprocessors in a tree, K-I-S-S-I-N-G by Nicole Sullivan
• パタン・ランゲージ―環境設計の手引​ by クリストファー・アレグザンダー
• 一流のプロは「感情脳」で決断する​ by ジョナ・レーラー
• About HTML semantics and front-end architecture by Nicolas Gallagher
• On HTML and CSS best practices by Harry Roberts