シンプルなUIを実現するためにできること


僕は、シンプルで使いやすいデザインが好きだ。
多くのデザイナーも同じ考えだと思うけど、積み上げられた意見を反映した結果、シンプルとかけ離れたデザインになる事も多い。

デザインやディレクションを仕事にしていると、例えば

  • チームメンバー、同僚デザイナーからのインプットが多く、絞り込めず納得感を持たせるためにやむをえず盛ってしまう
  • 終盤で仕様漏れが発覚し、初期設計からズレるが時間が無く暫定対応になる
  • 偉い人の指摘で抜本見直しが必要だがスケジュールは変わらず中途半端になる

一度くらいこんな経験をしたことがあると思う。

後出しで要件が追加されると2歩後退してやり直すか、時間の猶予が無いと暫定的な突貫対応になるため本来の実力が出せず不本意な結果になる事も多い。
そのため、僕の場合は、予め情報を集める事に力を注ぎ、後々破綻しないディレクションをするように心がけている。

必要な情報をできるだけ早く集めきる

 

1. 競合調査、ステークホルダーの確認

新しくデザインする時、まずグラフィックツールを開くのではなく、情報収集から始める事が多い。

ステークホルダーと目的合意、競合サイトの調査、必要機能の要件洗い出しは当たり前のようにやるとして、関連部署から受けるであろう制約も同時に確認して、要件の抜け漏れを防止するようにしている。

例えば、ロゴ作成時は図形商標の取得プロセス、スケジュール感を把握するための部門と相談し、アプリUIの設計時は、利用規約の表示方法から個人情報の取扱い・コミュニケーション機能提供時の制約などを確認してUIに反映する。

その時、制約を越えてこだわるべき箇所は、『弊社の法務は厳しいからこのUIしょうがないんだよねー』と言う状況を起こさないように説得材料集めのタスクを積んでいく。

意思決定者も関連部門のポリシーを正確に把握していない事も多く、ITや法務、インフラ部門との調整が杜撰だと後々ボディブローのように効いて後退する事になるので、必ずミーティングに参加する or 自分で調整するようにしている。

終盤のステージング環境でツッコミを受けて突貫工事するのは何としても避けたいからだ。

 

2. 画面を見ながら要件をあぶり出す

一通りヒヤリングして要件が見えたら、数パターンデザイン案を作ってチームから意見を募る。この時、重要なのは荒い状態でもいいから早く相談する事、密室でやらずに全員にシェアする事。

一人で要件を洗い出したつもりでも、実際の画面を見て会話する事で抜け漏れや改善案が見えてくる事が多い。

若い時は指摘を受けるのが嫌で、最初から完璧な仕事を目指す抱え込むスタイルだったけど、早い段階で周りを巻き込んで設計した方が質が高くなる事に気づいてからは、Twitter感覚で、SlackにUI案をつぶやきながら作るようにしている。

作ったUI案をSlackに投下したら、エンジニアが数時間でプロトタイプを作ってくれた事があるんだけど、頭で考えるのと、形にして手で触って感じることのギャップは大きいので、設計段階でその感覚をキャッチボールできる環境は最高だと思う。

この前「とにかく雑に作れ」と言う記事を見たけど、まさにこんな感じで、雑っぴんぐする事で、答えが浮かび上がってくる事が多い。

中には抱え込み癖がついている人も居るので、Slackの分報という仕組みを採用して雑にシェアするカルチャーを醸成するのも一つの方法だと思う。

日報の弱点を補える「分報」とは
課題解決へのアクションが遅れてしまうという日報の弱点を克服するために、僕のチームでは「分報」という独自の取り組みをしている。分報ではSlackなどの社内チャットツールを使い、「今やっていること」や「困っていること」をつぶやく。課題をリアルタイムに共有できるのが特徴だ。日報が社内mixi日記だとすると、分報は社内Twitterにあたる。

 

3. ユーザーレビュー、ニーズ引き出し

「2」と並行して、ユーザーニーズを集める作業も実施していく。
この時点では、MVPとして製品評価の実施ではなく、情報収集を目的としたオープンなインタビューを行う事が重要だと思う。

  • デザイン案をみてもらい本質的なニーズを引き出す
  • 自分の感覚とユーザー感覚とのズレが無いか確認
  • オープンクエスチョンでアイディアを募る

