文章を書くとき、UIが邪魔をするとわかるのは、実際に書き始めたときだ。
ツールバーが多すぎる。ボタンのラベルが小さすぎる。フォントが読みにくい。保存しようとしたらどこか迷う——そういった「邪魔」は、書くことに集中させてくれないUIから生まれる。
Google Stitch でコンテンツ作成画面の設計を担当したとき、私はこの問いと向き合った。「書く人のためのUIとは何か」。ブログ記事投稿画面を設計したプロジェクトで、それは単なるレイアウトの問題ではなく、「書くことへの集中を守る設計」の問題だった。
結論から言うと——コンテンツ作成画面で最も重要なのは「書くエリアの広さ」と「操作の出現タイミング」だ。ツールバーやオプションは「必要になったとき」にだけ現れ、書いていないときは視界から消える——その設計がライティング体験の質を決める。
テキストエディタUIとは何か
テキストエディタUI(コンテンツ作成画面)とは、ユーザーが文章・記事・メモ・メールなどのコンテンツを作成・編集するためのUIのことです。ブログCMS・ノートアプリ・メールクライアント・プロジェクト管理ツールなど、多くのサービスで必要になります。
テキストエディタUIには主に2つのタイプがある:
- リッチテキストエディタ:太字・見出し・リスト・画像挿入など、書式設定が可能なエディタ。NotionやWordPressのブロックエディタが代表例
- マークダウンエディタ:マークダウン記法で書式を表現するエディタ。GitHubのIssue・Zennなどが代表例
どちらを選ぶかはターゲットユーザーのリテラシーと、必要な書式の複雑さによって決まる。
コンテンツ作成UIが難しい理由
コンテンツ作成画面の設計が難しい理由は、「機能の豊富さ」と「集中環境の確保」が相反するからだ。
機能(書式設定・画像挿入・リンク追加・テンプレートなど)を増やすほど、UIは複雑になり、書くことへの集中が妨げられる。かといって機能を削りすぎると、ユーザーが表現したいことを表現できなくなる。
このバランスをどう取るか——それがコンテンツ作成UIの設計の核心だ。
Stitch でコンテンツ作成画面を設計した体験
ブログ記事の投稿画面をStitchで設計することになった。ターゲットは「毎日記事を書くライター」と「週1〜2回投稿する一般ユーザー」が混在するメディアプラットフォームだ。
「Full-screen集中モード」を軸に設計する
最初にStitchに「ブログ記事投稿画面を作って」と投げると、上部に固定ツールバー・中央に本文エリア・右サイドに設定パネルという標準的な3カラムレイアウトが生成された。
機能は揃っている。でも書き始めようとしたとき、「あれ、これツールバー邪魔だな」と感じた。
設計を見直した。「書いているときはエディタ以外は消える」という方向性でプロンプトを書き直した。
「ブログ記事エディタ。デフォルト状態:タイトル入力欄(大きめフォント・プレースホルダー「タイトルを入力」)+本文エリア(最大幅680px・センタリング)だけを表示。ツールバーはテキスト選択時のみ選択箇所の上に浮かび上がるフローティング形式。右上に「公開設定」ボタン(小さめ)のみ固定。シンプル・集中できるライティング環境。」
生成されたUIは、Medium のエディタに近い「書くことに集中できる」画面になった。選択したテキストの上にだけツールバーが出るフローティング形式で、書いていないときは何も邪魔しない。
実際に使ってみてわかったのは、コンテンツ作成UIの本質は「書くこと以外のすべてを視界から遠ざける」設計にあるということだ。
「公開設定パネル」を書き終わるまで隠す
もうひとつの重要な設計判断は、カテゴリ・タグ・アイキャッチ画像・スラッグなどの「公開設定」をいつ表示するかだった。
書き始める前からサイドパネルに公開設定が見えていると、書くより先に「カテゴリ何にしよう」「タグは?」と迷いが生じる。
解決策として「書き終わって公開ボタンを押したときに、公開設定パネルがスライドインする」という設計にした。書くフローと設定フローを分離することで、ライティング中の集中が保たれる。
Stitch でこれを設計したプロンプト:「公開設定パネル(スライドイン形式)。本文エディタの右から滑り込む形式。内容:アイキャッチ画像アップロード・カテゴリ選択・タグ入力・スラッグ入力・公開日時設定・「下書き保存」「公開する」ボタン。エディタと同時に見えない独立したパネルとして設計。」
コンテンツ作成UIの設計パターン
フローティングツールバーとスティッキーツールバーの使い分け
- フローティングツールバー:テキスト選択時のみ表示される。Mediumスタイル。書くことへの集中を妨げない。書式設定の頻度が低いユーザーに向いている
- スティッキーツールバー:常に画面上部に固定される。WordPressスタイル。書式設定の頻度が高いユーザー・多機能エディタに向いている
ターゲットが「毎日ヘビーに使うライター」であればスティッキー型、「たまに書く一般ユーザー」であればフローティング型が適することが多い。
自動保存インジケーターのUI
コンテンツ作成画面で「保存し忘れ」に対する不安を取り除くために、自動保存インジケーターは重要な役割を担う。
「保存中…」→「保存しました(数秒前)」→「変更あり、保存待ち」の3状態をStitchで設計した。画面右上の目立たない位置に、12pxのグレーテキストで表示することで、書くことへの集中を妨げずに安心感を提供できる。
よくある失敗と対処法
- 失敗1:ツールバーのボタンが多すぎる——H1・H2・H3・H4・太字・斜体・下線・打ち消し線・引用・コードブロック・リスト・番号リスト・画像・動画・表・横線・リンク……これをすべてツールバーに並べると、どれを押せばいいかわからなくなります。よく使う10項目に絞り、残りは「その他」メニューに格納しましょう。
- 失敗2:エディタ幅が広すぎる——画面いっぱいに広がるエディタは、1行の文字数が多くなりすぎて読みにくくなります。本文エディタの最大幅は680〜720pxに制限し、長い行を読みやすくしましょう。
- 失敗3:書いている最中に「未保存」警告が突然出る——しばらく保存していないとポップアップで「保存されていません」という警告が出る設計は、集中を強制的に途切れさせます。自動保存を実装し、手動保存は補助的な手段として扱いましょう。
- 失敗4:モバイルでのソフトキーボードとの干渉——モバイルでソフトキーボードが表示されると、ツールバーが隠れたりレイアウトが崩れることがあります。モバイルではツールバーをキーボードの直上に固定表示する設計が有効です。
- 失敗5:下書きと公開済みの区別が不明確——エディタ画面を見たときに「これは下書きなのか、公開済みなのか」がわからないと、誤って公開してしまうリスクがあります。画面上部に現在のステータス(下書き / 公開済み / 予約投稿)を常に表示しましょう。
よくある質問(FAQ)
Q. Google Stitch でリッチテキストエディタのツールバーを設計するとき、どんなプロンプトが効果的ですか?
A. 「フローティングツールバー。テキスト選択時のみ表示。ボタン構成:太字・斜体・見出しドロップダウン(H1/H2/H3)・リンク挿入・引用の5項目。ツールバーの背景は白・角丸8px・シャドウ。」というプロンプトが効果的です。ボタン数を明示することで、適切な幅のツールバーが生成されます。
Q. 画像・動画のインライン挿入UIはStitchで設計できますか?
A. できます。「本文エリアにカーソルがあるとき、左端に「+」ボタンが表示される。クリックすると画像・動画・コードブロック・区切り線の挿入オプションがポップアップ表示される」というNotion風のブロック挿入UIをStitchで設計できます。「+ボタン表示状態」と「オプションポップアップ展開状態」の2つのUIをセットで生成しましょう。
Q. MarkdownエディタとリッチテキストエディタのUI設計の違いは何ですか?
A. マークダウンエディタのUIは「左:マークダウン入力エリア・右:プレビューエリア」の2カラム構成が一般的で、ツールバーを最小限にしたシンプルなデザインが求められます。リッチテキストエディタは「WYSIWYG(見たままが結果になる)」であるため、書式設定ツールバーが必要です。Stitch でそれぞれをプロンプトで明示すると、対応するUIが生成されます。
Q. 複数人で同時編集する共同編集UIはStitchで設計できますか?
A. 静的なUIとして設計できます。「他のユーザーが編集中の箇所にカーソルアイコン(アバター付き)が表示される」「編集者リストが右上に表示される(アバター複数)」「選択中のテキストが他ユーザーの色でハイライトされる」などの状態をStitchで設計できます。ただしリアルタイムの変化は実装で対応が必要です。
Q. コンテンツ作成画面のモバイル対応はどう設計すればいいですか?
A. モバイルのコンテンツ作成画面では、ソフトキーボード表示時のレイアウト変化を必ず設計します。ツールバーはキーボード直上に固定し、本文エリアはキーボードの高さ分を差し引いた残りのスペースを使う設計が一般的です。Stitch でプロンプトに「ソフトキーボード表示時の状態(ツールバーはキーボード上固定、本文エリアは縮小表示)」と指定して生成しましょう。
まとめ:書くためのUIは、書くことを邪魔しないことが使命だ
Google Stitch でコンテンツ作成画面を設計してみて、「書く人のためのUI」の本質に気づかされた。
書くことは集中力を要する行為だ。良いエディタUIは、ユーザーが書くことに完全に集中できるよう、機能を「必要なときだけ」存在させる設計を持っている。
フローティングツールバー・公開設定の分離・自動保存インジケーター——これらはすべて「書くことの邪魔をしない」という同じ原則から生まれた設計だ。
Stitch でこの設計を可視化しながら気づいたのは、優れたエディタUIには「何かを追加する」より「何かを取り除く」という発想が必要だということだ。シンプルになるほど、書く人は集中できる。
次のステップ:自分のサービスのコンテンツ作成画面を開き、「書いていない状態で何が見えるか」をカウントしてみましょう。不要なものが目に入っているなら、それを隠すかタイミングを遅らせる設計から始めてみましょう。