CrowdWorks Designer Blog

クラウドワークスのデザイナーが書くブログ。深いような、そうでもないような知識、体験、考察をお届けします。

UI文言にビックリマークを使わないほうがいい5つの理由

f:id:takeshi-atarashi:20170921160240j:plain

 

みなさん、こんにちは!マネージャー兼コピーライターのアタラシです!
 
先日、ぼくの応援する浦和レッズが、AFCチャンピオンズリーグ(有名なUEFAチャンピオンズリーグのアジア版)の準々決勝で、同じ日本の川崎フロンターレ相手に世紀の大逆転勝利をもぎとりました!とても嬉しいので、ご報告させていただきます!本当にものすごくて、ぼくの生観戦歴の中では確実に5本の指に入ってくる試合でした!
 
さて、そんなことは置いておいて、今回もUIライティングについて書いてみます!連載の三回目!テーマは、エクスクラメーションマーク!ちまたでは「ビックリマーク」という呼称で広く親しまれている、この「!」マークです!ぜひ読んでください!そしてシェアしてください!
 
 

ビックリマークの使い方って難しい?

冒頭の文章、「!」を多用してみたのですが、どうでしたか?前半はそんなに違和感ないけど、後半はなんとなくウザいですね。それはどうしてなのでしょうか。もしかしたら、ビックリマークが関係しているかもしれません。
 
さて、この記事では、「UI文言にビックリマークを使わないほうがいい理由」について、ぼくなりに考えてみたことをいくつか書いてみようと思います。どうぞお付き合いください。
 
 

理由1:実は、あってもなくても、意味は変わらない。

「!」は感嘆符と呼ばれます。文章の最後などにつけることで、文章を強調する効果をつくるものです。文章そのものの意味には、大きくは影響しません。あくまでも強調です。従って、意味が伝わりさえすればよい場合に、UI文言の語尾に「!」をつけるのはオススメしません。
 
UI文言において、無駄な文字は1文字であっても減らすべきなので、「!」にしても1文字分のスペースがもったいない。さらに言えば、「!」のせいで、文章に無駄なニュアンスも付加されてしまい、そのせいで受け手に思考コストをかけたり、受け手の行動を阻害したりしてしまいます。スムーズにサービスを利用してもらうにあたっては、小さいながらも、確かな悪だと思います。
 
「トイレはこちら!!」
 
例えば、トイレの場所を示す貼り紙に、上記のように書くのは、まず文字スペースの無駄。そして、「気合いが入っているなあ」「そんなに自慢のトイレなのかな?」「キレているのかな?」「何これうけるw シェアしよう」などなど、トイレに行きたいユーザーをトイレに導くというこちらの目的に対して、それを阻害する何かを生み出してしまっているかもしれません。
 
もし上記の貼り紙を、おもしろがってシェアしてるうちに、トイレが他の人に利用されてしまったら・・・しかも長居されてしまったら・・・このユーザーは漏らしてしまうかもしれません。いや、けっこう真面目に書いてますよ、これ。
 
なんかスペース的に寂しいからとか、内容がうまく書けなかったからとか、いろんな理由でUI文言の最後に、軽く「!」をつけて誤魔化したくなる気持ちはわかります。でも、そんなときはグッとこらえてください。
 

f:id:takeshi-atarashi:20170921162516j:plain

 
 

理由2:強調箇所が多いほど、何も強調されなくなる。

強調というのは、メリハリのことです。メリがあって、ハリがある。これを忘れてはいけません。強調ばかりの文章は、結局何も強調できておらず、ただただ無駄な熱量を放ち続けます。無駄な熱量ばかりの文章は、熱量がまったくないより、はるかにうざったい。例えるなら、蛍光ペンだらけの参考書みたいなものです。
 
「!」に限らず、太字や下線なども含め、強調箇所は、絞りに絞りたいですね。そのほうが、強調が、強調として機能します。
 
(ちなみに、メリハリという言葉は「滅り張り」と書き、抑揚のことらしいです)
 

f:id:takeshi-atarashi:20170921162459j:plain

 
 

理由3:すでに十分、強調できている。

ユーザーの注目を集めるために、四角形や、ギザギザの吹き出しなど、何かしらの図形の中に文言を入れることがありますね。その中に「!」を使う必要は、あまりありません。少なくとも、ぼくはそう考えています。
 
「今すぐ会員登録する!!」
 
たまに見かけるのが、このように、コンバージョンボタンの中の文言に「!」を使用しているパターン。ぼくが考えるに、この「!」は不要です。
 
もし注目されることが目的の強調だとしたら、文言そのものは注目には寄与しないため、確実に不要です。
 
もし注目後の後押しが目的の強調だとしたら、「!」の有無で後押しされるほどユーザーも単純じゃないし、むしろ「なんか押し売りみたいだし登録やめとこうかな」ってなる可能性のほうが高いと思いので、これまた不要です。
 
UI文言は「受け手が行動を選択するための情報が正確に伝わる」ことが大切ですので、登録を後押ししたいなら、ちゃんとコンバージョンボタン以外のところに、ちゃんと後押し用のコンテンツをつくるなどして、そこでがんばるしかないと思います。

f:id:takeshi-atarashi:20170921162431j:plain

 
 

理由4:命令や押し付けになることがある。 

理由3の内容にも通じるのですが、「!」のついた文章は、命令のニュアンスを帯びる場合があります。なので、文章によっては、「!」が発するニュアンスからくる不快感、不信感を、相手に与えてしまいます。明らかに命令される理由のあるシチュエーションでない限り、ぼくらは、誰にだって命令なんてされたくないですよね。これは、ユーザーを何とかコンバージョンさせたいときなどに、起こりがちなパターンです。
 