テクニックの一つとして、複雑になりがちな入会遷移やフォーム周りのストレスチェックを実施して、関連部門との交渉材料もここで集めるようにしている。

例えば、ユーザー属性は取り敢えず取っておきたいマーケチーム向けに『ミスタップや入力項目が多いストレスで離脱ユーザーがこれだけ増える可能性ありますが、本当にこの属性全部必要ですか? ギリギリまで絞りません?』 と動画データをみせつつ交渉する事で項目を絞っていく事もできる。

 

4. 情報量の頂点

要件、制約、ユーザーニーズを出し切ったら、不必要な要素を排除し、本質的な情報に絞る引き算のデザインを始めていく。

僕は必要なければ、この時点までオリジナルのグラフィックは作らずに「UI8」「Sketch App Sources」「Shutterstock」などの素材を使って情報集めに徹する事が多い。

ここまでで大事なこと

  • チーム内外を巻き込んで意見を出し切っておく
  • 制約を把握する事で、後の設計破綻を防ぐ
  • グラフィックやアニメーションで悩まずに情報集めに徹する

 

5. 本番環境同等のプロトタイプレビューで最終チェック

テストは必ずユーザーが使うであろう同等の環境でチェックする事で、環境違いによる誤評価を防ぐようにしている。

利用想定が電車の中であれば、同じように電車の中で触り心地をチェックするし、Push通知がトリガーになるコンテンツの場合は、通知文言も最適化させた状態でチェックしていく。通信環境など実際ユーザーが触る環境でテストするともう一段階位改善する余地がでてくる事が多い。

例えば、スマートフォンAPPをPCのiOSシュミレータで評価することなどはしてはいけない。

 

6. デザインブラッシュアップ

ここまで来たらゴールはもうすぐ。
細かいアイコンやカラー調整などグラフィックを仕上げていく。

 

7. リリース & ガイドライン/デザインデータ整備

無事にリリースできた後は結果が出るのを待ちつつ、デザインガイドライン作りとデータ整備をしておく。
Twitterでエゴサーチをすると予想通りの反応が出ると嬉しくなるし、改善点も見えてくるので、チームにシェアしつつUIの改善案をだしてまだSlackに投下していく。

 

まとめ

これデザイナーの仕事?って思う人が多いかもしれないけど、シンプルで良質なUIデザインを実現したい場合、グラフィックよりもっと前の段階を調整する事で実現できることが多いのだけど、やり方がわからない人向けに書いてみました。良ければ参考になればと思います。

 

デザインの伝え方
デザインの伝え方

posted with amazlet at 17.02.28
Tom Greever
オライリージャパン
売り上げランキング: 30,094

 

 

UXデザインについて再考してみた


UX_Design

先日『意味不明なことばかり言ってるUXデザイナー達の代わりに「UXデザインとは何か」を端的に説明しよう』と言う記事がバズってた。

でもね、世に言う「UXマン」っているじゃないですか。

いかにも自分は上流工程だと言わんばかりに様々なフレームワークや聞こえはいい理論を振りかざしているにも関わらず、自分では手を動かしてモノをつくらないし、いざつくってもらったらアチャーなアウトプットだす人たち。

僕は、モノづくりに従事している人間なら「アウトプットで語れ」という哲学を持っていて、Twitter上で同意する考えをコメントした所、数名から辛辣すぎると言う意見をもらったので、もう考えを少し補足してみました。

UXデザインをチームに浸透させる事が使命になると本末転倒

僕もUXデザインを顧客重視のモノづくりと定義するならば、その考え方は凄く好きだ。

ただ、最近話題になるように 「UXを業界やチームに浸透させる事が使命」と言う人も出てきて、力の向き先が顧客やプロダクトでは無く、組織内や人に向いた布教が目的になっている人が出てきているのも事実だと思う。

敢えて言うけど、UXに特化したポジショニングのUXデザイナーや人間中心設計専門家って聞こえは良いけど、本人自体のモノづくりスキル、キャリアはいまいちな事が多くて、その知識で何を作ったか、作っているのか?と聞くとあいまいな回答が帰ってくる事も多い。

