「AWA」のデザインはどのようにして作られたのか。

久しぶりに1ぴくで更新が掛かりましたね、為になる内容なので、保存しておきます。
http://ameblo.jp/ca-1pixel/entry-12042291572.html



こんにちは。
AWAでアートディレクション/デザイン/ブランディングを担当しているムロハシと申します。

今回はAWAのUIデザイン、インタラクションがどのようにしてつくられたのか、 先日行った「 メディアプロデューサー養成講座」の講義内容をベースに、 簡単ではありますが書いていきたいと思います。
o0600042013344459424.png

「AWA」とは?
o0800047413344460282.png

AWAとは、ひとことで言うと
「登録なしですぐに音楽が聴ける定額制の音楽配信アプリ」です。

サービスの特徴として第一にあげられるのは、
・好きなアーティストを聴くだけでなく「プレイリスト」を軸に、自分の好みにあった音楽が「リコメンド」されること
リコメンドを通じて「昔好きだったあの曲」や「まだ知らなかったけど好きな曲」を一人ひとりにパーソナライズしてお届けしています。

そのほかの詳しい説明は プレスリリースをご覧いただければと思います。

インタラクションモックの重要性
AWAの初期の開発チームの体制は以下です。
o0800061913344465064.png

チームの結成は2014年8月。 実質プロデューサーは、6月から市場調査やサービスの企画など、結成前の母体となる軸を考えていたとのことです。 デザイナーである私がジョインしたのは結成から2カ月後の10月でした。

ここからの2カ月間、仕様設計とデザインを同時並行で進めていき、デザイン自体は12月末の時点でほぼ完成しました。

この期間、自然に、 デザインと同時にインタラクション専用のモックをつくる体制 に変化していきました。

デザイナーは、インタラクションのイメージをもってデザインをしているのは当然なのですが、 実際どう動くかは、またその動きにどんな体感を得るのかは「動かしてみないとわからない・・・」というのが常に悩みでした。

簡単な動きであれば、FlashやAfterEffects、最近では Pixateなどのツールをつかって共有ができるのですが、 こだわりの強いインタラクションになればなるほど、数ミリ秒のズレで「得る体感」が全然違います。

ここを調整していくにはツールでは限度があり、やはり実際のコードで表現するのが一番だと思います。
AWAでは、この部分を デザイン制作の段階でエンジニアと常に話しながら 同時並行で進められたことが、とても大きかったです。

また、毎日チーム全体で2時間近い夕会を行い、デザインやインタラクションの議論を行いました。 ここでチームメンバーの意見を聞いたり、こだわりを話し合ってデザインが進んでいきました。

本番実装までイメージのズレがなく進められたのも、この議論のおかげだったと感じています。

モック開発からデザインの軸が見えてきた
すこし話を戻して、デザイナーが加入前の2カ月間は、 エンジニアが主体となって各々が思うアプリをイメージしてモックづくりをしていました。

サービスの仕様も決まっていたのは「パーソナライズされた音楽がリコメンドされる」ということだけ。
デザインももちろん存在していないので、すべてバラバラです。

実際のモックは以下のようなものです。
o0800056013344475438.png
o0800056013344475437.png
手探り状態でのモック開発でしたが、モックは動かないデザインと違って実際に触って動かせるので、 その体感から「いいところ」「悪いところ」が見えてきました。

とくにインタラクションではデザインを決めていく部分ですごく参考になりました。
たとえば、
・視差効果(パララックス)は、使う箇所で良くなったり悪くなったりする
・動きのインパクトを重要視するのではなく、統一性と洗練性で全体的な心地よさになる
・インタラクションは言葉で説明せずに動きで理解させることができる
といったことです。

こういった発見をもとにデザインを進めていきました。

その過程で見えてきたのが
「デザインやインタラクションにおいて矛盾をつくらない」 ということ。
たとえば、AWAでプレイリストを見るときに、「プレイリストのサムネイルは、進むときも戻るときもおなじ動き」 をします。

バックボタンは当然ですが、iOS標準のエッジングバック(画面の端から右にスワイプすること)を行っても同じサムネイルの動きをさせているのがその特徴です。

