記事

Webと体験

利用者が終えたい仕事を基準にWebアプリを選び、設計します。提供方式、検索、多言語、フォーム、日々の使いやすさをつなげて考えます。

ストアにアイコンを置きたいという希望ではなく、必ず成立させたい作業から配信方式を選びます。誰が、どの端末を、どんな通信環境で使うのでしょうか。見積をたまに開く顧客と地下で働く技術者では、同じスマートフォン向けでも条件が違います。

まず公開情報と非公開の作業を分けます。製品説明、公開一覧、記事は検索で見つけてもらう対象になり得ますが、顧客画面や個人記録にはアクセス制御が必要です。すべてをサーバーで描画しても、公開するURLや最初の応答内容は別途決めなければなりません。

多言語製品では、内容、言語、利用者の希望を安定して結び付ける必要があります。タイトルが変わっても残るコンテンツIDから始めます。URLの言葉が違っても翻訳記事は同じ記事です。この区別があれば、ナビゲーション、言語切替、検索用情報で同じページを示せます。

見積フォームは仕様書を書かせる場所ではなく、役に立つ返事に必要な背景を集める場所です。依頼が対応範囲に合うか、誰が確認するか、何を相談するかという次の判断から考えます。必須項目には、その判断を助ける理由が必要です。

業務画面の役割は、仕事に気づき、理解し、処理できるようにすることです。グラフを集める前に、その役割で繰り返し行う判断を定めます。配車担当には会社全体の集計より、優先順の作業列と例外表示が必要かもしれません。

役立つものを、一緒に。

最初のプロダクト、複雑な業務、見直したいソフトウェア。現在の状況をお聞かせください。