ロール別ガイド

PDM/デザイナーのための
toishi活用法

情報設計の入力を揃え、手戻りを減らす。
「何を作るか」を整理してから、画面を描く。

Pain: 手戻りが多い

画面を作り込んでから「そもそもこの機能いらなかった」と言われる。デザインの前に要件が固まっていないのが原因。

toishi ではユーザーニーズセクションで「誰が、何を、なぜ必要としているか」を先に定義します。承認者の合意を取ってから画面設計に進むので、根本的な手戻りが起きません。

ユーザーニーズ承認 → 画面遷移 → 画面詳細の順で進行。前工程の合意なしに次へ進めない仕組みです。

「こんな感じで」という曖昧な依頼から、いきなり画面構成を考えなければならない。何を根拠に情報を整理すればいいか分からない。

ペルソナ → ユーザーニーズ → 画面遷移 → 画面詳細。この流れに沿って埋めていくだけで、情報設計に必要なインプットが揃います。

前提→ペルソナ→ニーズ→画面遷移→画面詳細→...

「この画面、どれくらいかかる？」と聞かれても答えられない。エンジニアの見積もりが見えないまま、スケジュールだけ決まっていく。

エンジニアが入力した工数見積もり（最小〜最大の2点推定）を、同じ画面で確認できます。「この画面は3〜5日かかる」が分かれば、デザインの粒度や優先順位の判断材料になります。

商品詳細画面

3〜5人日

検索結果画面

2〜3人日

ユーザーがどの画面をどの順番で辿るか、ゼロから考えるのは時間がかかる。特に複数ペルソナがいると、ジャーニーの整理だけで1日使ってしまう。

ペルソナとユーザーニーズを入力済みなら、AIが画面遷移の叩き台を生成できます。ゼロから考える必要がなく、叩き台を編集する形で進められます。

AI への指示例

「ECサイトのペルソナとニーズから、画面遷移を提案して」

「なぜこの画面が必要なのか」を経営陣に説明するのが難しい。デザインの良し悪しではなく、ビジネス価値を求められる場面が増えている。

各ユーザーニーズの月間実行回数と工数から ROI を自動算出。「この機能は月5,000回使われ、ROI 625」と数字で語れます。経営陣への説明資料としてPDF出力も可能です。

コンサルタントやビジネスサイドのメンバーにとって、Figma の操作は敷居が高い。情報設計レベルの整理に、デザインツールの習熟は不要なはず。

フォームに入力し、リストを並べ替えるだけ。デザインツールの知識は不要です。情報設計レベル（何を作るか、誰のために、どんな順番で）までをサポートします。

toishi は「何を作るか」を整理するツールです。画面デザイン（ビジュアル、インタラクション）は Figma やパワーポイントに委譲します。

toishi がカバーする領域

Figma / パワポに委譲する領域

ペルソナ、ニーズ、画面遷移。
デザインの前に「何を作るか」を固める。