o0539096013344482590.jpg
(背景部分は右に移動し、サムネイルは残った状態にする)

なぜそういった実装がされているのかというと、ページが進んだときは サムネイルが浮いて表示 された のに、戻るときに 一緒に右に戻ってしまった ら、ちょっとした違和感を残してしまうからです。

ほんの小さな矛盾ですが、こういった矛盾が積み重なるとアプリ全体で大きな矛盾になってしまいます。
この「矛盾をつくらない」という軸が、どんなインタラクションにするのかを考える、ひとつの基準になりました。

デザインで実現したいこと
もともとプロデューサーからデザインの要望として、
・今までにない、とにかくクールでかっこいい
・海外のアプリのようなインパクト
・考えないで感覚的に使える
といったものがありました。

ここで非常に難しかったのが、 「今までにない」というUIと 「考えないで使える」というUI。

UXの分野になりますが、「考えないで使える」ということを実現させるには 「よく見かけるUI」を採用することが一般的な考え方です。 たとえば、Facebookでよく見かけるUIだったら、Facebookユーザーは考えなくてもわかるUIだ、ということです。

でも、AWAでは「今までにない」という要望もあります。

なので、AWAのデザインで実現したいことを言語化すると、
「誰もが見たことないインターフェイス」でありながら 「操作が直感的で、感覚的に使えること」
となります。

私はこれを「人に薦めたくなるデザイン」というように置き換えました。

・今までにないインパクトだけのデザインだと、操作が難しくて人に薦めにくい。
・よくあるインターフェイスだと、すごく良い機能でない限り積極的には人に薦めない。

しかし、「インパクト」かつ「使いやすい」が共存さえすれば、
積極的に人に薦めたくなる、人に見せたくなるのではないか、と考えたのです。

そのための「見た目の斬新さ」だったり、「iOS, Androidで差をつくらないつくり」が必要だったり、 デザインで表現、工夫、解決すべきところが徐々に見えてきました。

デザインにおいて、ユーザーにどんなことをしてほしいか、どんな風に感じてもらいたいか、このあたりを念頭に考えると、自ずと実現したい方向性が見えてくるのかもしれません。

デザインには右脳と左脳が必要

実はもともとジョインした10月の時点で、ある程度のデザインが仕上がっていました。
それがこちら。
o0800047613344487600.png

デザインは違えど、これが現在の遷移構造やメニュー表示のベースになっています。
こちらをもとに、まず私がデザインしたのがこちら。
o0800056013344494469.png

前述のモックもまだ見ていなくて、デザインの軸もなにも決めていない状態で考えたものなので、かなり粗が目立ちますね。。

これは 自分の感覚だけでデザインすることで、インターフェイスの発想を広げたかったのが狙いです。

フォント、マージン、ブラー処理など、実装上の都合は全く考えず、余計な固定概念を取っ払って、まずはデザインをしておきたかったのです。
このとき、なんとなくですが、ジャケットを主役にしていこうと考えていました。

なぜジャケットを主役にしようと思ったのか。

それは 「ジャケット自身がすでにアーティストのこだわりによってデザインされたもの」 だからです。
なので、アプリのデザイン都合で、ジャケットが目立たなくなってしまったらいけないな、と考えました。(この段階ではメイン画面でもジャケットを全面背景にしていますね)

こういった右脳だけで作ったデザインをもとにしてチームと議論をするなかで、 ベースのデザインが決まっていきました。
そして実際の画面はこちらになります。
o0539096013344499416.jpg

ベースのデザインができた段階で、ここから今後はアプリ全体の構造を考えました。

この構造は、アプリ内の画面が、どのレイヤーにいるかを図式化したものです。
このあたりから矛盾がないようなつくりを意識し始めました。左脳の出番です。

デザインルールも、全体のデザインがある程度出来上がってから作っていきました。
o0600116013344521160.png

普通は、デザインルールを決めてからデザインするのかもしれませんが、 それだと左脳をつかったデザインしかできません。
最初にルールを固めてしまうと、そのルールを超えたデザインにはならない、と思ったのです。

