mokky14's IT diary

IT関係の仕事メモ、勉強会の感想など書いてます。

UX仙台 デザイナーが大事にしていること に行ってきました

2014/11/15のUX仙台のレポート。

チームで協業するための、共有のしかた (フジタジュンコさん)

過去

デザインチームが話を聞いた時点で開発期間はもう決まってたりする。
前工程で遅延が発生してても、〆切は変わらない。
デザイナーはその短い期間内で徹夜してでも頑張って終わらせる。

なのに、
「この通りに作ってくれればいいから」と言ってたのに、出来上がったら
何か違うんだよねぇ。。」と言われたり、
全部作り終わって、テストに入ろうという時になって、
偉い人がダメって言うから直して」と言われたりする。

死にたい...

なぜこうなる?

「この通りに作ってくれればいいから」の何が悪いかというと、意図を全く伝えていない。
そうなるとアウトプットもいいものが出来ない。指示が明確でないものをデザイナーは表現できない。

お客様に検証するための指標がない。
指標がないので、偉い人が「これじゃダメだよ」と言った事をそのままデザイナーに返す。

どうすれば?

全体を見ることが必要。

Webを作るといった時、製作者はWebだけ考えて良い物を作ろうとしてしまう。
ユーザは「何かをしたい」「何か欲しい」ためにWebを触る。
ユーザに価値を提供する媒体としてWebがあり、ユーザはWebではなく「Webを通して得られる体験」にお金を払う。
全体の流れの中にWebがあることを理解する必要がある。

f:id:mokky14:20141117005542p:plain

ユーザに届ける価値が一番大事。
ユーザが「お金を払っても良い」と思える価値は何か?

f:id:mokky14:20141117005607p:plain

チームでコンテクストを共有する。
全体でコンテキストを共有しないと最高のものを提供することはできない。

全体を見て協業するためにやってきたこと

インセプションデッキ

f:id:mokky14:20141117005618p:plain

良かった点

  • コンパクトなので、共有がすばやくできる。
  • キャッチフレーズを作ると、Webサイトでそのまま使える。
  • ミーティング1~2回で作れる

悪かった点

  • どの程度具体的にすればよいのかが難しい。
  • 大きいプロジェクトだと、内容がざっくりすぎて、何回も作る羽目になった。

大規模なプロジェクトでは難しいが、中規模、小規模のプロジェクトでは有用。
インセプションデッキを使用することで、ユーザが何を求めているか?
我々のサービスがどうアプローチ出来るかを共有する事が出来る。

ビジネスモデルキャンバス

良かった点

  • チーム外の活動(営業、マーケットの動き、エバンジェリストの活動等)を洗い出す事ができた。
  • 顧客にもたらす価値を共有できた。
  • コミュニケーションのポリシーまで決められた。

悪かった点

  • 時間がかかる。(以前のプロジェクトでは1週間くらいかかった)

デザインコンセプトを作る時には有効。
他にカスタマージャーニーマップも参考になる。

ペーパープロトタイピング

UI設計書の前にペーパーでプロトタイピングしたもの。
UIするデザイナーとのやりとりに使っていた。

f:id:mokky14:20141117005630p:plain

社内でテスターの人を呼んでペーパーで使い勝手をテストしてもらう。

良かった点

  • ペーパーで一旦テストしているので、後で「この画面使えない」という事はなかった。
  • テストとデザインを別立てで走らせられる。デザイナーを待たせないで済む。

悪かった点

  • 工作に時間がかかる。
  • 学習コストが高い。
  • 紙は動かないので、インタラクション設計を別にする必要がある。

画面遷移がそれほど多くないものであれば、紙に書いたものをデザイナーに渡すだけで、デザイナーは割とやれる。

気を付けている事

f:id:mokky14:20141117005716p:plain

全体を見て共有する事によるメリット

f:id:mokky14:20141117005724p:plain

f:id:mokky14:20141117005731p:plain

プロジェクトが始まった時点ではみんな「よいもの」を作りたいと思っている。
職歴、立場等で、「よいもの」がずれてくる。
「ユーザにとって」よいものを作るために上記の手法は有用。

f:id:mokky14:20141117005737p:plain

デザインワークをスムーズにする、共有のしかた (井上亜津奈さん)

デザインはふわっとしたモノととらわれがち。
f:id:mokky14:20141117005816p:plain
なぜこのデザインにしたか、デザイナーは常に答えを用意しておかなければいけない。
クライアントは説明の方にお金を払っている。

デザインの目的は課題の把握と解決。
デザインで何ができるかを考えて、具体的な方法を提示する。
主観やセンスで片付けられるものではない。

