開発部のasakuraiuです。
現在はISP事業で主にPMやチームリーダーを担当しており、数年前までは「manaba」事業でPM、外部仕様を担当していました。 今回は「manaba」事業時代を思い出しながら、外部仕様、特に画面設計の観点からお話します。
画面設計は使う人目線で考えることが大事になりますが、実際ある程度動くものができないと見えてこない穴もあると思います。 これらの穴にどれだけ早く気付いて修正できるかはひとつの腕の見せ所にもなります。 私の場合、新機能開発中のマニュアル作成過程が、ユーザの疑似体験にもなり画面設計の穴に気づく大きなステップとして機能していました。 この記事ではそのステップをまとめてみました。
はじめに: manaba とは
manabaとは、当社が開発・販売・サポートしているWebサービスです。
主に国内の大学様に提供している教育支援サービスで、講義を受講したり課題を提出する学生、講義を実施したり課題を出題する教員、そしてそれらを管理・サポートする職員をつなぐ "学びの場" としてデザインされたサービスになります。ITリテラシーの高くない人も多い教員・職員でも利用しやすいよう、開発初期から一貫して「シンプル」・「かんたん」・「安心」をコンセプトに設計・開発しているのが特徴です。
manaba のマニュアル
manabaは上記のように学生・教員・職員によって利用の仕方が大きく異なるため、そのマニュアルも学生用・教員用・職員用と大きく3つに分けて用意しています。 そしてそのマニュアルは、利用ハードルを下げるためにも、利用目的別に、画面イメージをふんだんに用いながら説明しています。
このマニュアル作りの中で画面設計の妥当性も見えてくるので、画面設計後にマニュアルの草稿を作成することで妥当性を確認でき、後工程の手戻り量の軽減を図れます。
画面設計の output
「画面設計の output」と聞くと、どのようなものを想像するでしょうか。
たとえばIPAの公開している発注者ビューガイドラインの画面編では、
「工程成果物」として「画面一覧」、「画面遷移」、「画面レイアウト」、「共通ルール」、「入出力項目」、「アクション明細」の6種類が定義されています。
資料としてのまとめ方は人や場所によって違えど、output としてはこれらの要素が記載されたものを想像するのではないでしょうか。
これら output からは、画面群の構成や画面間の関係、目的、各画面のレイアウト、構成、入出力定義などが見て取れます。
ここでこれら output による画面設計の妥当性を見るのに、マニュアル草稿づくりが効果的です。 以下ではその流れをまとめていきます。
マニュアル草稿を作ってみる
殊に manaba の場合は、マニュアルは「やりたいこと」に対する「かんたんな手順」と、それに対応する「画面イメージ」という要素から構成しています。
今回「マニュアルを作る」というのはこの「かんたんな手順」と「画面イメージ」を揃えることとし、「完成品まで体裁含め仕上げきる」ことはスコープ外とします。
これによりいたずらに時間を使いすぎることを防ぎつつ、本物のマニュアルドキュメントを作るときにも活用することで無駄をなくします。
「かんたんな手順」を書いてみる
「かんたんな手順」とは
課題を提出する
- 課題一覧画面で、課題を選択します。
- 課題の内容を確認し、回答を入力します。
- 入力が終わったら [回答内容の確認] を押します。
- 内容を確認し、 [提出] を押します。
のように1アクションずつの短文で終わる箇条書きをイメージします。 感覚としては読点一つぐらいで済む文章量を列挙するイメージです。 これだけでも、
- 実際に操作する際に十分「かんたんな手順」に分解できるか
- 手順の途中に注意したいポイント・難しそうなポイントはないか
- それは画面設計を変更することで軽減・補助できないか
- 画面の分け方は適当か
などが見えやすくなります。
「画面イメージ」を用意してみる
「画面イメージ」とは、有り体に言えばモックアップ画面です。
画面設計段階のレイアウトでは、例えばExcel上に図形などを用いて各要素の配置イメージを出力したもの(ワイヤーフレーム)に留まります。
これに対しモックアップ画面とは、文字装飾・配色・画像やフォームの配置などが具体的に実装された、最終的なビジュアルデザインが確認できる画面です。
このモックアップ画面は、開発成果物を利用する顧客とイメージを揃えるのにとても重要な output として知られています。
ただそれ以前に、自分たち開発部門内でのセルフレビューにも大変有用です。
モックアップ画面を作るときに大事なのは、固定文字列の表示箇所はもちろん、可変長データの表示・入力箇所にも、実際のデータまたはもっともらしいデータを表示・入力することです。
間違っても hoge, fuga, あああ, ...などの無作為な文字列で埋めてはいけません。
このような文字列で埋めてしまうと、出来上がった画面から意図が読み取りづらくなってしまい、顧客とイメージを揃える際にも不利になりますし、マニュアルにも利用しづらくなります。また、デザイン上の思わぬ落とし穴が潜んでいたとき、それに気づく可能性も下がってしまいます。なので英文字ダミーテキストの代表例である lorem ipsum の利用も好ましくはありません。
またそのためにも、想定されるデータ群は一式揃っていることが望ましいです。顧客が一式を所持している場合は、いただけないか事前に交渉します。
立ち止まって見渡す・気づく
ここで一度立ち止まります。
そして初めてその画面にたどり着いたユーザの気持ちになって、困ることや違和感を覚えること(=気づき)がないか見渡してみます。
自分で言葉にできないようなふんわりした違和感も、例えば周りのメンバーに見てもらったりすることで言語化できるようになったりもします。
ここで出てくる気づきに、画面設計の穴が多く含まれてきます。
以下によくある気づきの例をいくつか紹介します。
固定文字列が長すぎる・読みづらい
想定していた固定文字列を実際に画面レイアウトに流し込んでみると、読むのに長過ぎたり文字色が目に優しくなかったりして視認性が下がるパターンです。
大事な部分だからと赤文字を連発したり、画面上のすべてを説明したいがために大量の文章を入れたり、よくやりがちだと思います。
この場合、目が滑りやすくなるだけなので、
- 文章量を絞る
- 文章の体裁を見直す
- 本当に赤文字・太字強調すべきか見直す
- 行間を広く取る
- 詳細説明をヘルプアイコン&バルーン表示に変更できないか検討する
など「いい塩梅」に調整していく必要があります。
データ表示・入力枠が狭すぎる・広すぎる
画面設計時には問題なさそうに思えたデータ表示・入力枠が、いざ顧客から受け取った想定データ群を入れてみたら全然足りなかったり逆に枠があまり過ぎたりするパターンです。
このときは画面レイアウトや表示方法、入力フォームを調整します。
ただ、すべての想定データで視認性の落ちないレイアウトを見つけることは困難な場合が多いので、データ群の分布を見ながら「殆どの場合は視認性が下がらない」範囲で決めてしまうことも重要です。
テーブルに列が多すぎる
画面設計時には必要だと考えて羅列した情報をいざテーブルに一覧表示してみると、1セル内に複数行表示され、極端に視認性が下がるパターンです。
これはそもそも列タイトルを表示した時点で画面に収まらない(流石に先に気づきたい)パターンや、実際にもっともらしいデータを表示してみると想定よりも文字列長が長いパターンがあります。
このような場合は、
- 表示する列の数を減らせないか
テーブルで一覧することに意義のある情報か- 実は次の画面で閲覧できれば事足りる情報ではないか
- 実は特定の列軸で検索・フィルタリングしたいだけではないか
- 実はテーブルを分けて表示したほうが良いデータ群ではないか
- 実は画面自体を分けて表示したほうが良いデータ群ではないか
- 固定長文字列の表現を短縮できないか
- 他の短い単語に変更できないか
- フォントサイズを小さくできないか
- アイコン表示にできないか
などを検討し、時にはセル内複数行表示や横スクロール表示を許容することも選択肢として再考します。 また上述の通り、データ群の分布を見ながら「殆どの場合は視認性が下がらない」範囲で判断するのも肝です。
画面がうるさい
一画面内に表示している情報量が多く、長年そのシステムを使い続けている人しか使えない(プロフェッショナル向け)画面になっているパターンです。1
たとえばトップページに様々な情報を集約しすぎてしまうことはありがちです。
この場合、初めてログインしたユーザはその情報量にげんなりして帰ってしまったり、
「いろんな情報が表示されているけれど、私のやりたいことはどうすればできるのだろう」と途方に暮れてしまったりとユーザ利用率の低下を招いてしまいます。
これは特に実利用がスタートしてから長い年月の経っているサービス・システムで起きやすいです。
年月が経ち開発側も顧客側もそのシステムのUIに慣れてくると、徐々に初心者ユーザのUXを想像しづらくなっていきます。そして長年の機能追加・改修を経た先に、気がづけば九龍城砦のような魔窟が出来上がってしまうのです。
これに気づいたときには、画面構成のリニューアル(果てには全体構成のリニューアル)を必要とする場合がほとんどです。
機能への導線が見つけづらい
個人的に、モックアップ画面と「かんたんな手順」とを見比べて違和感を覚えるのはこのパターンが多いです。
- 画面遷移直後、新規機能への導線が見つけづらい
- 画面遷移直後、新規機能への導線は見つけやすいが、逆に既存機能への導線が見つけづらくなった
といったパターンです。
これは上述の「画面がうるさい」と関連することもあります。
既に画面上にたくさんの機能があるところに新規機能を追加するとどんどん目が滑りやすくなりますし、
「新機能を目立たせたい」「でも既存の機能も目立たせたい」とあれもこれも目立たせようとすると、碌な画面になりません。
画面遷移数を減らそうとして一画面に情報を詰め込もうとする方もいらっしゃいますが、その結果、一画面内が情報量過多になるのもあまり望ましくありません。
このときは既存機能との優先順位やグルーピング、画面遷移直後に導線の見当がつくかを考慮しながら、画面の分け方・画面レイアウトを再考します。
まとめ
マニュアルを作ってみると自ずとモックアップ画面が必要になったり手順を整理したりすることになるので、
結果として画面設計の妥当性チェックに使えますよ、ということをよくある事例を挙げながら書いてきました。
また、この記事は既存システムへの機能追加・改修を想定したもののため、フルスクラッチ開発のようにモックアップ画面の作成自体に多大な時間がかかりやすいパターンでは通用しづらいかと思います。
その場合にも使える程よいチェック方法は今後の課題です。
採用情報
朝日ネットでは新卒採用・キャリア採用を行っております。
-
そもそものコンセプトがプロフェッショナル向けのサービスであるなら、そのままでも良いかもしれません ↩