このルールも絶対的なものではなく、制作過程で「もっとクオリティがあがる」と判断したものはどんどん変更していきました。
たとえば、アイコンやフォントサイズなどもこのルールからすこし変更している箇所があります。

右脳をつかって出来上がったデザインに対して、 左脳をつかって構造やルール付けをしていき、全デバイスへ統一をしていく。

この作業は効率は悪いのかもしれませんが、エモーショナルなデザインをつくる場合においては重要なのではないかと思います。

ロゴについて
前述のラフデザインを見て「あれ?」と思ったひとも多いかと思いますが、 AWAは開発当初はRobinと呼ばれていました。

AWAというネーミングは、弊社社長の藤田がつけた名前ですが、「線対称」という文字の見た目の良さで決めていて、その言葉にとくに深い意味はありません。
o0540096013344524558.jpg

(参照:755「 藤田晋のトークライブ」)

なので、AWAのロゴマークもその文字自体のつくりを生かして、ほとんどいじっていません。

実はけっこうなバリエーションで作成したのですが、意味をつければつけるほどAWA自体の強さが弱まっていく感じがあり、 形を変えれば変えるほど別の印象を与えてしまうことにもなり、「クセのない強くて太いフォント」を綺麗にするのが一番だと判断しました。

フォントについて
「AWAのアプリ内で使っているフォントって何?」とよく聞かれるのですが、 デバイスフォントのほか「Mplus」というフォントと「Tex Gyre Adventor」というフォントを使っています。

ベースで、デバイスフォントを使いながら、 AWAを印象づけるメイン画面は、Mplusの細いフォントを使い、タイトル名を大きく見せる表現をしています。 ただし、細いのでセクションヘッダーなどではちょっと弱い。 そこでアクセントとして「Tex Gyre Adventor の Bold」を利用しています。

これらのフォントとデバイスのフォント、合わせて3つのフォントをうまく使い分けることで、 いろんな表現を可能にしています。

アイコンやパーツ部分の画像について
iOSとAndroidで、差がないようにデザインしながらも、「まったく同じにするのも実はよくないのでは?」と考えました。
その一つがアイコンやパーツ部分の画像です。

AWAのAndroidアプリ内のすべてのアイコンは、 マテリアルデザインの標準としてGoogleが配布しているアイコンを使用しています。

標準のアイコンにすることで、Android自体の世界観を崩さず、かつ見慣れたアイコンで、ユーザーに迷いなく使ってもらうのが狙いです。
シャッフルボタンやリピートボタン、ラジオのボタンなど、よく見るとiOSとは違うデザインになっています。

iOSでも標準のアイコンを基本としていますが、iOSの場合は各アプリのオリジナリティも必要になります。
なので、一般的な機能のアイコンはメタファーを合わせながらも、 AWAの世界観に合わせて、ひとつひとつ作成しています。

作成方法は、最近は当たり前になっている「Sketch」をつかっています。
全体のデザインはPhotoshopをベースとしていますが、アイコンやパーツ部分はデバイスごとでサイズが変わってくるので、 Sketchが非常に効率的です。

また、アイコンやパーツの画像のほか、背景画像やジャンルなどの画像、スプラッシュの画像など、 すべてをひとつのデータで管理できるので、そういった使い方としても有効でした。
o0640047413344535013.png

(SketchデータのiOSアイコン群)

最後に
AWAは、デザインやインタラクションで注目されることが多いですが、これが実現できたのも優秀なエンジニア、デベロッパーがいたからこそです。
デザインについては、本当に毎日毎日議論をして変化していきました。
まさに「チーム全員でつくったデザイン」だと思っています。

また、リリース前にもたくさんの方々にテストユーズしていただき、本当にいろいろな意見をいただきました。
ローンチの最後の最後までデザインに粘ることができたのも皆様のおかげです。

AWAのサービスは、まだ始まったばかりです。
ローンチしてみてわかった部分、至らない部分などが浮き彫りになっています。
さらに世界のアプリデザインに目を向ければ、もっと良いデザインはいくらでもあります。

ですので、これからも気を引き締めてデザインをしていきたいと思います。

非常に長いブログになってしまいましたが、最後まで読んでいただきありがとうございました!

0 Comments

Add your comment