CrowdWorks Designer Blog

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

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

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弓山にも参加してもらいました)

続きを読む

UXデザイングループの働き方に密着レポート!

f:id:humcooh:20170710205334p:plain

こんにちは、最近ボルダリングを始めようとは思っているけどなかなか踏み出せない、出不精デザイナーの浜野です。 今日はみなさんに、私たちの働き方を知ってもらおうと、 UXデザイングループ(以下UDG)の働き方レポートをお届けします。私たちがどのように日々、仕事をしているのかを少しでも知ってもらえたら嬉しいです。

使用しているツール

まずはじめに、私たちがどのようなツールを使っているのかをご紹介します。

デザインツール

Sketch

今や定番となっているUIデザインツールですね。 UDGでは、去年の3月からこのSketchをメインツールとして使っています。 様々なプラグインがあり、使いやすいようにカスタマイズできるのが魅力です。

f:id:humcooh:20170710193726p:plain

Adobe Illustrator

言わずと知れたグラフィックツールですね。 メインでSketchを使用していますが、ここ一番でこだわりたい時やロゴ制作の際には「かゆいところに手が届く」とても頼れる存在ですよね。

f:id:humcooh:20170710194703p:plain

Adobe Photoshop

こちらも王道画像編集ツール。 ビジュアル要素を含むページやバナー制作などの画像を使用する際には、無くてはならない存在です。

f:id:humcooh:20170710193823p:plain

Zeplin

一部のチームでは以前から導入していましたが、最近チームに正式導入した、デザイン仕様書やスタイルガイドを共有できるツールです。 Zeplinの導入により、エンジニアさんとのコミュニケーションが格段と手軽になりました。

f:id:humcooh:20170710194825p:plain

Prott

デザインプロトタイピングツールです。 主にデザイナー以外の方とのコミュニケーションやアプリの画面遷移をチェックしたい時などに使用しています。

f:id:humcooh:20170710194852p:plain

その他

その他にも、業務の最適化に向けて様々なツールを日々検討しています。 Origami StudioやinVision、Adobe Experience Designを少しさわってみたり、最近はインタラクションデザイン領域に手を出したくてAdobe After EffectsやFramerで遊んでみたりしています。 ぜひ、みなさんのオススメのツールなどがありましたら、教えていただきたいですー。

f:id:humcooh:20170710200327p:plain

UI BATTLEというイベントに参加した際に実際にメンバーが作成したものです

業務管理ツール

Slack

CrowdWorksでは社内のコミュニケーションはSlackを使用しています。 チームのバーンダウンチャートを自動で通知してくれるbotを仕込んだりと、業務の最適化をSlackでも行なっています。 また、コミュニケーションのみではなく、いつもチェックしているブログやTwitterなどの情報を集めるチャンネルを作って、情報収集の場としても活用しています。

f:id:humcooh:20170710213848p:plain

Googleカレンダー

スケジュール管理はGoogleカレンダーを使用しています。 各会議室やカメラなどの備品の貸し出しまで一貫して管理しています。 突然謎のミーティングが設定されて困惑することも…?

f:id:humcooh:20170710213855p:plain

Trello

プロジェクトや、業務の進捗はTrelloで管理しています。 全チーム横断のデザイン組織のため、タスク管理はとても大変ですが、Trelloの導入によりタスクの可視化、管理が格段と改善されました。

f:id:humcooh:20170710213924p:plain

ふせん

ふせんを使うと全員が発言できるので議論が活発になり、今では欠かせない存在です。 ブレストのまとめなどにも最適で、グルーピングも手軽にでき、議論の趣旨や全体像の理解も深まります。 アナログなので、リモートワークとの相性が悪いのでその点は考慮しなくてはなりませんね…。

f:id:humcooh:20170710204922j:plain

チームの一週間はこんな感じ

月曜日はプランニングDAY

UDGではスクラム風のチーム体制をとっています。 週の初めに今週のプランニングを行なっています。 ポイントの管理などはTrelloを活用しています。

