転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
設計と判断は自分で行い、実装も原則自分で書いています。AIには手順書・レビュー・調査を任せています。
転職用のポートフォリオとして作っているサービスの話です。
デザインの決め方というより、決めたあとで意味が後から追いついてきたという順序の話をします。
真似から始まった
自分のサイトは Bento Grid（大小のカードを敷き詰める様式）で作っていました。
理由は単純で、そういうサイトをいくつか見て、真似したくなったからです。
特別デザインにこだわりがあったわけではありません。思想があって選んだわけでもない。
アプリ化した瞬間に破綻した
手書きの HTML をアプリにして、カードをデータベースから出すようにした時点で壊れました。
Bento のレイアウトは grid-template-areas のエリア表で成立していて、
HTML 側で1枚ずつ「この枠に入る」と手で指定していました。
エリア表は枚数と並びが固定である前提なので、
「DB から可変枚数を出す」と両立しません。
移植をやめて、レイアウトを設計し直しました。
決めたことは全部「実装の制約」から出した
このとき決めたのは5つです。どれも見た目の趣味では決めていません。
| 決めたこと | 決めた理由 |
|---|---|
| 全カード同サイズ | エリア表が可変枚数と両立しない |
| サイズで重要度を表さない | サイズ差は作る側の都合だった |
| タップでその場展開 | 情報量の差をサイズではなく開閉で表す |
| 隙間を埋めない | 埋めると DOM 順と視覚順がズレてタブ移動が壊れる |
| 高さを指定しない | 固定すると中身が長いカードで溢れる |
名前を変えた（ここまでデザインの話はしていない）
別の理由で、プロダクト名を Hubpin に変えました。
旧名が長すぎたこと、英語圏で通じないダジャレだったこと、それに Hubpin なら
hub を留める pin という意味が単独で立つこと。レイアウトとは何の関係もありません。
その後、見た目の方向性を決める段になって「ピンボード風」という案が出ました。
名前から連想しただけの、後付けの思いつきです。
もともとそういう構想はなくて、名前から結びついた偶然でした。
並べたら、5つとも一致していた
| 制約から出した設計 | ピンボードで言うと |
|---|---|
| 全カード同サイズ | 留める紙は同じ大きさ |
| サイズで重要度を表さない | 大きい紙が重要という規則は無い |
| タップでその場展開 | 留めた紙を広げて読む |
| 隙間を埋めない | 刺した場所に留まる |
| 高さを指定しない | 紙の大きさは中身で決まる |
偶然ではないと思っています。
物理のピンボードは可変枚数を扱うための道具なので、
「枚数が決まっていないものを並べる」という制約を解くと、そこに寄る。
むしろ Bento のほうが、枚数と配置を作り手が固定できる前提の様式だった、
と今は思っています（これは自分の解釈です）。
だから「設計は1つも変えない」ことにした
コンセプトとして採用しましたが、実装は1行も変えていません。
変える必要が無かったことが、そのまま採用の理由です。
逆に言うと、設計を1つでも変える必要が出ていたら採用しませんでした。
比喩に合わせて実装を曲げ始めた時点で、それは制約ではなく装飾になります。
UI の言葉も標準的なまま（「追加」「削除」「並び替え」）にしました。
「ピンを刺す」に言い換えない。説明が要る比喩は弱いので、
見た目で伝わるなら言葉を変える理由がありません。
持ち帰り
- 順序が逆だと同じ結論でも価値が変わる。
「ピンボードにしたいからカードを同サイズにした」は趣味ですが、
「制約で同サイズになった結果ピンボードと一致した」は設計の説明になります
- 比喩は後から見つけるほうが強い。 先に決めると、実装を比喩に合わせて曲げ始める
- 真似から始めても、作り込む過程で理由が要求される。そこで初めて自分の判断になる
