告白

納品前に、4日くらい遊んでしまう癖がある。(1人で請負う案件)

意味もなく画面遷移して、意味もなくボタンを押して、自分の作ったUIを眺めて、UXにニヤニヤする。デレデレする。

昔はこれを「悪い癖」だと思って隠していました。今は工程表に計上してる。

要件定義    ⬜️⬜️
設計           ⬜️⬜️
実装               ⬜️
デレデレ              ⬜️⬜️⬜️⬜️⬜️⬜️    ← ここ
デプロイ                ⬜️
納品調整                       ⬜️

ふざけてるように見えると思う。半分ふざけてる。でも残り半分は、かなり真面目な品質保証。

デレデレ中に何が起きてるか

自分の作ったモノで4日遊ぶと、必然的にこうなる。

一番ヘビーなユーザーが自分になる。 想定ユーザーの誰よりも先に、誰よりも長く使い込むことになる。
動作確認では踏まない操作を踏む。 テスト項目は「正しく使ったら正しく動くか」しか見えない。デレデレすることには目的がないから、変な順番でボタンを押す。戻るボタンを連打する。ありえない入力をする。つまり、本番のユーザーと同じ動きをする。
粗が「気になる」レベルで見つかる。 バグ未満の違和感——ここのアニメーションちょっと引っかかるな、この文言なんか冷たいな——は、義務で触ってたら流してしまう。惚れて触っていれば、気になって直してまう。

粗の磨き込み

具体例1: 見た目は変えず、Tab順だけ入れ替える

ポップアップの右下に [キャンセル] [決定] が並んでる。
見た目はこれで正しい。

でもキーボードでフォームを埋めて、最後にTabを押すと——次に当たるのはキャンセル。
そのとき作ったフォームは、大半の利用が決定に進むのに、一個余計に押さなければいけない。

Googleのサービスの一部のダイアログはここが賢くなっていて、フォームの直後にTabすると決定に当たることがある。だから真似した。

DOMの並びは決定 → キャンセルにして、見た目だけ flex の order で入れ替える。

<!-- Tab順(=DOM順)は 決定 が先。見た目だけ後で入れ替える -->
<div class="actions">
  <button type="submit" class="primary">決定</button>
  <button type="button" class="ghost">キャンセル</button>
</div>

css.actions { display: flex; justify-content: flex-end; gap: 8px; }
.actions .primary { order: 2; } /* Tabは先。見た目は右へ */
.actions .ghost   { order: 1; } /* Tabは後。見た目は左へ */

order は描画順しか変えない。Tab順はDOMのまま——ここがミソ。
見た目の [キャンセル] [決定] を保ったまま、キーボードだけ決定に直行させられる。

Tab順なんてマウス派は一生気づかない。
でも自分がキーボードで100回ポチポチ検証してると、この一手が効いてるのを感じる。

具体例2: 一瞬のローディングは、いっそ見せない

処理が速いと、スピナーが0.1秒くらいピカッと光って消える。
これが地味に不安になる。

「今の、一瞬なんか光ったな…ちゃんと成功したんか?」。
...バグではない。動いてる。でも触っていて気持ち悪い。

だから2段構えにした。
速く終わるならスピナーは出さない。出すと決めたら、逆に一瞬で消さない。

/**
 * スピナーを「速い処理では見せず、見せるなら一瞬で消さない」よう制御する。
 *
 * @param {object} options
 * @param {number} [options.delay=200]      これより速く終わればスピナーは出さない (ms)
 * @param {number} [options.minVisible=500] 一度出したら最低これだけ出す (ms)
 * @param {() => void} options.show
 * @param {() => void} options.hide
 * @returns {{ start: () => void, stop: () => void }}
 */
