1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

設計こばなしAdvent Calendar 2023

Day 20

画面設計書ってどんな要素が必要だろう(nuxt)

Last updated at Posted at 2023-12-03

はじめに

前回「ため息が出るDB設計書」について触れてきましたが今度は画面です。
https://qiita.com/jun2/items/f4be237fed04c88dc1f5
皆さんは画面設計書は作っていますか?

なんとなく画面が貼ってあるだけの設計書や表示する項目の説明をこれでもか!と記載した設計書がありますが、何をどこまで書くとよいのでしょう。
正解はないのかもしれませんが、こういった観点ではどうでしょう?という提案です。

書いた方がいいと思うもの

  • テストするときに確認が必要な項目(以下例)
    • 検索はorで検索される。
    • 更新が重複した場合はリロードする
  • バリデーションされる種類・内容
  • ユーザー操作により考えられるエラーパターン
  • (VueやReactのようなものの場合) 利用しているコンポーネント
  • 更新が重複しうる場合など
  • 設計意図とそのエビデンス

全部詳細を書きたいことですが今回は最後をピックアップしたいです。
なんでこうなってるの?誰がこの動きを決めたの?客先からの指示など後から引き継がれたものは思いがちです。

頭の中にだけ入っているこのようなノウハウこそ設計書に記載されていると、意味のある設計書になると思います。

よって、設計意図とそのエビデンスというのは特にも重要と考えます。

別に書かなくてもいいと思うもの

  • ある程度常識として捉えてほしいこと
  • 通貨項目は右揃えである、カンマ区切りである
  • 認証失敗時には認証エラーを表示する
  • 登録ボタンを押したら登録を行う
  • 特に表など表示項目のただの列挙 (ただし意味の説明が必要なものはあった方がよい)
  • 「XXメニューというボタンを押下するとXXメニューに遷移する」

見てわかるものは書かなくてもいいよねということです。

何の媒体で作成するとよいか

個人的にはマークダウンなりテキストでの記載が良いと思います。
理由としてはテキストは変更点の追従がしやすいからです。
Officeでも変更点の追跡は可能ですが、個人的にはGit + マークダウンでの記載を行うことでいつからこうなったんだろう?などの追跡がやりやすいと感じております。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?