「次の人のためにキレイに使いましょう!!」
 
例えば男子トイレにこんな貼り紙があったとき。いつも汚くされて、店員さんが困っている様子が伝わってきます。でも、この貼り紙だけだと、人によっては「うるさいなあ、わかってるよ。ていうか、次の人のためとか言うけど、本当は自分たちのためでしょ?」とかひねくれた気分になってしまう人がいるかもしれません。そのせいで、信頼が得られないかもしれません。そうだとしたら、もったいない。
 
こちらとしては、お願いやオススメの気持ちであっても、受け手にとっては命令や押し付けになってしまうこともあります。気をつけたいところです。
 
もし店員さんがデザイナーであれば、便器の中にマトになるシールを貼るとか、立ち位置を示す足跡型パネルを床に貼るとか、そういう行動デザインのアプローチをとるのでしょうけど。
 
 

理由5:受け手をシラけさせることがある。

冒頭でも書いた通り、「!」は文章が強調されていることを示すものです。そして、UI文言は、文章の一人称が利用者本人のことが多い(「もっと見る」とか「申し込む」とか)。つまり、そういう時「!」は、あなた(サービス提供側)ではなく、利用者の気持ちや考えを強調するものとして、サービス上に置かれることになります。
 
UI文言に「!」を使用するときは、まず「この文言の一人称は利用者か?サービス提供側か?」ということを考えてみてください。そして、もしその文言の一人称が利用者側なのであれば、あなた(サービス提供側)の気持ちを載せて文言に「!」を添えるのはやめましょう。サービス提供側の独りよがりな気分が伝わり、受け手がシラけてしまいます。行動を止めてしまいます。
 
「手数料が無料になりました!」
 
例えばこんな風に、発信者が一人称の文言に添える場合は、「!」が効果的なこともあります。
 
この例の場合、サービス提供側の「みんな、ついに無料にできたよ!」という喜びと、受け手の「ついに手数料が無料になったんだ!」という喜びが、共鳴しているっぽいですよね。興奮を発信者と受け手で共有できる場合、あるいは受け手が確実に興奮するであろう場合は、「!」を使ってもいいと思います。
 

f:id:takeshi-atarashi:20170921162348j:plain

  

これだけ覚えて帰ってください。

UI文言は100%ユーザーのためのもの。
サービス提供側の気分は基本的に入れるべからず。
 
いろいろ書いてきましたが、すべて忘れてしまっても、この点だけは忘れないでください。
 
これは、どんなUI文言を書くときでも同じです。これさえ意識しておけば、意識する前よりも、よいUI文言が書けると思います。それでも、めんどくさかったら、コピーライターを雇うといいですよ。
 
なお・・・弊社サービス「クラウドワークス」には、「!」が多数生息中。駆除できておりません。このエントリーは自戒の念も込めて書かせていただきました。南無。
 
 

では、また次回。

なんかトイレの事例が多くなってしまいました。クラウドワークスでは、トイレの中でもデザインのことを考えちゃうようなデザイナーを募集しています。

“デザイン” を重視しないプロダクトに発症しがちな3つの病い

f:id:ueda1023:20170912100547p:plain

死に至る病とは絶望である
セーレン・キェルケゴール

こんにちは、デザイナーの上田です。

先日経済産業省からIT関連産業の給与等に関する実態調査結果というレポートが発表されましたが、「デザイナーの給与水準が低すぎるんじゃないか」「デザインをもっと重視するべきなんじゃないか」と話題になりましたね。

f:id:ueda1023:20170905152127p:plain 引用:http://www.meti.go.jp/press/2017/08/20170821001/20170821001-1.pdf

個人的な所感は、大企業やITベンチャーの中にも経営チームにCDO(最高デザイン責任者 / Cheif Design Officer)のポジションを設置するなど、経営的にデザイン思考や人間中心設計を重視する企業も増え始め、世の中のデザインに対する価値観の転換を感じています。その一方で、社外のデザイナーと話していると、大半の企業は「デザイン?何それおいしいの?」といった状態であるようなので、リソース(人数、給与など)の割き方という意味で、“デザイン格差”がすごいのが現状なのかなーと思ってます。

では、率直な疑問として、デザインにリソースを割く場合とそうでない場合とでどのような“差”が生まれるのでしょうか?逆に言えば、なぜ企業がデザインに力を入れ始めているのでしょうか?

デザインにリソースを割かない場合に陥る症状は無数にあると思いますが、私の専門であるWebやアプリなどのプロダクトデザインに焦点をおいてご紹介できればと思います。

今回はご紹介する病いは、以下の3つです。

  • 情報アーキテクチャ不全
  • バナー依存症
  • ターゲット失調