function createSpinnerGate({ delay = 200, minVisible = 500, show, hide }) {
  /** @type {ReturnType<typeof setTimeout> | null} */
  let showTimer = null;
  /** @type {number | null} */
  let shownAt = null;

  return {
    start() {
      showTimer = setTimeout(() => {
        shownAt = Date.now();
        show();
      }, delay);
    },
    stop() {
      if (showTimer) {
        clearTimeout(showTimer);
        showTimer = null;
      }
      if (shownAt === null) return; // まだ出してない = 一瞬で終わった。何も見せずに済む
      const rest = Math.max(0, minVisible - (Date.now() - shownAt));
      setTimeout(() => {
        hide();
        shownAt = null;
      }, rest);
    },
  };
}

delay: 200 が「0.2秒はスピナーしていないフリ」、
minVisible: 500 が「0.5秒かかったフリ」。

自分の指が覚えてる気持ちよさの閾値を、そのまま数字にしただけ。

⋮

ついでにボタン内スピナーは、ラベルを丸ごと置き換えると幅が変わってガタつくので、ラベルは動かさず頭に小さいスピナーを添えるだけにした。
位置がズレないから、ガタつきが消える。
(末尾にスリードットの「...」をアニメーションで見せるのもアリだと思う)

テストしてくれる人もユーザーでさえも「0.2秒のチラつきが気になります」なんて報告は上げてくれない。

デレデレしながら、4日触ってるからこそ、腹が立って直す。

具体例3: 追加した行を「ニューッ」と出す

一覧に項目を追加する。パッと現れる。機能的には完璧。

でも一瞬、「あれ、今追加したやつどれ?」と目が探す。でもたいてい、まず1ミリも困らない。
ただ、ほんの少しだけ気持ちよくない。

だから新規行を、高さ0からふわっと開くようにした。

/* height: auto はトランジションできないので、
   grid-template-rows の 0fr → 1fr で高さをアニメーションさせる */
.row-enter {
  display: grid;
  grid-template-rows: 0fr;
  transition: grid-template-rows 240ms ease;
}
.row-enter.is-in { grid-template-rows: 1fr; }
.row-enter > *   { overflow: hidden; } /* 潰れてる間はみ出さないように */

開き終わりに一瞬だけ背景をハイライトして、「これ」と視線を誘導する。

他にも

文言がいらつかないか、冷たい表現になっていないか
タップできそうなのにタップできないモノはないか、区別できているか
カードUIのカードの角丸のサイズ感
カードUIを展開した時のアニメーション、カードそれ自体の形の調整
文字の太字箇所は誤操作を招かないか
カラフルな色相的なバランス（機械的ではなく人間の目線で）
わざわざ確認される削除UX（頻繁に削除するのであれば操作取消ボタンで）
アニメーションの開きと閉じでの対称性（対称の方がたいてい気持ちよくない）
場合に寄ってはタップ操作をponterdown化
入力フォームの勝手な予測変換

など、ずっと触っていれば気になるところはどんどん出てきます。

要するにこれ、ドッグフーディング。ただし義務ではなく、いつも勝手にやっている。4日遊んでも飽きなかったら、そのUI/UXはたぶん大丈夫。さすがに1日目で嫌になれば、何かがおかしい。

自分の作ったモノに自分がデレデレできるかは、品質指標だと思ってる。

デレデレできないときは、危険信号

逆のパターンも書いておきます。

過去には、納品物が早く出来てもデレデレできなかったことがあります。

動く。要件も満たしてる。でも触っていて楽しくない。
自分の思う成果物に届いていないのが、触るたびに分かる。

そういうときは、だいたい設計のどこかで妥協してる。
デレデレは、その妥協を検知するセンサーでもある。

そのいうときには、設計から作り直したこともある。

まとめ

納品前に、目的なく自分の成果物で遊ぶ時間を工程に入れる
遊びは「正しい使い方」の外側を踏むから、テストの死角を潰す
自分がデレデレできるかどうかは、仕様書に書けないUI/UX, テストの品質指標
デレデレできないときは、どこかで妥協してる

次回以降の記事で、なぜ私が成果物で4日もデレデレできるのかを書く予定です。