水曜日はNOミーティング、NO残業DAY

私たちデザイナーにとって集中して作業できる時間はとても大切です。 ミーティングばっかりで作業時間がなかなか取れない、ということがよくありました。 そのため毎週水曜日は「NOミーティング、NO残業DAY」とし、作業のみを行い定時に必ず帰る日、としました。

f:id:humcooh:20170710220245p:plain

毎週水曜日にUDGのSlackチャンネルに定時近くになると警告してくれるようにbotを仕込みました

金曜日は振り返りDAY

週の初めにしたプランニングをもとに、一週間を振り返ります。 単純に振り返るだけではなく、ポイントの消化率や理想的なポイントなどの精査を行なっています。

f:id:humcooh:20170710202738p:plain

働き方の多様性を目指して

CrowdWorksでは働き方の多様性、個々の可能性を最大化するための人事制度があります。 実際に自分たちでも活用しているとても魅力的な制度なので、ご紹介出来ればと思います。

リモートワーク

1週間に3日まではリモートワークが可能です。 朝の出勤にかかる時間を考慮しなくていい点や、作業に没頭できるのが魅力的ですね。 始める前はコミュニケーションに不安がありましたが、Slack上でのコミュニケーションやビデオチャットを用いながら、実際にUDGのメンバーでトライする中でその不安は解消され、今では全てのメンバーがリモートワークを気軽に行えています。

f:id:humcooh:20170712162957p:plain

フレックス

10 -16時のコアタイム以外は自由に時間を使うことができる制度です。 イベントや勉強会に行ったり、社外の人との交流など、自分のスキルアップなどにも活用しています。 たまに「今日はもう飲みに言っちゃおうか」なんてことも…?

f:id:humcooh:20170710211917p:plain

お子さんがいるメンバーはフレックスを利用して早めに帰宅する日も

のびのびと仕事をしています

集中ROOM

作業に没頭できる場として、集中ROOMという個室がオフィスに設置されています。 もくもくと作業したい場合に篭る場所として活用されています。 ちょっと殺風景なので、私はあまり利用しませんが…。

フリースペース

イベントスペースとしても活用されているMixLab。 このMixLabの奥には「小上がり」が存在し、社員が自由に使用することができるスペースがあります。 ちょっと気分を変えて作業したいときに活用しています。 ここから見る景色が好きで、私もちょくちょくこの「小上がり」を活用しています。

f:id:humcooh:20170712162201p:plain

f:id:humcooh:20170712162418p:plain

さいごに

いかがでしたか? 少しでも私たちの働き方がお伝えできたでしょうか。 イベントなどでお会いしたら「うちのチームではこんなことしてるよー」や「このツールよかったよー」などの意見交換をさせていただきたいです。

また、CrowdWorks UXデザイングループでは、一緒にデザインしてくれる仲間を募集中です! 少しでも興味を持ってくれた方、小上がりってどんなところ?など気になった方、お気軽にオフィスに遊びに来てくださいー。 お待ちしています。

www.wantedly.com

instagramはじめました!

私たちの日常をもっと知ってもらうために、instagramをはじめました! ぜひ、フォローしてくださいー。 www.instagram.com

各デバイスを含めた、サービス全体を考えてモノを作るための授業(UX Failcon 登壇レポート)

f:id:ueda1023:20170703141628j:plain

こんにちは、デザイナーの上田です。最近 High Resolution という海外のデザイン組織を特集している Podcast を聴き始めてまして、あまりに面白いので、全コンテンツ日本語訳できないかなーと、もやもや検討してます。

さて、先日 UX Failcon 〜先人たちの偉大な失敗と成功〜というイベント (主催はDMM.comラボさん、UX MILKさん、CAREER HACKさん)でお話をさせていただきまして、今回はそちらの記事を書かせていただければと思います。

uxmilk.connpass.com

UX Failcon 俺みたいになるな!!

f:id:ueda1023:20170703164836j:plain

f:id:ueda1023:20170703164829j:plain

