エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
「情報アーキテクチャ」記事の一覧 | ラプラス取説研究所 > 情報大工のひとりごと
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
「情報アーキテクチャ」記事の一覧 | ラプラス取説研究所 > 情報大工のひとりごと
例えばAという機能の説明を作成する必要があるとしましょう。そのためにまず必要なのは、形として表れて... 例えばAという機能の説明を作成する必要があるとしましょう。そのためにまず必要なのは、形として表れてくるUIの外部仕様を知ることではなく、機能全体を理解すること、そして機能訴求ポイントや訴求方針を押さえることです。そういった面を全部想像してライティングするよりも、当該設計/実装に至った経緯を記した検討資料や各種仕様書(いわゆる「ドキュメント」)を入手して、エンドユーザー向けにコンテクスト変換した上でブラッシュアップ、必要に合わせて不足情報の追加というフローで作業した方が、正確で重要なポイントを押さえた成果物につながるわけです。それも効率良く。 なのですが、どうもこのドキュメントを要求する行為を甘えと取る人がそれなりにいるようで、なんだかなあという感じです。資料開示すればすぐに問題が解決するにも関わらず、どうして開示を嫌がって原稿作成工程に無用の負荷を掛けたがるのか、理由がまったく謎です。新規