カウルTech Blogをご覧のみなさまこんにちは。
2017年の3月にHousmartにジョインしたデザイナーの稲井です。
食う寝る遊ぶが大好きなので色々と回り道してますが、よろしくお願いします。
さて今回はテックブログへの初投稿ということで、デザイナー不在の開発チームにジョインしてからの半年間を振り返って、チーム内でのデザインフローをどのように整えていったか？といった内容で送りしたいと思います。
スタートアップ企業でのインハウスデザイナーの役割や、デザインワークフローの改善に興味のある方は参考にしていただければと思います。
ジョインする前の状況の確認
基本的にエンジニア3人（iOS,Android,WEB,サーバーサイド）の体制で開発をしており、デザインに関しては外部から手伝ってくれるデザイナーさんやフリーランスの方に機能ごとにスポットで依頼しているという状況でした。
サービスとしては徐々に売り上げが上がってきている時期で、さらなる拡大に向けて大幅なUIのリニューアルを控えたタイミングでインハウスデザイナーとして参画することになりました。
インハウスデザイナー不在のチームに入ってまず感じた課題
- アプリとWEB集客用のポータルサイト、Appstoreのキャプチャなどお客様が使い始めるまでに目にするイメージがバラバラで同じサービスだとわかりにくかった。
- アプリ内の説明イラストやUIの表現など、機能ごとにデザインが異なる。
- アプリ内部のテキストレイアウト・ボタンなど細かい部分が統一されておらず使いにくい。
- 画面内に情報が多すぎて見辛い。
- 単発での依頼が多いためデザイナーとエンジニアの作業フローの改善などが行われず、作業効率が頭打ちになっていた。
開発力自体はあり、優れたデザイナーさんも外部から手伝ってくれていたのですが、時系列を経るごとに様々なデザインが重なってしまいわかりにくくなっているなというのが第一印象でした。
単発でのデザイン依頼が多く作業フローなどの整理もあまり行われていなかったため作業効率的にも改善点が残った状態でした。
改善方針
スタートアップ企業にとってリリースの順延はダメージが大きいため開発スピードを落とさず、走りながら整備するためにはどうすればいいか悩みました。
色々と資料を漁る中でLancersのチーフデザイナーの方のスライドを思い出し、参考にさせていただくことにしました。
https://www.slideshare.net/TakeBo/money-fowerd?ref=https://moneyforward.com/engineers_blog/2015/08/13/designers-meeting-201508/
参考になった点 * エンジニアとゴールの目線を合わせるために最初にデザインレビューをしまくった。 * 実装時に他の人（ディレクタ）に実装を任せた結果失敗した。 * デザイナーがやれるところは自分でやりきることで完成度上がる。
ハウスマートの開発チームではディレクターのみをやっている人間はいないので
レビューにチームを巻き込みつつ、できるところは全部自分でやるみたいなスタンスが噛み合うなと思いました。
デザインのスピードを上げつつ、ディレクションもHTMLコーディングもやるという形がいいだろうと。
具体的には下記のような流れでデザインフローを整えていきました。
- 素材ファイルの一元化
- デザイン共有&プロトタイピングフロー整備
- デザイン実装時の作業フロー整備
- 運用フェーズでのフロー整備
STEP1 素材ファイルの一元化
まずはメインとなるSketchファイルを一つのマスターファイルに絞りすべての画面を素早く参照できるようにしました。
バージョン管理の手間を省きコンポーネントの再利用性を高めるためと、 デザインの責任者が知らないところでSketchファイル変更や実装が行われないようにするためです。 Sketchの学習コストはとても低くてエンジニアでも軽い変更などができますが、アプリケーション全体を見渡しながら作業しないと、この画面だけ使われてるボタンカラーが違うとか、平気で出てきてしまうので。。
外部のデザイナーさんにはブランチとなるデザインファイルを別途作成してもらい、後でマスターファイルに取り込む形をとっていきました。
シンボルファイルはInVisionのCraftというプラグインを利用して共有化しました。
マスターとなるSketchファイルのシンボルをシンボルオーガナイザーによって整理し、利用可能なコンポーネントを一覧化しました。ここら辺のSketchファイルの細かい使い方についてはまた別の機会に詳しく書きたいと思います。
STEP2 デザイン共有&プロトタイピングフロー整備
作成したデザインはInVisionというプロトタイプツールを用いて共有化しました。 エンジニアとデザイナーの目線（ゴール）をユーザの目線に合わせるのが目的です。
画面仕様を固める際にお互いのこだわりがぶつかっていいのですが、それが本当にユーザーのためになってるのかわからなくなることがあります。 画面内の表示項目の並びが分かりにくかったり、文言が専門的になりすぎていないか、などプロトタイプでの検証を挟むことで平和的に仕様が収斂されていきます。
社内メンバーと外部のデザイナーさんにInVision上で共有しコメントをもらうようにしました。
修正が必要な場合はデザインを調整して再度レビューを繰り返しプロトタイプを作っていきました。
多角的にレビューが入ることでわかりやすいUIになっていきました。
デザインができると早い段階で積極的にユーザーテストを行いました。
デザインバージョンごとに5名ほどユーザーを募ってテストしました。
ユーザーテストで気づいた点はデザイン責任者としてまとめ、メンバーに共有しました。
チーム内でもいくつか意見が別れるような場面もありましたが、ユーザーテストを行うことで主観のぶつかり合いを避けることができ、客観的にUIの改善点が洗い出されてくるので早い段階でユーザーテストを行うことはチームをまとめていく上で非常に有効だと思います。
STEP3 デザイン実装時の作業フロー整備
実装時に必要な情報をまとめて共有しやすくするためにデザインの実装の段階ではスタイルガイドを作成し、Zeplinにて情報共有を行いました。 スタイルガイドはとても有効ですが精緻にすればするほど維持管理コストも高いのでなるべくコンパクトにすることも同時に考えました。
フォントサイズやカラーやなどの基本的なものの説明にとどめ、Zeplinの機能でオーバレイでのデザイン確認機能を活用していただくことにしました。
カウルのアプリエンジニアチームはSketchも使えるので、コンポーネントのリストを作成する代わりにSketchファイルをそのまま開いてデザイン情報の確認ができるようにしました。 シンボルオーガナイザーというSketchのプラグインを使うことでシンボルをカテゴリごとに整理して表示しコンポーネントリストの代わりとしました。
アプリだけでなく、PCの操作画面のデザインもリニューアルしなければなりませんでしたが、 チームで相談した結果、CSS力は自分が一番高いようだったので自分でHTMLコーディングすることにしました。
チーム内のエンジニアが今まで開発してきたアプリを見せてもらいデザイン力などを確認した上で、自分が行うべきロールの調整をすることでスムーズな実装に繋がると感じました。
STEP4 運用改善フェーズでのフロー整備
運用改善フェーズでは細かい修正や改善をスプリントごとにリリースしています。
まだ試行錯誤の段階ですが大切なのはデザイナー、エンジニアの技術領域とデザインプロセスの共有、 そして定期的な振り返りではないかと思います。
デザイナー、エンジニアの技術領域を共有する
デザイナーとエンジニアお互いに何が困っているのか？を話し合い必要な打ち手を見つけていきました。 まず説明用ドキュメントありきで進めるよりも、お互いの技術領域を共有しながら解決策を見つけていくのが効果的だったと思います。
WEBフロントエンドの領域を例にすると、 デザイナーはHTMLモックアップを組んでエンジニアにRails環境に組み込んでもらうというやり方を取っていましたが、非常に効率が悪かったのでRails環境内でデザイナーがStaticなHTMLを組めるように一緒に改善していきました。
デザイナーはDockerの使い方を教えてもらい、エンジニアはscssのファイルの分割構成や記法を覚えるなどお互いの技術領域を活かしながら作業フローを改善していきました。初期のラーニングコストはあれどもこういった作業によりお互いの理解が深まり、作業効率は高くなっていきました。
カウルでは2週間のスプリント内に1日、生産性を高めるための改善デーを設けています。
今後はデザイナーやエンジニアが増えた時の運用を考慮してコンポーネントやドキュメントなどの整備にも力を入れていく予定です。
新機能追加時はデザインプロセスを共有する
ハウスマートではデザイナーは単にデザインを作るだけではなく、ディレクションも行います。
新機能や改善を行う場合は下記のようなフローを利用しています。
- ユーザーの稼動状況データと、定性的なユーザーヒアリングを行い問題点を定義
- 問題点を解決するための機能の mini spec（プロジェクトの要件を簡潔にまとめたドキュメント）を書く、ここでユーザーストーリーも合わせて定義する
- デザイナーがデザインを作成
- チーム内でUI/UXの観点からレビューを実施
- エンジニアがシステム設計と実装
- デザイン面でのチェックが必要な場合はデザイナーが最終チェック
- リリース
- 実装後にKPT(Keep/Problem/Tryの洗い出し)を行い作業フローについて見直し、エンジニアからやりづらかった点があれば次回からやり方を変えていく
特徴的なのは、デザイナーであってもエンジニアであっても全員が mini spec を書くことができることです。
基本的には問題の解決に対して一番理解が深い人が担当することになっています。
例えば、デザイン面での変更・追加であればデザイナー。バックエンドの速度改善などの場合はエンジニアが担当することが多いです。
この段階でユーザーストーリーを定義しておくことで、UXの質を高めています。
特にKPTに関しては毎回非常に有用な意見が出てくるのでデザインに限らず、ワークフローを改善したいチームにはオススメです。 大事なことなので２回言いますが振り返りは本当に大事です。
デザインフローの改善結果
デザイナーへの単発外注体制からインハウスでのデザイン体制に切り替わったことでデザインの方向性が一つにまとまってきました。
また作業の効率化も認められます。KPTでの洗い出された問題点は毎回スプリントで問題解決を行なっており、前回のスプリントでは１週間かかっていた作業を3日で終わらせることができ、浮いた時間を他のクリエイティブな作業に回すことができるなど好循環が生まれつつあります。
今後はアプリケーションのUIからWEBサイトや集客用のサイトまで、より強固なブランディングイメージの統一などを行なっていく予定です。
まとめ
- チームメンバーの数とスキルセットをちゃんと確かめてそれに合わせたデザインフローを作ることが重要。
- スタイルガイドはデザイナーからエンジニアへの一方的な指示書ではなくコミュニケーションのツール。エンジニアが実装に必要な情報量を確認し、まずは最低限必要なものを用意して一緒に補強していくのが吉。
- プロトタイプでユーザーテストを行う。UIの方向性で意見がまとまらなかったりする場合はユーザーにとっても使いにくいものしかできないので、早い段階でテストして観察しプロダクトチームの意見をまとめるのが良い。
- 運用段階では高速で施策が回っていくため、UIがブレやすくなる。デザイナーとエンジニアの知識を共有しながら、最適な解決策（共同作業環境構築やスタイルガイドなど）を見つける。
- 作業フローは定期的に振り返り、常にメンテナンスする。
メンバーの増加や新技術が出てくれば、デザインワークフローも大きく変化していくので 定期的に振り返りながらメンテナンスする意識が大切だと思いました。
今後ハウスマートはデザインチーム体制を強化していく予定です。
プロダクトだけでなく、マーケティング・ブランディングもデザインしたい
欲張りなデザイナーの方、応募をお待ちしております。