UX Failcon とは、テレビ朝日で毎週日曜よる21時58分〜放送されている「しくじり先生 俺みたいになるな!!」というテレビ番組をイメージし、UXデザインを実践した事例の中から、失敗した経験とそこからの修正と着地までの話を提供するといった趣旨のイベントです。

登壇のお誘いを受けた際、改めて自分自身の経験を振り返ってみていくつか候補が浮かんだのですが、失敗からの修正や着地といったところに比較的対処できているアプリプロジェクトでの話を今回はさせていただきました。

PCメインのサービスなのに、アプリ好き勝手に作っちゃった

しくじり先生のフォーマットに習って整理すると、

  • どんなしくじりか?
    • 好き勝手にアプリをつくった結果、使いづらいアプリにしてしまった
  • どんな先生か?
    • PCメインのサービスなのに、PCとの一貫性を無視してアプリ好き勝手に作っちゃった先生

といった内容でお話しさせていただきました。

クラウドワークスはもともとPCのみだったのですが、2015年以降アプリでもサービスを展開しています。

私はアプリのプロジェクトでサービス改善やUIデザインの担当として関わっていたのですが、プロジェクトの進め方やUIデザインにおいてしくじりポイントがあったので、そのあたりの内容をお話しいたしました。

詳しい内容は、以下のスライドをご覧いただけると幸いです。

伝えたかったこと

スライドにもある通り、アプリ未経験でプロジェクトに取り組んだ背景もあり、目先の数字だけに囚われて定性的なものを軽視してしまったり、PCメインのサービスなのにアプリ独自の仕様をたくさん詰め込んでしまったりと、反省点の多いプロジェクトでした。

サービス改善の経験を重ねたり、UIデザインを学習する中で当時を振り返って「じゃあ、どうすればよかったのか?」と見えてきた部分もあるので、同じ失敗を繰り返さないための教訓として、以下のような内容を共有させてもらいました。同じような状況にある人にとって、少しでも参考になればと思っています。

教訓 其ノ一「数字だけに囚われることなかれ。」

定量的な数字のみ追ってしまい、定性的なものを軽視していたので、 自分たちが好き勝手に作ってしまったことに気づけなかった。

教訓 其ノ二「アプリはユーザー体験の一部。一貫した設計を意識せよ。」

デバイスの役割は被り、はっきり切り分けられない。 逆に機能に一貫性を持たせることで、相互に代替できるようにすべきだった。

さいごに

UX Failcon は企業やプロジェクトの規模を問わず、普段聞けない失敗事例を知れるので、自分自身も他の登壇者の方の話を聞いてとても勉強になりました。後日、CAREER HACKさんがイベントのレポート記事を公開して下さるそうなので、よろしければそちらもウォッチしていただけるとうれしいなと思います。

といった感じで、日々、試行錯誤しながら業務に取り組んでいます。そんなクラウドワークスにご興味ある方、恵比寿のオフィスまで気軽に遊びに来てください!

最後までお読みいただき、ありがとうございました。

www.wantedly.com

デザイナー以外へUXガイドラインを浸透させるためにやったこと

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

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

今回は以前公表し、多くの方に読んでいただいたクラウドワークスの"UXガイドライン"について書こうと思います。

UXガイドラインとは、 クラウドワークスというサービスが提供すべきユーザー体験の指針を、11ケ条・33項目にまとめたものです。

さて、今回は作成したUXガイドラインをどのようにデザイナー以外のメンバーに浸透させたかということについての記事を書こうと思います。

やったことは大きく二つです。

  1. UXガイドラインを印刷、メンバーに配布
  2. UXガイドラインをもとにワークショップを実施 

1.UXガイドラインを印刷、メンバーに配布

せっかく作ったガイドラインも、デザイナーが利用するだけでは不十分です。

なぜならUXガイドラインはデザインをする上での指針ではなく、プロダクト全体の指針だからです。

