設計手順というわけでのはないですが、
利用してもらうのに簡単な説明が必要となる場合が多いので、
・開発予定のアプリのイメージ図を作成しますね。
・あとはアプリを一つずつ作り、ルックアップや関連レコード等でアプリ間をつないでゆきます。
①まずはマスタ関連から制作します。データも含めてアップ
②入力のメインとなるアプリ（※だいたいが既存の紙フォーマットであったり、Excelフォームで
　　あったりすることが多い）を制作
③アプリと各マスタ関連を繋いでゆきます。
④アプリごとに、アプリの説明、操作方法、注意事項等を入力して、初めて利用される方が
　わかるようにコメントを入れておきます。

イメージ図にはあとで書き足し、各アプリに説明、操作方法、注意事項等記入した内容をコピペ。
※弊社の場合はドキュメント化するツールがあるので自動生成しています。

アプリは作成して終わりではないことが多く、修正依頼・問合せとうとうを受け入れる
アプリも準備して、アプリ改善を繰り返しますね。

一つイメージ図があれば、それからの機能追加・他システムとの連携とうとう
考えやすいですね。
　

作る方もいらっしゃいますし、出来てから仕様書のようなものを作られる方もいらっしゃいますね。
私は大体作るとき時間がないのと、すぐ欲しいので、とりあえず作らずに、後から必要に応じて作るという感じにしています。

会社の決まり事は各々で結構ルールが違い、あまり参考にならないと思うので、1234さんが在籍する組織のルールに合わせて作られるのが良いかなと思います。
（閲覧権限とかね。）
不安であれば、テストスペースを作って、そこでアプリを作成→問題なければ一般リリース、というのも手です。（スペース内に作ればそのスペースに参加している人だけがそのアプリを触れますし、一般公開時も該当部署のスペースに移すとか、ポータル全体にリリースするということも可能です。）

自分なりのルール、で言うと「あまりこだわらないこと」ですかね。
作り込み過ぎると変に愛着が湧いて、いざリリースした時、修正依頼が多いとマジで心が折れるので、
一旦必要事項をまとめて作る → 自分でテスト入力して使い勝手が悪い部分や足りない部分を足す（引く）→ リリースする時は「追加して欲しい部分などあれば言ってください！」などアナウンスをする
という風にしています。

「未完成な部分もある」ということを周知すれば、興味をもって「こここうして欲しいんだけどできる？」というユーザー側のリクエストも増やすことが出来ますよ～。