一つでも当てはまる企業にお勤めの方は、ぜひお早めの治療をご検討くださいっ |´・ω・`)

病名①「情報アーキテクチャ不全」

f:id:ueda1023:20170912204135p:plain

デザインにリソースを割かないと、情報アーキテクチャ不全にかかります。

情報アーキテクチャとは、対象のWebサービスやアプリが提供している情報を可視化し、ユーザーにどんな行動を取ってほしいのかを考え、適切な機能やコンテンツの配置に落とし込むアプローチのことです。

情報アーキテクチャの実践を怠ると、サービスの成長の過程で新しい機能やコンテンツを五月雨に追加する形になりがち*で、みるみるうちに情報構造が複雑になってしまい、ユーザーが混乱したり、迷ったりしてしまう症状に陥ります。

*類似する考え方として「誰のためのデザイン?」という本で、「機能症」という概念が紹介されています。

また、新しい機能やコンテンツを追加する時に、ラベリングや導線で延々の議論が続いてしまい収束しない経験はありませんか?

ユーザーの混乱を招く複雑な情報構造になってしまっているということは、裏返すと開発チームの視点で見ても同じように整理のついてない状態なことがほとんどなので、大抵は開発スピードの鈍化、自社サービスの展開力の低下につながります。

怖いですねー。

f:id:ueda1023:20170906142907j:plain

Booking.com の公開している事例が分かりやすかった。これはリニューアル前のトップページの情報構造の可視化だそうですが、異なる性質の情報がページ内で散らばってしまっているのが確認できます。
引用:https://uxdesign.cc/booking-com-ux-analysis-and-responsive-redesign-5854d616c0b8

情報アーキテクチャ不全の治療法

治療法を考えてみます。

情報アーキテクチャ不全に陥った時、そんな時に活躍するのは情報アーキテクチャの実践なわけですが、具体的なアクションとしては、デザインシステムの策定・導入デザインリニューアルを検討してみるのがよいかと思います。

抱える機能が肥大化してきたタイミングで、デザインリニューアルを実施する会社も実例としてはありますし、デザインシステムとしてプロダクトの情報設計やビジュアルデザインのルールを定義し、それに準拠して日々の機能開発を進めることで、情報構造の整合性を保ちやすい状態を作り出すことができます。

どうしても大きなコストはかかってしまいますが、ユーザー体験の向上や開発の生産性の向上につながる施策になると思うので、中長期的な視点で検討したい取り組みです。

クラウドワークスではどうしてるの?

自分でこんな記事を書いておいてなんですが、クラウドワークスは情報アーキテクチャ不全を抱えているサービスの一つです。

創業時にUIのコンポーネントをパーツ単位で管理するスタイルガイドを策定し運用を進めていたものの、情報アーキテクチャの指針やUIの拡張性のない仕組みだったこともあり、一部形骸化してしまっている部分があります。

そのため、クラウドワークスのUXデザイングループでは新たにデザインシステム作りのプロジェクトを発足させ、現在進行中で策定を進めている最中です。現時点で詳細をお伝えできず申し訳ないのですが、またいつかご共有できればと思います。

なお、今回は情報アーキテクチャについての詳しい説明は省きましたが、具体的に詳細を知りたい方はUXデザイングループの文部科学大臣、田村さんオススメの「しろくま本」を読んでみてください。

情報アーキテクチャ 第4版 ―見つけやすく理解しやすい情報設計

情報アーキテクチャ 第4版 ―見つけやすく理解しやすい情報設計

  • 作者: Louis Rosenfeld,Peter Morville,Jorge Arango,篠原稔和,岡真由美
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2016/11/18
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

病名②「バナー依存症」

f:id:ueda1023:20150828210928j:plain

デザインにリソースを割かないと、バナー依存症にかかります。

バナー依存症とは、トップページやマイページなどアクセスの多いページがバナー置き場になる病いのことです。

実はこれ、オライリーで出版されてる「デザインの伝え方」という本でも紹介されてまして。

トップページ症候群
アプリケーションの起動画面やウェブサイトのトップページが「なんでもありのガラクタ入れ」と化してしまう事態。リンクやボタン、バナー広告がひしめきあって使い勝手が非常に悪く、デザイナーが「泣きながら寝入る」しかない。

身に覚えのある方もいるのではないでしょうか。最近はあまり見かけなくなってきましたね。

バナー依存症が発症してしまうと、対象ページにバナーを五月雨に追加する形になりがちで、使い勝手が非常に悪くなってしまい、ユーザーの適切なサービスの理解を損ない、ページの本来の役割を果たせない症状に陥ります。

ユーザーの期待や目的と内容が異なるケースが多いので、ユーザーの離脱につながりやすく、コンバージョンなどの成果も多くは見込めません。残念ですね(マイクロコンバージョン的なものはもちろんあると思いますが、あまりオススメできません)

バナー依存症の治療法

具体的なアクションとしては、 ユーザーの行動をできる限り阻害しないバナー表示エリアの確保や、ユーザーが新着の情報を受け取りやすいお知らせ機能の整備などがよいのではないでしょうか。ユーザーに訴求したい新サービスや新機能が増えること自体は喜ばしいことなので、伝えたい情報がしっかりとユーザーに伝わりやすい仕組みを作ることが重要と考えます。

クラウドワークスではどうしてるの?

クラウドワークスはバナー症候群の感染に気づき、対策を進めていますが、まだ道半ばです。

実際にクラウドワークスのトップページやマイページでもファーストビューにサービスの機能とは関係ないバナーがたくさん表示されてしまう課題など、症状に現れていまして、現時点の対策としては、ユーザーのサービスを利用する行動を阻害しない形で新着の情報を露出できるように、マイページのUI改善のタイミングでデザインを変更・リリースなどの手を打っている状況です。

また、バナー依存症の症状を避けたほうがいいのではないかとデザイナーが気づけたとしても、実際に改善を進めていく上ではマーケターやエンジニアなどの理解や協力が必要になるケースが多いと思います。その際は、デザイン思考や人間中心設計の考え方を軸にしつつ、関係者とコミュニケーションをとりながら改善を進める形になるでしょう。

マーケターやエンジニアなどの関係者とコミュニケーションをとっていく上で、少し応用編にはなりますが、クラウドワークスではプロダクトのユーザー体験の指針となるUXガイドラインを策定・浸透する活動を行っているのですが、組織のリテラシーや価値観の啓蒙にも役立っています。

病名③「ターゲット失調」

f:id:ueda1023:20170912204851j:plain

デザインにリソースを割かないと、ターゲット失調にかかります。

ターゲット失調とは、サービスのターゲットとなるユーザーを曖昧にしたままサービス開発を進めてしまい、機能やコンテンツの一貫性を保てなくなってしまう病いのことです。

開発チームから「自分たちは誰のためにサービスを運営しているんだろう?」「これは誰のための施策ですか?」という声を聞いたことはありませんか?ものづくりをする上ではターゲットの設定は当たり前のようにも思えますが、競合の動きや技術の進化に引っ張られる形でサービスを開発をすると、ターゲット失調にかかる可能性が高まります。開発チームもモチベーションにも影響しますね。

ターゲット失調の治療法

具体的なアクションとしては、ユーザーインタビューなどの定性調査によるペルソナやカスタマージャーニーマップを通じたターゲットとなるユーザーや体験の可視化が一般的です。

具体的な事例だとAirbnbの取り組みが代表的で、ユーザーストーリーというデザイン手法でターゲットとなるユーザーや提供する体験を可視化し、開発プロセス内で常に参照できるようにすることで、工夫をしているそうです。

クラウドワークスではどうしてるの?

クラウドワークスは今年から定性調査の取り組みを始めています。

ユーザーインタビューやユーザビリティテストの実施や分析の回数を重ねるごとに、少しずつ自分の中にもユーザーの人物像やニーズについての感覚が芽生え始めてるようにも感じますし、ペルソナやカスタマージャーニーマップといった形で具体的なアウトプットになりつつある状況です。

具体的な取り組みは中心となって進めているUXデザイナーの八尾さんがブログで記事を書いているので、ご参考ください。

本だけではわからなかったユーザビリティテストのリアル
新卒の見習いUXデザイナーがユーザーさんの声を聞いて感じたこと

さいごに

いかがでしたでしょうか?

今回は“デザイン” を重視しないプロダクトに発症しがちな3つの病いというアプローチで考えてみましたが、書き進める中で感じたのは、どの病いも症状が明らかに顕在化するわけではないので、病いの自覚や対策の打ちづらさがあるなーという点でした。

数字で表しづらい分野だと思うので、デザイナーやデザインを活用したい方々は、適切にデザインの理解を深め、検証しながら自分たちなりのデザインのスタイルを形作っていくのみなんでしょうね。

こんな形で日々悩みは尽きないわけですが、クラウドワークスをデザインの力でよりよくしていける仲間を募集していますので、ぜひお気軽にオフィスに遊びに来てください〜。

www.wantedly.com

デザインツールFramerもくもく勉強会を開催しました&コミュニティ開設のお知らせ

こんにちは。デザイナーの上田です。

普段、皆さんはどんなプロトタイピングツールを使っているでしょうか?世の中には様々なプロトタイピングツールがありますが、それぞれ使い方や得意とすることが違っていて、キャッチアップしていくのも一苦労ですよね。

クラウドワークスでも色々なツールを試していて、次はFramerを試してみようということになりました。そして、せっかくなら社外の方たちと一緒にさわってみよう!ということで「もくもく勉強会」というイベントを開催しました。

crowdworks-udg.connpass.com

Framerとは

f:id:ueda1023:20170908172802p:plain

Framer - Design, code and collaborate.

Framerは、Sketchライクなデザインツールとコードエディタを組み合わせたようなプロトタイピングツールで、プログラム(CoffeeScript)を書くことでアニメーションや画面遷移を作っていきます。

プログラムを書かなければいけないので、デザイナー(非エンジニア)にはややとっつきにくいのですが、プログラムだからこそ、作れるものの自由度がとても高く、細かい動きもかなり作り込める点が特徴です。

イベントの様子

f:id:ueda1023:20170908174924j:plain

イベントでは、それぞれもくもく作業をする前に、まずは簡単なプロトタイプをつくる公式のチュートリアルにみんなで取り組みました。Framerはチュートリアルやサンプルが充実してるのもポイントです(全部英語ですが…)。

f:id:ueda1023:20170908174938j:plain

我々も参加してくださった方々もFramerを初めてさわる方ばかりで、試行錯誤しながらも、協力し合いながら進めていきました。なんとか書いたプログラムがサンプル通りに動くところまで辿り着けました。

f:id:ueda1023:20170908175059j:plain

チュートリアルが終わった後は、「もくもく会」です。もくもく会とは、“それぞれ各自もくもくと勉強したり作業したり本を読んだりするだけの会”(もくもく会ポータルより) のことです。各自、黙々と作業します。

f:id:ueda1023:20170908175138j:plain

チュートリアルで作ったプロトタイプをいじってみたり、別のサンプルをさわってみたり。とても可能性を感じるツールなのですが、日本語の情報が少なく、使いこなすまでには苦労しそうです。

懇親会も開きました

f:id:ueda1023:20170908175224j:plain

約1時間の作業の後、懇親会も開きました。Framerを使ってみての感想や、他のプロトタイピンツールについての情報交換など、とても有意義な時間が過ごせたと思います。ご参加いただき本当にありがとうございました!

Framer Japan コミュニティ開設のお知らせ

ここでお知らせです。このイベントをきっかけとして、このたび、日本のFramerユーザー向けに、「Framer Japan」というコミュニティを開設しました!(※ Framerの許諾を得た上で開設しています)

懇親会での「Framerは日本語の情報が少ない!」という話から、イベント後も情報共有していける場を作っていこうということで、使い方の相談・質問や、イベント情報の共有ができればと思います。Framerを既に使っている方も、これから使ってみたいと思っている方も、どうぞご参加ください!

Framer Japan

本だけではわからなかったユーザビリティテストのリアル

f:id:takuto-yao:20170831124712j:plain

こんにちは、UXデザイナーの八尾です。

京都に旅行して久しぶりに自転車に乗ると筋肉痛になりました。運動不足です。

 

UXデザイナーとしてデザイン組織に入り、主に定性調査を任されています。

ユーザーインタビューやユーザビリティテストを通じてユーザーの真のニーズの把握や仮説の検証を行なっています。)

 

今回は、社内で初の試みであった、自社サービスの本格的なユーザビリティテスト(ユーザーテスト、ユーザビリティ評価って呼ばれたりもしますよね)について書かせていただきます。

まだ体制の整っていない中で行った手探り感と自社で定性調査を実施する上での気づきがお伝えできればと思っています。(暖かく見守ってやってください)

 

本を読んでみる。でも、本のようにはいかない

まず、どういう流れで進めればいいのかすらわからないのでとりあえず本を読みながら考えました。

主に参考にしたのはこちらの本です 

ユーザビリティエンジニアリング(第2版)―ユーザエクスペリエンスのための調査、設計、評価手法―

ユーザビリティエンジニアリング(第2版)―ユーザエクスペリエンスのための調査、設計、評価手法―

 

定性調査について広くカバーしており、全体の流れをイメージしやすく教科書のように読み込んでいます。 

 

本を読むと

f:id:takuto-yao:20170830112935p:plain「なるほどなるほど、こんな風に進めればいいのか」

となります。すごくできそうな気がしてきます。

 

しかし、さあやってみようとなると、

f:id:takuto-yao:20170830113116p:plain「いやいや、本で書いてる通りにできればいいけどさ、、」

となるわけです。

 

本の通りにはいきません。

 

なぜなら、

  • ユーザビリティテストは目的によって具体的な方法が変わってくる
  • 本に書いてあるのは理想であり、社内に体制がないこともある
  • 現実のスケジュールは厳しい

からです。

まだユーザビリティテストをやってみようという段階では仕方がないことでもありましたし、経験不足も多分にありました。

 

意識したこと

本のようにはいかないこと、その原因がわかった上で、次にイベントに参加したりして、人の話を聞いてみました。

そして、自分で意識するようにしたことは以下の3点です。

  • テストを実施する上でどういう目的で何をテストするのかを明確にする
  • どういった結果が得られれば成功なのかを具体的にイメージする
  • 最低限の状態のみ整えてその他は実施しながら改善する

一つ一つ詳細を記載しておきます。

テストを実施する上でどういう目的で何をテストするのかを明確にする

 ユーザビリティテストをやろうとすると、ユーザーから聞いてみたいことは多く出てきます。しかし、全てを聞こうとすると本当に大事なことが薄くなってしまったりして、本来の目的が達成されなくなってしまうことがあります。

f:id:takuto-yao:20170830112935p:plain「いやー色々話聞けたな。でも今のサイトの課題はわからなかったな。」

となってしまいます。

 

そのため、「ユーザビリティテストをやってみよう!」という段階で目的をシャープにしておく必要があります。

例えば、

  • 仮説の検証がしたいのか?
  • 実際のアウトプットのユーザビリティ上の課題を知りたいのか?

や、

  • サイトのコンテンツをテストしたいのか?
  • サイトの機能をテストしたいのか?

などです。

目的が明確になっていると厳しいスケジュールの中で、プロトタイプのどこは作りこむ必要があってどこはないのかということが分かります。

また、チームで認識を揃えられるようになり、分析を行う際にも目線を合わせた状態で実施することができます。

 

どういった結果が得られれば成功なのかを具体的にイメージする

目的が明確になっていることと成果物のイメージがついていることは別です。

ユーザビリティテストを設計する上ではこの成果物のイメージが非常に重要だなと感じました。

ここでいう成果物とは、テストの結果何がわかっているのかというイメージです。

つまり、「目的が達成されると具体的に何がわかっているの?」ということです。

 

例えば、

  • XXというコンテンツはファーストビューに入れるべきだ

ということが結論としてでればいいのか、

  • 〇〇を意図してファーストビューを作っていたけどユーザーは△△ということを期待していたようだ

ということが結論としてでればいいのかで、同じページの同じ部分のテストでも中身、分析方法は変わってきます。

 

最終的に得たいもののイメージが具体的についていないと、いざ設計しようとしてもふわふわしたイメージのまま進んでしまいます。

その結果、

f:id:takuto-yao:20170830113116p:plain「あれ、これでいいんだっけ?結局何がわかればいんだっけ?」

ということが発生してしまいます。

 

逆にイメージがついていると、本を参考にしながら具体的な内容をカスタマイズしてオリジナルでも作りやすくなります。

ゴールがはっきり見えていると道も自ずと見えてくるということです。

 

目的と成果物の明確化に関しては、
  • 目的の明確化=チーム全体の目線を揃えるために重要
  • 成果物の明確化=ユーザビリティテストの具体的な中身を作るために重要

だなと感じました。

 

最低限の状態のみ整えてその他は実施しながら改善する

最後に運営面についてです。自社で実施しようとすると運営面までしっかり考える必要があり、機材が整っていないことも多々あります。

f:id:takuto-yao:20170830113116p:plain「本に書いてある機材が社内にない、、うちにだってラボ欲しいよ、、」

という状況です。

その状況に対して、何が担保されていることが一番重要かという問いから始めました。

そして、記録を確実に残すという部分だけは押さえられるようにしておくことを意識して運営面は設計しました。

せっかくのユーザビリティテストでも、記録として残せていなければ機能しなくなってしまうからです。

 

一方、録画の画質や被験者の座る位置などはよくない状態が仮にあってもユーザビリティテストとしては機能します。(もちろん被験者の方の心地よさは非常に重要であるとは感じています)

やっていく中で毎回改善を繰り返していくことができる部分です。

そのため、初めて実施した際にはユーザビリティテスト直後に運営の面については問題点などを整理しておくようにしました。

 

まとめ

いかがでしたか?自社サービスのユーザビリティテストを初めてやってみて気づいたことをまとめてみました。

本だけでは見えてこない部分をイメージしていただけると幸いです。

 

とはいえ弊社の定性調査もまだまだ勉強真っ最中という状態です。

ぜひアドバイスをくださいw

 

また、一緒に学んでいきたいと思ってくださる方(むしろ教えてくださる方)、ぜひランチに行きましょう。

デザイン組織で働くエンジニアは何をやっているの?

f:id:takeru0757:20170825125459j:plain 家ではコロッケを揚げたりしています。

こんにちは。エンジニアの廣瀬です。最近、マツダのプレマシーという車を購入しました。子どもが2人いるのですが、両側電動スライドドアってほんと便利ですね。『ラ・ラ・ランド』のサントラを聴きながら運転するのが好きです。

エンジニアである僕がデザイナー中心のデザイン組織である「UXデザイングループ」に所属するようになって、気が付けば約半年が経ちました。そこで今回は、いわゆるデザイン(ビジュアルデザイン)ができるわけでもない僕が、デザイン組織で何をやっているのか、そんな話を書いてみたいと思います。

※ UXデザイングループの成り立ちや所属に至った経緯などについては、以前に書いた『デザイナーとデザイナーじゃない人でデザイン組織を作る(UX & Service Sketch #27 登壇レポート)』という記事をご覧ください。

続きを読む

文字について考えよう Vol.2

f:id:humcooh:20170817172936p:plain
こんにちは、CrowdWorks UXデザイングループ デザイナー、浜野です。

夏ですね。みなさん恋してますか?
じつは私、ひさしぶりに一目惚れしてしまいまして。といっても「本」に、なんですけどね。
先日、グラフィック社さんから、とっても魅力的な本が発売されました。その名も「定番フォントガイドブック」。和文・欧文の定番フォントなどを約700書体も収録している、書体好きにはたまらない一冊となっています。
また、よくある書体を収録されている本との違いは、ここ数年で新しく追加された書体までしっかりと収録しているのに加え、和欧混植の見本まで網羅している、「今、買うべき書体のガイドラインの決定版」と言える内容ではないでしょうか。

本の内容もさることながら、私が一目惚れしたのは本のデザイン(装幀)なんです。
f:id:humcooh:20170817114623p:plain
f:id:humcooh:20170817114205p:plain
f:id:humcooh:20170817114239p:plain

簡単に開きやすいように設計されている点も素晴らしく、作業しながら隣に開いて置いてくことができるんです。

さて、そんなわけで久々に書体熱が高まってしまったので、久々に書体について書きたいと思います。前回は、日本語と英語の違いみたいなところでしたが、今回は欧文の基礎について書こうかと思います。

今更、セリフ体・サンセリフ体なんて言われても知ってるよ…と思うかもしれませんが、ここにも細かい違いなどがあるので、知っていて損はないのかもしれません。

続きを読む

コンセプトの使い方

どうも、3回目です。

経営企画室 ブランディングPRチーム アートディレクター
鈴木雄大です。

今回のテーマは「コンセプトワーク」について。

Concept(コンセプト)=【意味】構想、発想、考え、概念 と、いうことなんですが、

鈴木が大事にしていることは「概念の理解と共有」です。

では、先日リリースされたばかりのサービス

「経営課題を抱える企業」と「課題解決のスペシャリスト」とのマッチングサービス|BRAIN PARTNER(ブレーンパートナー)

f:id:yudai-cw:20170808220639p:plain

これの宣伝がてら、制作の思い出とともに解説します。

事業立ち上げのとき

この事業、立ち上げからLPのリリースまで実に4ヶ月(構想も含めるともっと)かかっています。

一度、5月末に事業メンバーから、LPの制作を依頼されたのですがその時、狙いはあって営業するものの、まだクライアントからの発注依頼もなく、LPをリリースするための一番の目的はアポを獲得することでした。

この時、鈴木が感じた課題は、

  1. ターゲットに対して、事業にどんなメリットがあるのか。

  2. そもそも、そのターゲットってあってるのか。

  3. この事業が世の中に提供できる価値や解決できることってなんなのか。

  4. これらの仮説が合っていたとして、最適なコミュニケーションってなんなのか。

でした。

LPはいくらでも作れますが、営業をかけてアポがない時点で、1〜3の可能性が捨てきれない(何を訴求すべきかわからない)以上、自信を持ってやろうという決断はできませんでした。

結論、事業メンバーとは一旦、今想定しているターゲットに対して明確なメリットとファクトを整理した営業資料を作るのはどうだろうという結論に。

その後、とてもわかりやすい営業資料ができて、スイスイとアポが獲得でき(資料だけじゃなく、とんでもない営業量の結果もあると思います)7月、ターゲットも明確になりLPの制作に入ることになります。

コンセプトワークについて

ここで、まずやったことは、コンセプトの言語化とネーミングとロゴ制作。

今回のアートディレクションとしては、ここが一番事業メンバーとのやりとりに時間をかけた気がします。

で、言語化されたのがこれ。

f:id:yudai-cw:20170808214715j:plain

で、ここからアウトプットしたネーミングがこれ。

そして、これをセットに事業メンバー以外からの投票でネーミングを決定しました。(ファーストインプレッションで、伝わるかどうか、主観が入らないようにするため。)

選ばれた理由としては、

  • クライアント目線で見ると、他の案は助けてくれなそうに感じる。

  • 受注を取るのにまず課題はクライアントの目線が入ったネーミングがいいのでは。

など、LPの設計をする上でも重要な意見がありました。

デザイン制作について

LPのデザインに入ってからも大事なのは、言語化されたコンセプト。

「企業と人材を、次のステージへ。」

ネーミングでの投票の意見やこの言葉から導き出される、設計は

TOPでは、受注者・発注者両方にメリットが伝わるけど、バランスとしては、「発注者6:受注者4」くらいのメリット訴求。その配下にくるページで受注者・発注者を分けてメリットを訴求すること。

おかげで、LP設計やトーン&マナーの議論、デザインをするデザイナーも迷わず作業ができ、比較的揺り戻しも少なくデザインが進行できたのではと思います。

と、いう感じで、伝えたい価値やなぜこのデザインなのか。全てが、コンセプトに紐づいて会話が行われていたので、立場や役割が違う間柄でも理解でき効率もよく、余計な軋轢を生みませんでした。

で、完成したLPがこれ。“経営課題を抱える企業”と“優秀なブレーン”をつなぐ|ブレーンパートナー

※運用の都合で、フォームや諸々イケてないとこありますがw

まとめ

  • 構想は構想なので、伝えるためにその構想を事実を元に具現化する。

  • 磨いた構想は、概念になるが概念のままだと、まだ伝わらないので客観性を持って具象化する。

  • 具象化した概念に基づいて、ズレがおきないよう伝わるように具体化する。

と、考えます。

人によって「コンセプトの使い方」は違うと思いますが、いろんなやり方があるので一意見として、みなさんの参考になると嬉しく思います。

※最適解があれば、マジでご意見ください。飲みましょう。

ということで、クラウドワークスでは、様々な職種を募集しております。

www.wantedly.com

ぜひどうぞ。

デザイナー読書会の運営方法について(クラウドワークス・UXデザイングループ編)

f:id:yusuke-tamura:20170802175448j:plain

こんにちは。デザイナーの田村です。

今回は、わたしが所属するUXデザイングループで行われている「読書会」の運営方法についてご紹介します。

実はわたくし、UXデザイングループの中では、読書会や週次勉強会、そしてこのブログの運営なども担当させていただいています。

前回の記事では、「試しに読書会をやってみたら、こんなメリットがあったよ!」ということをご紹介しましたが、気がつけば読書会はUXデザイングループの中ですっかり定着し、今では毎週のように開催されるようになりました。

その過程で、当初は手探りだった運営方法も、回数を重ねるごとにブラッシュアップされてきています。

そこで今回は、これまでのデザイナー読書会を通してわたしなりに得られた運営方法に関する知見を吐き出してみたいと思います。

この記事を読めば、まだ読書会をやったことがないチームでも、スムーズに取り入れられるようになるかもしれません…!

興味のある方は、ぜひ最後までご覧ください。

続きを読む

良いUIライティングの定義って?(UIライティングについて考える連載 vol.2)

みなさん、こんにちは。UXデザイングループ マネージャーのアタラシです。ここ数ヶ月、浦和レッズの調子が悪すぎて、もう最近は試合の日がやってくるのが怖いです。
 
さて、ぼくの専門はコピーライティングです。前回のUIライティングについて考える連載 vol.1というエントリーに続き、UIライティングについて書きたいと思います。今回は、そもそも論にしてみます。
 
 

「良いUIライティング」の定義は何か?

最近、考えてたんですよ。そもそも、良いUIライティングとは、一体何なのか。良い文言って、どんな文言なんだ?「意味が理解できる」とか「短くまとまっている」とか「サービスの世界観に合っている」とか「コンバージョンが上がる」とか、色んな視点で、色んなことが言えそうです。でも、なんかどれも決め手にかけるんですよねえ。
 
ということで、「良いUIライティングとは、こうだ」ということを、今回、ぼくが何かしら強引に、言い切ってみることにします。一度誰かが言い切ってみるのもいいのかな、とも思いますし。 
 
 

良いUIライティングとは、「ユーザーが迷いなく判断できる言葉を書くこと」だ。

いきなりサクッと言い切ってみました!割と気軽に。もっといい定義があるな、と思えば、今後、どんどん更新していくつもりです。では、なぜ、ぼくはこう定義したのか、ということ次に書いてみます。
 
 

ユーザーが行動するには、道しるべが必要。それも、ハッキリとした。 

基本的に、ユーザーには、必要以上の努力を強いてはいけません。ユーザーの努力は、省ける限りは、極限まで省いてあげるべきです。これは、「文章を読む」「リンクを探す」「文字を入力する」などといった物理的な行動努力はもちろん、「絞り込み方法に悩む」「文言が伝えんとする真意を考える」といった思考努力についても同じです。
 
そういう意味では、最もよいUIライティングとは、何も文言がない状況をつくること、とも言えるかもしれません。ビジュアルだけでハッキリと判断できる状態にする。読まずに見るだけで済むのであれば、ユーザーの努力は少なくて済みます。
 
運転中の赤信号とか最高ですよね。「止まれ」とか書いてなくても、赤い色を見たら、ぼくらはみんな止まれます。これは日本人には、「赤は止まれ」というコンテキストが根付いているから(それを理解することが免許取得の条件だから)。コンテキストがある限り、信号に文字で「止まれ」と書く必要はない。(色弱の方にアプローチする信号デザインについては、ここでは省略します)
 

f:id:takeshi-atarashi:20170727232919j:plain

 
 

UI文言は「短く、明確に」?

WEBの話に戻ります。ビジュアルだけでユーザーに判断させてあげられない場合、いざ文言が必要になってきます。さて、どんな文言ならよいのか?よく聞こえてくるのは「短く、明確に」的な声です。間違ってはいないと思いますが、「ユーザーが判断できる範囲において、短く、明確に」のほうが、正確な言い方になるのかな思います。
 
 

ここから急に、カレーの例え話。

もし、ある日、オフィスにあるあなたのデスクに
 
 カレー
 
と書かれたボタンが設置してあったとしたら、あなたならどうしますか?
 
とりあえず一旦、考えますよね。「これはイタズラなのか?ぜったいイタズラだろ。もしイタズラじゃないとしたら、なんなんだ。押したらカレーがどこかから出てくるのか?でもそんな穴はない。あ、匂いか?どこからかカレーの匂いがしてくるんじゃないか。よし押してみよう・・・ってなるか!ぜったいイタズラだろ。」みたいな感じですかね (-⊡ω⊡)+
 
でも、
 
 席までお届け!カレー ¥1000  (カレー屋バンバン) 
 
と書かれていたら?ぼくなら、とりあえず押してみるかもしれません!イタズラなのかも?とは思うと思いますが、意味は明確だし、イタズラだとしても別にいいやと判断できるので。
 
・・・なんか例え話に失敗したかもですが、まあそういうことです (-⊡ω⊡)+
 
ユーザーが思考する必要のないくらいにUI文言が整理されていると、ユーザーが行動を起こすかどうかは置いておいて、少なくとも、自分が何をすべきかは明確に判断できます。
 

ちなみに、上記の「席までお届け!カレー ¥1000 (カレー屋バンバン) 」は、注文ボタンの文言として長くないの?という意見もあるかと思います。確かに、長いです。でも長くて問題があるのかといえば、ぼくは「問題ない」と思います。これはボタンが設置されている環境によるところです。オフィスのデスクに、このボタンがあるという特異な状況を考えるに、文言が長いことよりも、その意味が伝わることのほうが、はるかに大事。UI文言の長さが気になる方は、「ユーザーが判断できる範囲において、短く、明確に」という考え方で、チェックしてみてください。

 
見出しが使えるなら、見出し文言を「席までお届け!カレー ¥1000 (カレー屋バンバン) 」にして、ボタンには「注文する」と書くのがよいかもしれませんね。あと、もし、カレー屋の中にある券売機にこの文言があったとしたら・・・それは、長いっすね。長いというか、無駄が多すぎる。「カレー ¥1000」だけでいいでしょう。
 

f:id:takeshi-atarashi:20170727232402j:plain

 

ボタンだけじゃなく、あらゆるUI文言に言えること

この記事で「良いUIライティングとは、ユーザーが迷いなく判断できる言葉を書くことだ」ということを書くにあたり、ボタンの文言の話だとわかりやすいので、それで貫きましたが、アラート文言やFAQなど、WEB上のあらゆる文言について、この考え方は適用できるものだと思っています。
 
とにかく、ユーザーが判断できるかどうか。これだけを考えて文言をつくるといいと思います。もしそれが難しいのであれば、コピーライターを雇うといいですよ。
 
なお、本来は、サービスのターゲットや、つくりたいトーン&マナーを踏まえた上で、UIライティングすることも必要なのですが、そのへんの話は、また今度。ちなみに、クラウドワークスのユーザー層は年齢もリテラシーも本当に多種多様なので、ユニバーサルな言葉づかいを意識しています。(ぼくが入社して以降、ぼくが関われたところに関しては!)
 

ていうか、カレーの例え話、どう思いました??

やっぱひどいですかね。ぼく、例え話が好きなんですよね・・・すみません。なんだかカレーが食べたくなってきました。
 
さてさて、「『登録』と『登録する』なら、どっちがいいの?」みたいな、実務に直結する話も書いていきたいところですが、まあそのへんは、あなたとぼくが直接お会いしたときにでも!
 
あ、そういえばクラウドワークスでは今、デザイナー採用をやっているので、この機会にどうでしょうか。ぜひぜひ、ランチにカレーでもいきましょうよ。
 

UXデザイングループメンバー(+α)のホーム画面を公開してみる

f:id:takeru0757:20170721172713p:plain

こんにちは。エンジニアの廣瀬です。いまだに『ラ・ラ・ランド』のサウンドトラックを聴きながら会社に通っています。ブルーレイほしいです。

前回の記事では“UXデザイングループの働き方”をテーマに、使っているツールや仕事の進め方についてお伝えしました。今回はもう少しクローズアップして、メンバーそれぞれのスマホのホーム画面をご紹介したいと思います。

というのも、昔、37signalsが同様の企画をやっていてそれがとても面白かったので、このブログを始めるときにいつかやりたいと思っていたのです。

それでは早速ご紹介します。(特別ゲストとして、COO成田とCTO弓山にも参加してもらいました)

続きを読む