エラーメッセージはフォームのどこに表示するべきか
UX Movementの著者および設立者です。ユーザー体験のデザインスキルの開発を手助けしてよりユーザーフレンドリーな世界のために、このブログを創設しました。 フォームのどこにエラーメッセージを配置していますか？ ユーザーの期待する場所にエラーメッセージが置かれていないと、ユーザーはフォーム入力を完了できなくなってしまうかもしれません。 フォーム入力を間違えたら、ユーザーはそれを修正して送信し直すために、なにが間違っていたのかを理解する必要があります。フォームを完了しようと思っていたとしても、それがあまりにも大変であればユーザーは心変わりしてしまうでしょう。 フォームの上か、フィールドのインラインか エラーメッセージの配置場所でもっとも一般的なのは、「フォームの上」と、「エラーのあるフィールドのインライン」という２箇所です。どちらの配置場所が、ユーザーにとってより直感的でしょうか？ 調査に
プロトタイプは画面や機能ごとに作ってはいけない
※ユーザー調査法は下記のように、大きく2つに分類される。両者の違いは、次回説明する。 ニーズ探索型:ユーザー調査、行動調査、フォーカスグループインタビュー 仮説評価型：ユーザーテスト、ABテスト、アンケート プロトタイプ 今回は、この中からプロトタイプを取り上げる。プロトタイプとは、一般的には「評価、改良を目的にプロダクトの模型を作ること」である。この連載での改良の対象は当然、プロダクトのUI（ユーザーインタフェース）やUX（ユーザーエクスペリエンス）が中心ではあるが、技術仮説の模型もプロトタイプと呼ばれる。 画面やインタラクションを丸ごとプロトタイピングしない UI開発にプロトタイピングが有効であることはよく知られているためか、下記のようなゆるっとした進め方により、結果プロトタイプ開発に工数をかけ過ぎてしまうことがある。 目的を定めずに、漫然と「決めた仕様に基づく使い勝手を確かめるため」
サーバサイドエンジニアが考える、エラー発生時のより良いUX
誰のためのエラーメッセージなのか意識する 私はサーバサイドエンジニアとして API を提供する立場なので、サーバ起因のエラーが起きたときに適切な情報を伝えるために何ができるかを考えてみます。 サーバサイドの視点では、クライアント（顧客）は２者存在すると考えることができます。 ひとつは、もちろんアプリケーションを実際に利用するエンドユーザ。 もうひとつは、サーバサイドが提供する API を利用するクライアントサイドエンジニア。 同じ事象でも対象によって伝えるべきエラーメッセージは変わってきます。 たとえば、エンドユーザにデータベースのエラーコードをそのまま伝えても不親切です。逆にクライアントサイドエンジニアに「不正なリクエストです」としか伝えなかった場合、何がどう不正なのか分からず、原因を切り分けるためにより詳しい情報を知りたいと思うでしょう。 つまり、それぞれの立場にたって「何の情報を伝え
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