と言うのも僕の感覚では、1年〜2年手を動かす仕事から離れると技術変化に追いつけなくなるため、開発ディレクションを語るにはリアリティが無く、よほどサービス感がある人じゃないと、プロダクトを作り上げていくフェーズにおいては価値を発揮しにくい職能になってしまうと思う。

アカデミック知識の重要さを否定するわけではないけど、サービスを作る時一緒に働きたい人は、多識な人ではなく、今作ろうとしてるモノの領域を信じて執着できる人だ。その上で、「具体的にどういうインターフェースであるべきか、習慣化させるために必要な継続的な工夫は何か」を膝を付きあわせて話し続けられる仲間であって、予期的UXという一般論や概念では無い。

手を動かす人が企画して実行する方が生産性が高い

最終形態かもしれないがシンプルに考えて、開発チーム全員が手を動かせる状態の方が生産性が高い。そして専門知識より、MVPのフィードバックで得た経験値の方がチームをレベルアップさせる。

冒頭の記事で「UXとはみんなでちゃんと企画すること」と定義されてるけど、ここ数年バズった恩恵で、現場のデザイナーやエンジニアも「ユーザーの使い勝手の最重視」つまりユーザー・ファーストが大事な感覚を理解した上で、自分たちなりに工夫して実践し始めている。

例えば、最近読んだスライドでは

手を動かすプレイヤーがユーザーの使い勝手を想像し、工夫・実行できるように仕組み化しているので個人がディレクションするのではなく、客観的なフィードバックを受けられる仕組みがディレクションとなる文化に置き換わってきた。

その背景として、プロトタイピングツールやリアルタイムの分析ツールが一般化した事で、現場の人間が直接フィードバック受けれる機会が増えたというのも大きいと思う。
『おいおい。うちのチームまだそんなに良い環境じゃねーよ』って人もいると思うけど、コストもかからないのでまずはスライドなどを参考にやってみると良いと思う。

ただそこに”いわゆるUXマン”が参入してくると、ベーシックなフレームワークで被せられ『まずはペルソナ作りましょう』など広義な話に引き戻されるし、最悪なパターンとして「自分はセンスがないのでUIは任せますね」という感じで、上流工程でお手並み拝見スタンスになる事もある。

その結果、チームで企画を考えるのではなく、個人がディレクションする逆行状況になり、UXデザイナーに対する反論記事が増えてきたというのが事の顛末だと思う。

「僕はUXデザインだけではなく、モノも作れます!」って人も多いと思うけど、その場合は、理論でマウントを取りにいくのではなく、モノを作りながら結果で示してくれた方が周りの納得感も高いと思う。

・UXに関わる仕事をして感じた4つのこと
http://baigie.me/nippo/2016/07/19/ux%E3%81%AB%E9%96%A2%E3%82%8F%E3%82%8B%E4%BB%95%E4%BA%8B%E3%82%92%E3%81%97%E3%81%A6%E6%84%9F%E3%81%98%E3%81%9F4%E3%81%A4%E3%81%AE%E3%81%93%E3%81%A8/

・UXという理解し難いモノと向き合う forエンジニア
http://qiita.com/netetahito/items/88a61128d26ff17bd418

現場とUX専門家との役割を棲み分ける

では、UXデザイナーの専門家は何をする人なのか、という質問をされた時の答えとしては、対チームではなく対外的な交渉や巻き込む時において価値を発揮していくべき職能だと考えている。

前回の記事でも書いたけれどユーザーにとって理想的なモノづくりを実現するには、交渉力や関係者の巻き込み力が必要になる。特にIoTにおけるユーザー体験を追求していくと、ウェブ完結型ではなく非ウェブ業界との連携、アセット活用が重要になってくる。

例えば、スマートロックを使って感じるのは、既存の物理キーより解錠の手数が増えるUIになってしまうので、スマートと言うには若干遠い状況だ。理想としては、開ける意志を持ってドアに近づいた時だけ、自然解錠されるようなモノが望ましいが、内側のキーシリンダー外付け + iPhoneアプリでそのユーザー体験を実現する事は、iOSの仕様的に難しい。

そのため、独自では無く既存の鍵メーカーと組んで、鍵そのものの仕組みを置き換える事で理想に近づけると思うが、技術的には可能でも、実現にあたってリソース調達や技術連携は、モノづくりとはまた違うスキルが必要になる。

