デザインはメッセージです。親切にもできれば、無愛想にもできます。人懐こくもできれば、冷淡にもできます。何が正解かを考えるのがデザインの仕事ではありますが、その答えを知っているのはユーザーだけです。
ユーザーが熟練しているからといって、オペレーションを分析せずただ項目をレイアウトしただけではないか？
ユーザー自身と協議しながらだったとはいえ、見た目の話だけで「動き」のイメージを共有していないのではないか？
レビュー事例のサンプルサイト（少しずつ増やします）
https://yumeryu-github.github.io/index.html
「このデザインは本当に『ユーザーにやさしい』のか？」
微力ながら、疑問を持っている方のお手伝いができればと思います。
ドキュメントのフォーマットについても受け付けています。
==========
レビューの手段
A 静的リソース
GitHub経由で見せていただきます。
専用GitHubアカウント「yumeryu-github」
B WEBアプリ
公開済みならばURLを教えてください。アカウントが必要なサイトでは、有効なアカウントを用意してください。
開発中ならばDockerイメージを提供してください。
専用DockerHubアカウント「yumeryudocker」
C スマホアプリ
運用中のアプリに限り対応します。有料の場合は対策を用意してください。
D デスクトップアプリ
リモートアクセス等、妥当な手段を用意してください。
==========
レビュー結果
｛通番, 指摘内容, 摘要｝をセットとしたリストです。改善案はオプションです。対象が「動き」であっても動画は作成しません。
レビュー基準は私の独断です。枝葉末節を取り上げて無駄に件数を増やしたりはしません。指摘が無ければ成果物は発生しません。
提出方法はいずれかを選んでください。
・GitHubのIssue
・Excel（GitHub経由）
ユーザーがハッピーなら、プログラマーもハッピーなはず！ win-winより＜happy-happy＞
原則として、動きを見ます。どうしても形状だけのレビューになる場合は、私の固定観念がレビューの品質を落とす危険性が高いです。「お試し」だとしても、効果が期待できない投資は避けるのが賢明です。
特別な前提が必要な場合は、用語集・運用マニュアル等を添えてください。
例）
・専門用語を多用している
・ユースケースのアクターのスキルが高く想定されている
・特定のルールや機材の知識がドメインにおいて常識とされている
>>>重要事項<<<
原則として実施後のキャンセルはお断りします。
注文の準備に関する問合せには対応しません。
レビュー行為に付随するいかなるコストも当方では負担しません。ライセンス、アカウント発行、個人情報保護等、あらゆるコスト及びリスクは注文主の負担とします。
機密保持関連の書類には対応しません。今後の活動にまで影響する内容を含むことが多く、その詳細を確認するコストを取るつもりが無いためです。営利事業の一環として注文することはお勧めしません。
「回答＝正解」ではありません。回答の採用に伴うリスク及び生じた結果に対し、当方はいかなる責任も負いません。