![見出し画像](https://assets.st-note.com/production/uploads/images/146644719/rectangle_large_type_2_91e6369bbb67472e8c8a88ed96c25df5.png?width=1200)
SaaSUIの割れ窓リストを作って、解消プロジェクトを進めてみた話
こんにちは。クラウドワークスデザイナーのえらです。
私は現在、クラウド型工数・プロジェクト管理ツール「クラウドログ」のUI及びUXデザインを担当しております。
気がつけばクラウドワークスに入社して一年が過ぎていました…。
特に年末から今日までの日々が怒涛すぎて記憶がほぼありません笑
年末といえば…昨年末に弊社のアドベントカレンダーでこんな記事を書いたんでした。
この記事では以下の内容をお話ししました。
割れ窓理論とは何か
SaaSプロダクトにおける「割れ窓」の例
割れ窓リストの作成と運用方法
割れ窓リストを作ることのメリット
実際に運用してみての気づき
今回は前回の記事の続きとして、この半年間で得られた成果や気づき、そして今後の展望についてお話をしたいと思います。
上期の成果:チームの取り組みと数字で見る半年間
割れ窓解消プロジェクトでは、デザイナー3名とフロントエンドエンジニア2名が中心となって取り組みました。それぞれの専門性を活かしながら活動を進めてきました。
では、具体的な数字を見ていきます。
上期に発見された割れ窓事案:47件
解消できた事案:13件
結果としては、28%の解消率となりました。
割れ窓解消のプロジェクト自体は、まずは半期に渡り継続して行う基盤を作り、通常業務の合間に進めるサイクルにメンバーが慣れることを最優先事項としていました。
そのため結果としては少ない解消率に見えますが「まずは始めてみる。そして続けてみる。」というマインドがメンバーの中に芽生えたことは良いことと解釈しています。
これからは数を増やしていくことで、さらに成果を上げていきたいと考えています。
解消した割れ窓の中には、プロダクト全体のUIやUXに関わる大きなものから、特定のパーツに対する細やかな修正まで、様々なスケールの問題が含まれていました。 例えば…
コンポーネント同士のwidthの不一致があったので、widthを合わせるように修正(パーツレベルの修正)
![コンポーネント同士のwidthの不一致(パーツレベルの修正)](https://assets.st-note.com/img/1721717798798-HHy0rHErr1.png?width=1200)
AlertBoxとToastの使い分けルールの曖昧さがあったので、改めてルールを策定(プロダクト全体に関わる問題)
![AlertBoxとToastの使い分けルールの曖昧さ(プロダクト全体に関わる問題)](https://assets.st-note.com/img/1721717839416-Aw5hDyfV2m.png?width=1200)
このように、軽微なものからUI全体に関わる大きめの問題まで、様々な「割れ窓」と向き合ってきました。 一つひとつは小さな修正かもしれませんが、これらが積み重なることで、プロダクト全体の品質向上につながっていくと思っています。
振り返りと下期へ向けて:KPTで半年を総括
また、半年間の活動を振り返るため、プロジェクトメンバーでKPTを実施しました。その結果を簡単に共有します。
![割れ窓プロジェクトで行ったKPTの図](https://assets.st-note.com/img/1720442573712-Ow2cABjVtG.png?width=1200)
Keep:良かった・続けたいと思った点
エンジニアの効率的なタスク消化
チーム間連携による幅広い問題への対処
定期ミーティングによる問題の網羅的認識
割れ窓の仕組みが出来たことによるメンバーの意識変化
割れ窓課題の追加場所誕生
デザイナーだけでは難しい技術的な問題にも、お互いに知恵を出し合い、その都度最適解を見つけることができるようになってきました。
また、割れ窓の仕組みができたことで、メンバー全体にプロダクトUIの課題に対する意識が芽生えたこと、さらに、気軽に課題を追加できる場所ができたことは大きな成果だとメンバー全員が実感しています。
Problem:課題だと感じた点
大きな割れ窓が後回しになりがち
通常業務と割れ窓修正のバランスの難しさ
割れ窓が増えないための仕組みが必要
半期の間このプロジェクトに取り組んできて、まず割れ窓を意識するようになり、それによってプロダクト全体に大小様々な割れ窓が多く潜んでいることが明らかになってきました。
コツコツと直していくことは良いことですが、このままでは根本的なプロダクトの品質改善に至るまでには時間がかかるのではないか、という仮説が見えてきました。そのため「割れ窓を増やさない仕組み」を作る必要があると考え、Tryで具体的に何をしていくかを思案しました。
Try:下期からやっていくこと
予防的アプローチの強化
「割れ窓を増やさない仕組み」として、現在のクラウドログデザインシステムを改善していくことにしました。
クラウドログUIのベースとなるデザインシステム自体を改善することで、UIの崩れや根本的なUXの矛盾を防ぐことが期待されます。
チーム体制の拡充
これは単にリストに上がった割れ窓を解消するためにメンバーを増やすというわけではありません。
むしろ、プロダクトの品質向上をチーム全体の責任として捉え、メンバー一人ひとりが自分事として取り組む意識を醸成することが必要なためです。
メンバーの拡充により、品質に対する意識を組織全体に浸透させ、長期的かつ持続可能な改善の仕組みを構築していきます。
とはいえ普段の業務もあるため、リソースのバランスは取っていく必要がありますね。
最後に…
クラウドログの割れ窓プロジェクトは、まだまだ発展途上の施策です。
しかし、少しずつプロダクトの品質が向上している実感はありますし、今後も地道に、しかし確実に進めていきたいと思っています。
クラウドログのユーザーの皆様が、利用中にストレスを感じないプロダクト作りもこれからも続けていきます。
また半年後、noteで結果を報告したいと思っています!(いい成果が出ますように…。)
この記事が気に入ったらサポートをしてみませんか?