初リリースで学んだkintoneのデザインフローと考え方〜チェックボックスのデザイン改善〜
はじめに
こんにちは。サイボウズ新卒デザイナーのKayaです。入社後約3ヶ月の研修を経て、7月中旬頃からkintone Design Team（kDT）で活動しています。
正式配属前にkDTで2週間チーム体験をしたのですが、そこで課題として取り組んだ【チェックボックスのデザイン改善】が、デザイナーになってからの初リリース🎉となりました。改善した内容は、kintoneのアップデート情報ページにも掲載されました。
範囲の狭い改善に見えるかもしれませんが、想像以上に悩みながら取り組んだやりごたえのあるデザイン改善でした。また、入社後まもないタイミングで「事業会社のデザイナーが普段どんなことを考えてデザインをしているのか」を学ぶとても良い機会になりました。
kintoneのデザイナーとして何を考えて・どんなプロセスでデザインするのかを少しでもイメージしてもらえたら嬉しいです！
どんな改善をしたのか
kintoneは、業務に合わせたシステムやアプリをノーコードで作れるクラウドサービスです。
アプリを作るとき、用途に合わせてアクセス権や条件通知などを詳細に設定できるのですが、チェックボックスはその「アプリ設定画面」にたくさん登場します。
アプリ設定内の一部の画面では、アプリの関係者が多いほどチェックボックスがたくさん並び、それに伴って操作箇所も設定状況を確認する範囲も多くなります。また、アクセス権の設定ともなると情報セキュリティに関わるので、慎重に&正確に設定を行う必要があります。
そのため、チェックボックスの状態（チェックされているのかされていないのか、有効なのか無効なのか）をぱっと見で正しく判別できること、つまり”視認性の向上”が、今回の改善の重要課題でした。
改善のBefore&Afterは、以下の通りです。チェック状態のボックスを塗りつぶしに変更し、また、checkedとchecked disabled、uncheckedとunchecked disabledのボックスに差分を作ることで、見分けやすくなりました。
下のように実際の画面で並んだものを見比べてみると、チェックボックスの状態がぱっと見で判別しやすくなり、設定状況も把握しやすくなったことが分かるかと思います。
デザイン改善のフローと考え方
「何を改善するか」を定める
まず取り組んだのは、改善箇所の洗い出しです。チェックボックスが使われている画面をすべて確認しながら、気になるポイントを挙げていきました。
気になるポイントはいくつかありましたが、その中で今回の「チェックボックスの状態が判別しにくい」という課題に改善対象を絞ったのは、「改善コスト」と「ユーザーへの提供価値」を考えて改善の優先順位づけをする必要があると知ったからです。kintoneはスクラム開発を行っていて、リリースする単位と一つのバックログに見合うコストと価値を考えてデザインを提案することが必要になります。
「改善コスト」について、例えば、他の部分との整合性にも影響するようなデザイン変更はそれをカバーする新たなコストを生みますし、実装の構造自体に手を入れなければならないようなデザイン改善は、エンジニアの実装コストがかさみます。kDTには「デザインテクノロジスト」職能のメンバーがいて、実装面を考慮したデザインについて相談に乗ってもらえます✨。
「ユーザーへの提供価値」は、問題の深刻度とか、解決することによる効果の大きさとも言えると思います。ちょっとしたズレなど細かい部分はもちろん気になるしこだわりたいですが、今回の改善対象は設定状況が判別しやすくなる・ミスしにくくなるという面でユーザーへの提供価値がより高い改善でした。
デザイン案を作る云々の前に「何を・どのくらいの分量で改善するのか」「何を目的とする改善なのか」を定めるプロセスを踏むということは、とても重要な学びだったと思います。
案の発散
改善対象が決まってからは、思いつく限りデザイン案を発散させていきました。
他社のデザインシステムもリサーチして案の参考にしましたが、製品によってコンポーネントが使われる場所や状況も違うので、kintoneのデザインとしての最適解を見つける必要があります。
そのため、例えばkintone内でチェックボックスが使われうる画面すべてでアクセシビリティガイドライン（WCAG）が定めるコントラスト比を満たしているか確認しながら、カラーパレットから配色を考えていきました。
他にも、kintoneはユーザー自身で様々なプラグインやカスタマイズを適用できる拡張性のあるサービスなので、それらを踏まえてもデザインが成り立つかどうかを考えなければいけないケースもあります。このようなとき、深い製品理解がデザインをする土台として重要になります。
案を絞る
たくさん出したデザイン案の中から最終案を絞っていくのも、中々に頭を悩ませました。
そんなとき教えてもらったのは、それぞれの案でメリットとデメリットを言語化すること。感覚的に案同士を見比べていても判断できないので、半ば粗探しをするような意識で一つ一つの案を検討してみると、徐々に絞り込むことができ、最終的な判断を下すことができました。
チームでのデザイン
今回、kDTのメンバーにレビューをもらいながらデザイン作業をするという「チームでのデザイン」も体験できました。製品理解が深い人、実装やアクセシビリティに詳しい人、他社での経験が豊富な人、いろんなメンバーにいろんな角度からのフィードバックをもらってブラッシュアップしていくことで、最終的な決定にも自信を持つことができました。
この、チームでレビューし合ってデザインを作っていく流れは、私が新人デザイナーだからというのに限りません。普段からkDT内で活発に行われていて、先輩のデザインプロセスや考え方を知れるという意味でも、とても勉強になっています。
まとめ
2週間のチーム体験中に行った「チェックボックスのデザイン改善」でしたが、とても学びが多く、一つのコンポーネントに徹底的に向き合う大変さ・楽しさも実感することができました！
kintoneのデザインが全て今回書いた内容に沿う訳ではなく、それ以上にステークホルダーが増えたりプロセスが複雑だったりします。ただ、この経験を通して学んだことは正式配属後のデザイン業務にも活きていますし、これからも意識したいと思っています。
最後までありがとうございました！
この記事が気に入ったらサポートをしてみませんか？