UXデザイナーがプレゼンスを発揮すべき所は、定量評価ができない状況・類似事例が無い場合においても、何故そのサービスが必要なのか、その理由の土壌みたいなものを言語化して説得する事だと考えている。非インターネット業界の人を巻き込む仕事は、今後重要になっていくと思う。

イノベーションを起こすためには何が必要か

世の中のプロダクトやサービスをよりよいものにしたいという想いが非常に強かったことを覚えています。ユーザー不在の組織や社会にイノベーションを起こす思想こそ、日本のものづくり文化の再建に貢献するだろうと確信しました。

とある、UXデザイナーのブログでこんな文章を読んだ事がある。

なんだかんだ言っても、良い物を作りたい想いは同じなんだと思うけど、あえて言うと”現場でユーザーの事を考えてない奴なんて居ないし、イノベーションを起こしたくない奴も居ない“と思う。少なくともウェブ業界にはかなり健全だ。

日本の新規事業開発においてよく言われるのは「大企業では、イノベーションを評価できる人がいないことから、新しいアイデアが生まれても、それを推進できる環境では無い」という課題がある。例えば、ソフトとハードウェア部門が分かれている事でアジャイル開発できない弊害や、入念な安全規格やリーガルチェックが入り無難なアイディアに着地せざるを得ない。それで、多くの技術者は悔しい思いをしてきたと思うし、僕もその経験がある。

でも、いつか実現できる時が来ると信じて僕らは日々技術を磨くのだけど、UXデザイン専門家がデザインの価値というモノを証明して、それらを変える動きをする事は、現場の最適化よりモノ凄くインパクトのある事だと思う。

現場からは以上です。

 

UXデザインを学んだその先にあるモノ


いつからか、UXという言葉をあまり使わなくなった。

UXと言う単語だけ切り出すと言葉の定義が曖昧で、開発現場で建設的な議論がしにくいというのもあるんだけど、現場のデザイナーや開発者がごく当たり前に考えている内容と同じ事でも、UXデザインのプロセスを通ると「これからUXデザイン手法で検証した、すごい結果をお話しますよ」と大層な話になってる事もしばしばある。

… 続きを読む

 

デザイナーに必要なコミュニケーション能力とは何か


最近、デザイナーにコミュニケーションスキルが必要と言われるしその通りだと思うけど、日本の美大でコミュニケーション教育は重視されてないのに関わらず、社会に出たら突然「重要です!」と言われて最近の新卒は「突き放された気持ちになる」と言う話をたまに聞く。

そして、社会人になるとデザイナーに限らず、同じようにコミュニケーションスキルが必要と言われるのだけど、クリエイターが不幸なのは、教えてくれる人が極端に少ない所だと思う。確かに、デザインスキルは楽器演奏と同じで、実践による反復運動の繰り返しで身につくものだと思うけど、コミュニケーションスキルに関しては、感覚的にと言う言葉で終わらぜず、キチンと言語化しておくほうが良い。

… 続きを読む

 

UIデザイナーに必要なのは、決定力のあるデザインを作る能力


最近、デザイナーに求められるスキルが多くて何を学べば良いかわからなくなってきた。と言う声を聞くようになってきた。

流行りの記事のいくつかに目を通すと、デザイナーは「経営者と対等に話せるコミュニケーション能力、ビジネスセンスを保有していて、イケてるグラフィックを作り、コードまでかけないといけない」らしい。

スキルを多く保有している方が望ましいのは間違いない。

ただ、現場デザイナーに最も大事なのは実装面での考慮事項が網羅されて考え込まれた「決定力のあるデザイン」を作る力だと思う。

サッカーで言うと、決定力は「得点を決める能力」として使われているけど、UIデザインにおいては「実装面まで考慮された実装可能なデザインであるか」という言葉として使っている。

魅せるデザインとフィージビリティが考慮されているデザインでは、内容がかなり異なってくるので、現場デザイナーとしては特にこのあたりを意識しておきたいところ。

Dribbbleに掲載されているデザインは確かにかっこいい。僕も好きでよく見ている。
参考にしているデザイナーも多いと思うけど、あれはあくまでコンセプトなので、孵化させるためにはフィージビリティを深く考えてデザインする必要がある。

具体的には、仕様が精査されている事に尽きるのだけど、決定力のあるデザインの一例をあげてみる。

… 続きを読む