デザインの現場でよくある事

f:id:mokky14:20141117005825p:plain
f:id:mokky14:20141117005833p:plain

でも、お客さんは悪くない。当たり前の事。

お客さんに分かりやすいものを提示して誘導するのもデザイナーの仕事。
明確なイメージを一緒に探らなければ迷路に迷い込んでしまう。

まず、ビジネスやサービスの目的を理解すること。
f:id:mokky14:20141117005901p:plain

デザインに出来ない事も理解しておくこと。
「検索で常に上位に来る」とかはデザインでは出来ない。

トーン&マナーを作る

トーンとは、企業やサービスがもってる「らしさ」の事。
トーン(概念)をルール化したものをトーン&マナーという。

f:id:mokky14:20141117005934p:plain

トーン&マナーを作るときはターゲットが大切。

デザインの前に表現の方向性の共有を行う。これでデザインが楽になる。

f:id:mokky14:20141117005946p:plain

ヒアリングでは世界観を表すものだったら何でも(雑誌、サイト、ブランド等)いいので聞く。

ユーザのヒアリングに有効な手法

f:id:mokky14:20141117010002p:plain

言語マトリクス

ユーザヒアリングの中で出てきた抽象的なワードを拾って言語マトリクスを作成し、どのあたりを狙うかを考える。
競合の会社がマトリクス上どのあたりに位置するかをポイントし、そのあたりは外すという事も出来る。
お客さんも参加しやすいというメリットがある。

カラーリング

こんなキーワードで、こんなターゲットで、こんな組み合わせはどうでしょう? と提案する。
カラーは世界を決めてしまうものなので大切。

f:id:mokky14:20141117010011p:plain

イメージボード

世界観を表す画像を集めたスクラップブックのようなもの。
手間はかかる。
お客さんとイメージ共有を手っ取り早くするために使用する。

サンプルサイト

見えるものに引っ張られてしまうという弊害がある。
見せたサイトと全く同じものを作ると思われたり、イメージではなくガワの話に終始する危険性がある。
使えるかはお客さんに依る。

ワークショップ

2チームに分かれてのデザインワークショップ。
自分のチームは、ずんだPRのためのWebサイトリニューアル企画検討。
(課題内容書いた紙を持ち帰るの忘れた orz)

ワークショップの内容

  1. 依頼内容の確認。
  2. 依頼内容を元にお客様にヒアリング。(ヒアリングシート無くしたので写真なし。)
  3. ヒアリングした内容から、企画検討。
  4. プレゼンのボードを作成し、お客様(相手チーム)にプレゼン。

企画検討
f:id:mokky14:20141129024922p:plain

良かったところ

  • 企画検討のとき、アイデアを各自が発言しながら付箋に書いて貼っていくのは良かった。(誰か一人が記載するより早い。人の発言を聞きながら自分の手を動かせる)
  • 企画検討で、対象の情報をググって、アイデアのヒントになる情報を探すのは有効。(「ずんだは仙台七夕あたりからお盆までが繁忙期」という情報から、七夕祭りとファッションショーを関連付ける案が出た。)
  • いまいちだな、と思ってもとりあえず出してみる。他の人がそのアイデアを膨らませてくれるかも。
  • イデア出しのとき、「否定しない」事は大事。人のアイデアで「いまいちだな」と思っても、「このアイデアの活かせそうなところは。。」という方向で考えて、アイデアを発展させることが出来た。

悪かったところ

  • お客さんへのヒアリングが難しかった。抽象的なイメージを聞くためにどんな質問したら良いか分からなかった。今ブロク見返して、言語マトリクスとか使ってみても良かったと思ったり。

自分のチームで作成したプレゼンボード。
f:id:mokky14:20141116235656p:plainf:id:mokky14:20141116235711p:plainf:id:mokky14:20141116235721p:plainf:id:mokky14:20141116235732p:plainf:id:mokky14:20141116235855p:plain

作成した後に思ったのが、「ユーザの発言全てに応えようとはしなくて良い」事。
お客様の色々な立場の人が、それぞれの立場から意見を出してきたら、その中には相反する要望、実現出来ない要望、単なる思いつきの要望も入ってるはず。
なので、要望全てに応えようとするのではなく、要望をヒントに方向性を決めて、その方向性に沿って提案をする事が大事。
自分も含めて、プログラマーは言われたことは全て実現しないといけないという考えになりがちなので、この視点は意識しないといけない。

デザインにもアジャイルの手法が有効な事が分かったのは面白かった。

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−