🚧

小規模WEBアプリのUIの運用に！UI WIPバッジのアイデア

2022/12/12に公開

デザイン

idea

はじめまして、みのじろーと申します！
LAPRASを含め複数のチームで、主にWEBアプリのUIデザインやフロントエンド開発のお仕事をしています。

LAPRAS Advent Calendar 2022の12日目の今回は、UI WIPバッジについて書きます！
UI WIPバッジは私が最近取り入れ始めた、デザインの運用に使うフロントエンドの自家製コンポーネントです。

一般的にお仕事でのフロントエンドの実装は、デザイナーがFigmaなどでデザインを作ってから行われます。
ただ実際には、デザインリソースの兼ね合いや期限などで、エンジニアそれぞれがGitHub上のissueの要件や簡単なワイヤーから、いきなり実装する場合も多いのではないでしょうか？
この場合はビジュアルリグレッションテストなどの仕組みで、リリースまでのどこかのタイミングで、最低限リリースに耐えるか否かをデザイナーが判断する必要があります。
もちろん開発段階からデザイナーによる細かい文言やマージン、モーションの微調整などを行うことは、プロダクトの体験をよくする上でとても大切ですが、MVP（顧客に価値を提供できる最小限のプロダクト）の開発としては上のフローで十分な場合も多いでしょう。

しかし、これを長く続けると、やがて機能ごとに見た目がバラバラだったり、整合性が失われた、とてもイマイチなUIが出来上がります。
デザイナーがいざ改善しようとしても、プロダクト全体のデザインの状態が把握しきれずに、どこから手をつけたものだか…という苦しみと戦うことになります。
この問題をちょびっとだけ解決するのが UI WIPバッジ です！

UI WIPバッジとは

このバッジは、プロダクト上に表示される、その部分のUIが開発中の状態であることを示すバッジです。
コード上に <UiWip comment="◯◯の施策で作りました。ABテスト中" /> などと入れておくと表示され、コメントも残せます。
見た目はこんな感じです。

本来こういったコメントはデザインデータ上に存在することが多いのですが、デザインデータが存在しない場合は、せめてコード上に残しておこうという取り組みです。
もちろんこのバッジは、本番では表示されないようにします。
ステージングでも普段はノイズになるので、URLに特定のクエリパラメータをつけた場合にだけ表示させるのが良いでしょう。
（フラグはなんでも良いけど、コードに親しみのないデザイナーも多いので、環境変数変えてpod再起動とかはイマイチかも）

Nuxt用のUI WIPバッジコンポーネントの実装例はこんな感じです。どのフロントエンドフレームワークでも似たような実装はできると思います。
?show-ui-wip=1 をURLにつけると表示されます。
propsは運用に合わせてお好みで… 項目は増やしすぎると運用コストが上がるのでおすすめしません🙅‍♂️

<script setup lang="ts">
const props = defineProps<{
  comment?: string
}>()
const route = useRoute()
const active = computed(() => !!route.params['show-ui-wip'])
</script>

<template>
  <div
    class="absolute p-3 bg-red-500 text-white rounded opacity-80"
    v-if="active"
  >
    <p class="font-bold">👷‍♂️ UI WIP 🚧</p>
    <p v-if="props.comment">{{ props.comment }}</p>
  </div>
</template>

なにが嬉しい？

UI WIPバッジの嬉しいところは、デザイナーがブラウザで確認したときにUIが未完の箇所を素早く発見でき、直したい箇所を優先づけしながら順番に直していけるところです。
例えばバッジに「ABテスト中」とコメントが残っていたら、「スペーシング直したいけど、機能ごとなくなるかもしれないなら、一旦別の作業をしよう」となるかもしれません。

また、エンジニアは「ビジュアルリグレッションテストで通してもらえたとはいえ、もっとUIの完成度^[1]が上げられたかもな」とモヤモヤしながらリリースせずに済みます。
バッジをつけることで、改善の余地があれば後からブラッシュアップしてもらえるから大丈夫！と安心できることでしょう。

運用の例

UIを実装する際は、カジュアルにUI WIPバッジを置いておく。余裕があればコメントも！
リリースは、プロダクトの最低ラインの品質を満たしていれば行う（この基準はプロダクトによるし、ビジュアルリグレッションテストでデザイナーが判断）
1スプリントに1時間などタイムボックスを決めて、その中でUI WIPバッジが付いた箇所を、デザイナーとフロントエンドエンジニアでペアプロして直していく。（できたらUI WIPバッジは剥がしていく）
UI WIPバッジをいくつ倒したか、コード全体でいくつ残ってるかがわかるようにすると楽しいかも。GitHub ActionsがPRにコメントで書いてくれても良さそうですね◎（UI改善にもゲーミフィケーションを！！）

最後に

私もまだ取り入れてから時間が経っていないアイデアなので、参考程度にどうぞです。
また、「うちはこうしてるよ！」「こんな方法もあるよ」など、コメントいただけると嬉しいです！
…

あとは、、え、えーっと…
メリークリスマス！！！！（？）🎅

脚注

ここであえてUIの完成度とふわっと言っているのは、UIの評価基準はチームによって異なるからです。ユーザビリティ観点で有効さ・効率・満足度から評価したり、UXピラミッドの項目（6段階のアレ…忘れてしまった）で評価したり、なにか独自の評価基準をもっていたりと様々でしょう。 ↩︎

UI WIPバッジとは

なにが嬉しい？

運用の例

最後に

Discussion