エンジニアがワイヤー作成時に考えていること

はじめに

最近、機能の仕様検討から入るようになり、
あわせてワイヤーフレームを書く機会が増えてきたので、
言語化の練習も兼ねて、意識していることをまとめてみたいと思います。
UI/UX デザイナーの方々にとっては当たり前のことかもしれませんが、
同じように要件定義や仕様検討から入るエンジニアにとって少しでも参考になれば幸いです。

意識していること

特に意識していることは以下の 3 点です。

1. ユーザーの「分からない」は発生しそうか
2. 学習コストは高くないか
3. 実現イメージがついているか

ユーザーの「分からない」は発生しそうか

ユーザーが感じる「分からない」には主に 3 種類があります。

1. 位置が分からない
2. 状態が分からない
3. 操作が分からない

車の例 🚘

種類	例
位置	カーナビを見て自分がどこにいるのか、どの方向に向いているのか
状態	今ドライブモードなのか、パーキングモードなのか
操作	何を操作すればエンジンが起動するのか、ハンドルを捻るとどうなるのか

WEB サービスやアプリでも同様の「分からない」が発生しています

WEB システムの場合

位置が分からない

• 自分がどのページにいるのかが分からない、
• フォーカスを見失って画面上のどこにいるのか分からない
  ↓
• ページに一貫性を持たせて、現在地がわかりやすいようにする

状態が分からない

• マナーモードなのか、ミュートになっているのかどうか分からない
  ↓
• 状態を指すのか、操作を指すのかを分ける

操作が分からない

• ボタンを押してみないとどうなるか分からない
• 普段の使い方と違う使い方になっている
  ↓
• サービス内で一貫性を持たせる
• 一般的なルールに従う

対応策については様々あるかと思いますが、
まず、上記に当てはまるような「分からない」がないかという点で見直すようにしています。

学習コストは高くないか

上記の「操作が分からない」と重複する部分もありますが、
学習コストが高いかどうかについては特に意識しています。

既存機能やページとの一貫性はあるか
既存のこのページと同じ操作だと直感的にイメージがつくかなど、
ユーザーが一度学んだ操作方法を繰り返し使えるようにすることで、
学習コストが下がるかと思います。

ユーザーがよく使う他システムとの乖離はないか
既存機能に同様の動きがない場合は、
ユーザーが日常的に使用するシステムと操作感に大きな違いがないかを確認しています。

馴染みがある Google 関連のプロダクトや日常的に使っているであろう LINE など、
機能によって最低でも 5 つのプロダクトを操作して考えるようにしています。

実現イメージがついているか

エンジニアが、仕様検討に入る価値の 1 つがここかなと。
ワイヤーを書きながら実装のイメージがつくことで工数の大幅なズレが起きづらい、
スケジュールの見通しが立てやすい、実装者の負荷の軽減にも繋がるのではと考えています。

主にフロントの動きについてですが、
この部分は〇〇のコンポーネントを使えそう、
〇〇のライブラリを使って実装すると簡単に実装できそう　などなど。
自分自身が実装する場合を考えながらワイヤーを書いています。

もちろん、私がイメージできたことより、もっと良い方法がある可能性はあるので
必須ではないことを前提にイメージできる部分は伝えるようにはしています。

終わりに

ワイヤーフレーム作成時に意識していることをまとめてみました。
書いてみると当たり前の部分も多いのかもと思いましたが、
改めて言語化することで自分の考えを整理できたのでよかったです。
同じように要件定義や仕様検討を行うエンジニアの皆さんにとって少しでも参考になれば幸いです。

参考

• 情報アーキテクチャ 第 4 版 ―見つけやすく理解しやすい情報設計
• UI デザイン必携 ユーザーインターフェースの設計と改善を成功させるために
• ノンデザイナーズ・デザインブック [第 4 版]