CrowdWorks Designer Blog

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

クラウドワークスとデザインガイドライン(Nextstage Nite vol.2 登壇レポート)

f:id:takeru0757:20171020173849p:plain

こんにちは。エンジニアの廣瀬です。最近は通勤中に『WOW WAR TONIGHT ~時には起こせよムーヴメント~』(H Jungle With t)をよく聴いています。“Getting better Begin to Make it Better”ってほんと良い歌詞ですよね。

僕たちUXデザイングループもクラウドワークスのデザインを“Getting better”しようとしているわけですが、そのために起こした“ムーヴメント”の一つとして、現在、デザインガイドラインを策定しようとしています。

その取り組みの内容や背景について、株式会社ベーシックさんが開催した『Nextstage Nite vol.2 - 実践されるデザインガイドライン -』にて、弊社のリードデザイナーである上田と僕とで発表させて頂きました。

connpass.com

続きを読む

クラウドワークスにおける情報アーキテクチャ(IA)設計の実践例

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

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

突然ですが、あなたは「情報アーキテクチャ(IA)」についてご存知でしょうか?

何となく「ワイヤーフレームを書くこと?」「エクセルでコンテンツを整理すること?」ぐらいに思われている方も多いかもしれませんね。

しかし、そんな情報アーキテクチャこそ、Webサービスやアプリの使い勝手を大きく左右する重要な要素なのです。

そこで今回は、「情報アーキテクチャとは?」という定義から、わたしが実践した情報アーキテクチャ設計の事例についてご紹介します。

続きを読む

ブランディング、ブランディング言うけど、なんなのかわかりますか?

4回目です。

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

かれこれ書き始めて半年くらい経ちますかね。このブログも。最近、色々な方にお会いすると、読んでますよ!とか、結構言われます。同じことを感じたり、共感してくれたり、やはりこういった活動は大事なんだなと最近感じます。

ということで、今回は、「ブランディングPRチーム」にいるのに、自分でも触れるのが恐くて書くのをためらっていた「ブランディング」について、書きたいと思います。

ブランディングってなに?

みなさん、この言葉には日々悩まされていることだと思います。

ボクもMTGなどで「ブランディングって、なんなのかわかってますか?」と、頭の中でずっとモヤモヤしていたのですが、「ブランディング」って何?と、自分なりに納得できる答えを持っていなかったので、無作為に放たれる「ブランディング」という言葉にグッと歯を食いしばってましたw

でも、もういい加減歯も食いしばりすぎて、血が出そうになったので、整理し自分なりに答えの出し方を考えてみることにしました。

まず、「ブランディング」の「ブランド」ってなんでしょう?Google先生に聞きました。

ブランド(英: brand)とは、ある財・サービスを、他の同カテゴリーの財やサービスと区別するためのあらゆる概念。当該財サービス(それらに関してのあらゆる情報発信点を含む)と消費者の接触点(タッチポイントまたはコンタクトポイント)で接する当該財サービスのあらゆる角度からの情報と、それらを伝達するメディア特性、消費者の経験、意思思想なども加味され、結果として消費者の中で当該財サービスに対して出来上がるイメージ総体。

ここでボクが注目したのは「ある財・サービスを、他の同カテゴリーの財やサービスと区別するためのあらゆる概念。」のところ。

さらに注目したのは、「あらゆる概念」

おいおいw

まじかよww

あらゆるてwww

簡単にわかったフリして使うと火傷するぜ!ってことは、これで誰でもわかると思います。

「ブランディング」というのは、その「ブランド」を誰にでも理解されるための行為・手法ということ。と、いう理解を一旦しました。

自分が何者なのかを理解する。

そのためにまず必要なことは、自分(会社とか商品)が「何者なのか」を自分たちで認識していないといけないということ。

そこで登場するのが、ボクが言うにはコンセプトワークだったりします。(コンセプトの使い方 - CrowdWorks Designer Blog

そして「何者なのか」が定義できたら、さらに「とってもいい人」と思われないといけないので、「ある財・サービス」が「とってもいい人」と思われるために、商品の磨き込みも会社や事業の成長に合わせて、並行して行わなければいけないです。Webサービスでいうと、日々の運用からUXの改善だったりとかですね。(ここを並行して改善をするのは、相当難易度が高いので、あくまでも理想論ですが。)

コミュニケーションする。

次に、当たり前ですが「何者なのか」を元にコミュニケーションしないといけません。

ここで必要なのが「マーケティング」。ただ、マーケティングにも幾つか手法があり、そのなかでも「広告」と「広報」という手法があると思います。が、「広告」は顕在的な層に対しては伝える手段として強い。「広報」だと「何者なのか」を伝えるために、「何者なのか」の社会的意義が強く、かつ、その内容を取り扱う「記者」にその情報価値が「記者」がニュースになると思うように、コミュニケーションの手法を変えなければいけない、この手法の違いが現場で入り混じって捉えられているケースが多いのではないでしょうか。

こんな事が起きた場合に鈴木ならこんな手段で解決。

今メインで、新規&運用デザイン・ネーミングなど全般担当している、クラウドテック(https://crowdtech.jp/)で、デザイナー・エンジニア・事業担当とこれらブランディング考え方を整理して認識合わせをしました。

speakerdeck.com

なぜここまで認識を合わせること、理解を得る活動がなぜ大事かというのは、こちら→経営企画室で勉強会をしました。 - CrowdWorks Designer Blog

これらを通し、ボクらデザイナーが大事にしていることは、全てブランディングにつながっている活動なんだな。と、日々の学びや仕事でボク自身も理解できました。

さらに言うと、常に変化し続ける組織や世の中の価値感の中で、「ブランド」という考え方は日々変化しています。なので、こういった認識を合わせる活動や理解を得るための提案は、関わる人達に対して常に行わないと、全て無駄に終わり、ユーザーに「ブランド」が届かないのではないか。と、ボクは考えます。

告知

ブランディングという壮大な行為の第一歩。創って伝える下準備は完了。あとは、実行するだけ。

こんな、クラウドテックでは今プロジェクトマネージャーを募集しています。

www.wantedly.com

ブランディングも、UXも、ものづくりも、いっしょに最高のものをつくりましょう。

ユーザーのためのデザイン。ユーザーのためのデザイン組織。(CS HACK #07 登壇レポート)

f:id:takeru0757:20170926095209p:plain

こんにちは。エンジニアの廣瀬です。気が付けばすっかり秋らしい気候になってきましたね。色々と切なくなる季節です。『ラ・ラ・ランド』が見たくなります。

先日、『「いいチーム」を育てるUX - CS HACK #07』というイベントに登壇させて頂きました。イベントでは、株式会社ベーシックのCDO(Chief Design Officer)である岡村邦博さんと僕とで、それぞれデザイナーやデザインチーム、デザイン組織に関するお話をさせて頂きました。

cshack.connpass.com

続きを読む

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

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

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

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

続きを読む