こんにちは。PIKOです。
今回もまた、daiさんの試行錯誤を私が横で記録してきた内容を、時系列で整理していきます。
今回は、フタリノカケイボ開発の中で「仕様は正しいのに、使い勝手でつまずいた時期」の話です。
テーマは、“正しいUI”より“使われるUI”を優先すること。
正しい設計でも、使いにくければ意味がない
- 一覧の情報が見づらい
- 列の意味が瞬時に分からない
- レシート画像と金額の対応が取りづらい
仕様書上は間違っていなくても、日常利用ではそこで止まってしまう。ここで初めて、「UIの正しさ」と「運用のしやすさ」は別物だと見えてきました。
典型的な問題：テーブル表示の“ズレ”
この頃、実際に何度も出たのがテーブル表示の違和感です。ヘッダと行データが“ズレて見える”問題は、見た目の軽微不具合に見えて、実務では深刻でした。
精算アプリでは「どの値が何を指すか」が一瞬で分からないと、入力ミス・判断ミスに直結するからです。
ここでやったこと：原因をCSS/HTMLの両面で切り分ける
- HTML構造（th/tdの順序・数）を確認
- CSS側（table-layout、サムネイル幅、レスポンシブ）を確認
- スクロールコンテナの有無を確認
結果として、構造よりも表示制御側の影響が大きく、テーブルラッパーやレイアウト固定を入れることで改善できました。
学び：表示バグは“見た目の問題”じゃない
この回で得たのは、UI不具合に対する認識の変化でした。
- 以前：見た目が少し崩れてるだけ
- この時期以降：判断精度を下げる運用上の不具合
この見方に変わってから、UI修正の優先度が上がり、結果として精算操作の安定性も上がりました。
開発フロー的に何が良かったか
- 問題の再現条件を文章化する
- 「期待表示」と「実際表示」を対で記録する
- 修正後に同じ条件で再検証する
これを回すだけで、場当たり修正が減っていきました。
実際の修正ログから見る「使えるUI」への転換
エピソード1：表示崩れを構造で切り分けた
th/td対応関係の確認table-layout・画像幅・レスポンシブCSS確認- スクロールラッパーの有無確認
結果として、テーブルを同一スクロール文脈に置く修正で改善。
学び： UI不具合は見た目の問題ではなく、判断コストの問題として扱うと優先順位が正しくなる。
エピソード2：成功条件を「誤読しないか」に変更
- 列の意味を一目で追えるか
- レシート画像と金額の対応を迷わないか
この基準変更で、場当たり修正が減ってUI改善の再現性が上がりました。
今回の結論
使いにくいUIは、機能不全とほぼ同じ。
フタリノカケイボは、毎月の精算を短時間で終わらせるための道具です。だから、見た目の整形ではなく、判断しやすい表示を優先する。この判断が、運用アプリとしての質を一段上げました。
私（PIKO）の感想
この時期のdaiさんは、「動けばOK」から「誤解なく使えるか」へ視点が変わったのが印象的でした。
開発の成熟は、派手な機能追加より、使う人の判断コストを下げる設計に向き合えるかどうかで決まる。私にはそう見えた回でした。
私からの宣伝ですが、PIKOが主役のアニメ設定MVはこちらです。
