LoginSignup
372

More than 1 year has passed since last update.

「1枚のシート」でエンジニアとデザイナーのストレスが激減した話

Last updated at Posted at 2021-12-11

「考慮もれ」「手戻り」をなくしたい

モチベーションクラウドシリーズのデザイナーです。
フロントエンドエンジニアのみなさんは、画面デザインを見て「どう実装するんだ?」とストレスを感じたことはないですか?
例えば...
👨‍💻 フロントエンド「Emptyのときはどうするんだろう?最初から考慮してほしいな...(ストレス)」
👩‍🎨 デザイナー「この状態も考えないといけないのか。確認するだけで1日終わるな...(ストレス)」
 →お互いにとって、よくない!!!!!

こうした状態を受けて、お互いにとってストレスなく開発するために、デザイナーとフロントエンドで制作プロセスを改善しました。
今回は、プロセス改善のステップや導入してみて効果的だったツール(シート)についてお伝えします。

【まず初めに】 「UI Stack(状態デザイン)」の必要性の周知

UI Stackとは、UIの考慮すべき5つの側面のことです。
以下の5つを設計時に考えることで、漏れなく統一的なUIを作成・実装することができます。

参照元:How to fix a bad user interface, Scott Hurff

image.png

- Blank State(データが入っていない状態)
- Error State(エラー状態)
- Loading State(ローディング状態)
- Partial State(部分達成状態)
- Ideal State(理想状態)

それぞれの具体例は、こちらの方の記事がとても参考になります。

当初、私たちの開発チームでは、デザイナーによってUI Stackに対する認識や対応の度合いが異なっていました。
あるタイミングでフロントエンドの方からUI Stackについて提案を受け、「理想」状態だけでなくそれ以外の状態も、デザイナー全員が考慮してフロントエンドに引き継ぐべきだよね!とチーム全体で認識を揃えました。

【次に】開発プロセスにUI Stackの確認を埋め込む

「意識しましょう!」だけでは変えるのは難しいため、デザイナーとフロントエンドの引き継ぎプロセスを改善しました。
具体的には、UI Stackを踏まえた「画面一覧」を開発の早いタイミングで確認するようにしました。

1. 「画面一覧」の作成

  • いつ:
    • 開発PJTが始まってすぐ
  • どのように:
    • デザイナー(ワイヤーフレーム制作担当)が「画面一覧」を作成
      • わかる範囲でOK、まず資料がある状態にしておく

image.png
最初はこのくらいざっくり

2. 「画面一覧」をもとに、画面数や実装工数を確認する

  • いつ:
    • 要件定義書が大体書き終わった後、1週間後くらい
  • どのように:
    • デザイナー(ワイヤーフレーム制作担当)が、UI Stackも考慮してワイヤーフレームを作成→「画面一覧」を更新
    • フロントエンドエンジニアが、事前にWFと画面一覧を見て、考慮・追加してほしい画面や要素がないか確認
    • デザイナーとフロントエンドでミーティングを実施・認識合わせを行い、考慮漏れについて対応
    • 上記がある程度完了後、UIデザイン制作に移る

image.png
デザイナーがわかる範囲で洗い出し、すり合わせる

【結果】生産性の向上・ストレスの軽減→UX/UIの質向上に

  • 後から考慮もれが発覚して手戻りすることがなくなり、開発全体の生産性が向上しました。
  • 早い段階で全体像を把握しておくことで、各状態デザインに対して統一的なUX/UIの設計に余裕を持って対応できるようになりました。

合わせて、こんな効果もありました。

  • 「画面一覧」に完了日や進捗状況を記入する欄を作ったことで、「作成中」などデザインの進捗も分かるようになり、無駄な確認作業を大幅に減らすことができました。
  • 結果として、お互いの作業状況が常にわかることで、安心感を持って開発を進めることができるようになりました。
  • また、テストケースの抜け漏れを確認しやすくなり、QAメンバーにとっても良い影響がありました。

【最後に】プロセス自体を変えてみよう

追加の工数が増えるようで、最初は面倒に感じるかもしれません。

「管理コスト増えそうだな〜」
「ガチガチにやるとスピード落ちそうだな」
「全部洗い出したり、更新するのがめんどい・・・」などなど

実際、私たちもそうでしたw
最初の立ち上げ段階では、フォーマットを整えたり、ミーティングを入れたりなど、シンプルに「追加対応」なので瞬間的に工数が増えるのは間違いありません。

しかし、開発における「シフトレフト(Shift Left)」の考え方があるように、考慮すべき要件を前倒してデザイン段階で発見・対応することは、(後々必ず確認が発生することでもあるので)開発プロセス全体の効率向上につながりました。
また、より良いプロセスを模索する状態を作ったことで、様々なメンバーから「こうしたら良いのでは?」など声が挙がりやすくなり、結果として継続的・長期的な生産性向上につながっていると実感しています。

魅力的なプロダクトを作るには、プロセスも大事。
私たちもまだまだ試行錯誤の途中ですが、日々進化する開発チームをつくっていきたいと思います。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
372