面接で技術について聞かれること

例えば、一覧の画面で、行を横にスワイプして削除する操作をデザインしたところ、エンジニアから「キーボードや読み上げで使えないし、工数も大きい」と言われたケースです。目的は「不要なものをすばやく消せること」だったので、それを共有したうえで、案を並べて比べました。

結果、行の「…」メニューから削除できる形を基本にし、スワイプは次の版で追加する、と段階を分けました。誰でも使える手段を先に用意できたことと、工数を抑えて予定どおり出せたことが良かった点です。意見が分かれたときは、どちらの案が正しいかではなく、目的に対して何を優先するかで決めるようにしています。

例えば、検索の絞り込みで、選んだ条件に合わせて結果の件数をすぐに表示する案を最初に作りましたが、エンジニアと相談すると、件数を毎回数えるのはサーバーの負荷が大きいと分かりました。そこで、件数は「適用」を押したときに表示する形に変えました。

そのままでは「押すまで結果が分からない」という体験の弱さがあるので、0件になりそうな条件の組み合わせは先に注意を出す、といった工夫を足しました。実装の制約で変わった部分も、目的を保つためにどう補ったかまで説明できるよう、判断の記録を残しています。

コードを書けることより、制約を知ってデザインに反映できることが大事だと考えています。具体的には、画面の状態、画面幅と文字の拡大による伸び縮み、OS の作法、デザインシステムとコードの部品の対応、アクセシビリティ、表示の速さに効く素材の重さ、AI のような新しい技術の性質です。

これを知っていると、デザインの段階で抜けに気づけ、エンジニアとの相談も「どこが大変か」「この案なら手間はどうか」と具体的になります。HTML や CSS を少し触れる、開発者ツールで値を確かめられる、くらいまでできると、実装との違いを自分で調べられるので役に立っています。

まず要件を確かめます。誰がどんな場面で買うのか、アプリか Web か、座席を選ぶ形か、支払いの方法は何か、在庫の情報がどれくらいの速さで更新されるかです。そのうえで、「迷わず、確実に買えること」をいちばん大事な体験に置きます。

流れは、日時と枚数の選択、座席の選択、確認、支払い、完了です。状態としては、読み込み中、売り切れ、選んでいる間に他の人に取られた、支払いの失敗、通信が切れた、を考えます。購入は取り消せない操作なので楽観的に完了と見せず、処理中をはっきり示し、二重に押せないようにします。最初の版の範囲と、購入の完了率を指標にすることも決めます。