まずはとにかく多くのメンバーにみてもらおう、手元に置いてもらおうという思いでUXガイドラインを印刷し、実際に本にしました。

画像のようにしっかりと表紙をつけ、中には目次やはじめにという項目をつけ一つの読み物として成立するよう工夫しました。

そして製本も自分たちでやりました!

f:id:takuto-yao:20170628101204p:plain

そして完成したのが↓

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

それに加えて各チームの使用しているホワイトボードにフライヤーを設置してメンバー全員に周知できるよう工夫しました!

↓こんな感じ

f:id:takuto-yao:20170628100938p:plain

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

ここまでで結構時間と労力かけてます(笑)

2.UXガイドラインをもとにワークショップを実施

UXガイドラインの印刷・配布によって社内認知を広めた後に、メンバーにしっかり使ってもらえるようワークショップを実施しました。

対象はプロダクトに関わる全社員。

ワークショップの様子は以下の写真をご覧ください。

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

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

ワークショップの内容は?

ワークショップでは仮想の機能を題材にしてワイヤーフレームを書くという内容でした。

扱った題材はクライアントからクラウドワーカーにお歳暮を送れるという機能でした!

※私たちが運営する「クラウドワークス」は、お仕事を発注する「クライアント」と、お仕事を受注する「クラウドワーカー」をマッチングするサービスです。

  1. クライアント→クラウドワーカーでお歳暮を送る機能のワイヤーフレームをUXガイドラインを見ずに作ってみる

  2. UXガイドラインを使ってレビューする
  3. チームのアウトプットをお互いにシェア

という流れで行いました。

考えやすいようにお歳暮はクッキーかamazonギフト券に限定したり、技術的な難易度は考慮しないようにするなどいくつか前提を加えました。

こういった前提は事前にUXデザインチームでリハをした時に議論になったものを反映しています。

工夫した点

  1. 仮想の機能を題材に用いたことで既存の機能などとは切り離し、比較的0ベースで考えられるよう工夫しました。
  2. 実際のアウトプットに対してUXガイドラインを利用することでリアルな使い方をイメージづけてもら得るようにしました。
  3. UXデザインチームのメンバーも全員出席し、フィードバックやUXガイドラインの解説を行い、楽しみながら理解が深まるようにしました。

実際やってみてどうだった?

ワークショップを実施したことで実際多くのメンバーにUXガイドラインの活用法についてイメージしてもらうことができました。

アウトプットの内容もチームごとに大きく異なるところがあり楽しみながら実施することができました!

実際、ワークショップ後のアンケートではこのような声がありました。

・判断に迷った際などの根拠になると思う。参照していきたい。

・今回実際に使うことができたので、どのように活用したらいいかイメージが湧きました。事例もあったのがよかったです。

・ワークショップで体感的に理解が進んだ

・根拠としてガイドラインを使うことでコミュニケーションが円滑になりそうです

短い時間のワークショップとはなりましたが、まず具体的なイメージをつけてもらうという意味では非常に意味のあるワークショップになったなぁと感じています。

感じたこと

社内に新たな文化や仕組みを浸透させる上で重要だなと感じたことは徹底することです。

プロダクトに関わる社員全員の時間をいただいて、かつ、デザイナー全員の時間を使って一つのドキュメントへの理解を得る機会を作るということは簡単なことではありません。通常業務で忙しい中そんなことをしている暇はないという声もあると思います。

それでも作りたての今だからこそ、徹底して全社員に伝わるようにある程度コストを割いて工夫を凝らすことが将来的にはいいプロダクトを作ることに繋がると試していく中で感じました。

最後に 

いかがでしたか?

社内で作った指針をどのように社内に浸透させたかという内容でした。

そうはいってもまだやれることはたくさんあるので、今後当たり前に使われるようにどんどん新しいことをやっていきます!

 

そんなデザイン文化を築こうとしているワクワクする時期のクラウドワークスUXデザイングループではデザイナーを募集しています。

ご興味ある方はぜひ遊びに来てくださいね!

www.wantedly.com