ここ数年、マインナンバーカードやe-Taxなどの利用者拡大に加え、新型コロナによる在宅勤務や外出自粛による、ネットサービスの利用が急増したせいなのか、公共サービスのWEBサイト、アプリの不具合や使いにくさが話題になる事が多くなった。これを書いている間にも、コロナ・ワクチン接種の申し込みWEBサイトの使いにくさが、話題になっている。
最近、私の所にも公共サービスのUI/UX改善依頼や、公共サービスを多く制作している大手企業からのアプリのUI/UX制作の依頼が増えてきた。それらの中で、普段多く請けている中小IT企業からの依頼と制作の方針や工程が大きく異なる事が分かってきた。一言で言えば、これらの公共サービスを手掛けている大手開発企業には「デザイン工程がない、もしくはデザインを軽視している傾向がある」だった。だから使いにくくて、分かりにくいWEBサイトやアプリが出来上がってしまうのだ。
広告系とサービス系におけるデザインの扱い
一般にブラウザーで見るようなWEBサイトには大きく分けて、コーポレートサイト、LP（ランディング・ページ）、キャンペーンサイトなどの広告系と、EC、銀行の取引、マイナンバーカードやe-Taxなどのサービス系がある。そしてこれらのサービス系には、タブレットやスマートフォン専用のネイティブ・アプリがある。
広告系制作会社は、元々紙媒体の広告を制作していた会社が多く、デザインがメインであるため、これらのWEBサイトの制作会社には、デザイナー（HTML、CSSのコーディングができる）が多く在籍し、プログラマーの割合は少ないか、常駐していないのが普通。集客、マーケティングやSEOを考慮してWEBサイトを制作するのも広告系の特徴である。
これに対しサービス系は広告系とは逆で、元々コンピューターのシステム開発をメインにしている会社が多く、在籍しているのはプログラマーがほとんどで、デザイナーがいない場合が多く、在籍していても極端に少ない。昔は業務用のソフト開発がメインで、美的な意味でのデザインも、機能性という意味でのデザインも、ほとんど重んじられなかったという側面がある。
以上の経緯から、広告系のWEBサイト制作においては、デザインの必要性・有用性は、発注者と制作者双方において十分に周知されている。しかしサービス系、特に大手が作るWEBやネイティブアプリにおいては、ノンデザイナーのプログラマーが適当に作るなど、デザインが大変軽視されている傾向がある。
これが昨今の公共系サービス・サイトにおける、使いにくさや分かりにくさにつながっている。
サービス系デザイン制作工程の違い
私が多く関わるような中小のIT企業が、例えばECサイトを作るとする。これもサービス系である。
その場合、大まかな流れは以下のようになる。
- 企画
- ワイヤーフレーム制作
- モックアップ制作
- デザイン・カンプ制作
- フロント部分のコーディング（HTML、CSS、JavaScript）
- （必要であればプロトタイプ制作）
- プログラムの組み込み
- 検証
- 完成・リリース
この中で、モックアップやプロトタイプの制作を省略する事もあるが、近年FigmaやXDのプロトタイプ・ツールの発展により、これらが簡単に作る事ができるようになり、また以降の工程精度を上げるためにも制作する事が多くなっている。
これを見て分かるのは、デザイナーが関わる工程が多いことである。
これに対し、大手開発会社に多い流れは以下のようになる。
- 企画
- 要件定義
- 画面設計図制作
- デザインとフロント部分のコーディング（同時制作）
- プログラムの組み込み
- 検証
- 完成・リリース
「要件定義」「画面遷移図」などの言葉の定義は、デザイン会社と開発会社との間で違いはあるが、この場合は、デザイナーが関わる工程が少ない、または全くない。
サービス系サイトやアプリの問題点
サービス系サイトやアプリを制作する大手開発会社では、ワイヤーフレームやサイトマップを作る事は少ない。画面設計図は作るのだが、これはラフなワイヤーフレームの様なものであり、単一の画面内に必要な要素を置いてあるだけであり、完成後のレイアウトとは別なものである。
要件定義（書）もサイトマップに近いのだが、単にプログラムの流れを追ったものであるため、俯瞰で見る事が出来ず、一連の流れを見ることが困難だ。
その結果「ユーザーの操作に不都合は生じないのか」「このページは必要なのか」といった、いわゆるUXなど考えるすきがない。
またUIパーツに関しても「別ページだが同じ機能のボタン」の規格に統一感がなく、バラバラになる事も多い。全体を見ていないからである。
そして「4.デザインとフロント部分のコーディング」は、プログラマーが作業をする。細かいCSSでの調整が不得意なプログラマーは、CSSフレームワークとしてBootstrapで済ませる。しかし発注者やユーザーのフィードバックを吸収しようとすると、CSSをカスタマイズしなければならず、ここでまたCSSやHTMLの不都合が生じ、ユーザーにとって使いにくいサービスとなる。
「5.プログラムの組み込み」が終わってから、デザインを修正するためCSSの大きな修正をする事も普通にある。通常HTMLソースにプログラムが組み込まれた状態で、後からCSSだけでデザインを調整するのには限界がある。特に現在一般的なレスポンシブデザインにおいては。
デザインを修正する場合、まず既存セレクタのプロパティやその値を追加・修正し上書きする。それで無理ならHTMLソースに新たなセレクタを追加して、CSSを調整する。しかしプログラマーが組んだHTMLには、HTML自体を改変しないと実現できないデザインが発生する確率が非常に高い。そしてプログラムが組み込まれたHTMLを改変すると、プログラムが動かなくなる可能性もあるので、デザイン修正が困難になる。
これからのサービス系デザイン
工程は多くなり、納期も長くなるので避けている大手開発会社も多いと思うが、これからは中小の開発会社のように、ワイヤーフレーム制作、デザインカンプ制作、サイトマップ制作、モックアップ制作の工程は省くべきではない。
そして、美的な意味でも、機能的な意味でも（私のような）専門のデザイナーを使い、プログラマーはプログラミングに集中させる。「そんな事もうやっているよ」という会社も多いだろうが、大手になるとデザイン抜きの会社が、まだ多いのも事実。何せ大手でも「サイトマップって何？」「ワイヤーフレームって何？」という会社が実際に存在するのだから。
そうする事で結果サービスの向上が期待され、検証などの後工程も軽減される。
専門のデザイナーが求められる時代
この分野では、軽視されているデザイナーだが、今後は確実に必要性が高まるだろう。まだまだ需要自体が少ないので、報酬もプログラマーに比べたら半分以下である。公共サービスも公共サービスだから、コストを下げるため無愛想で使い勝手の悪いサービスで十分という考えは、薄くなってきている。「使いにくい」「分かりにくい」というような、ユーザーのフィードバックを無視することが出来なくなってきているからだ。広告系のWEBサイト制作者は、参入障壁が低いせいもあり、既に飽和状態である。仕事を得るには、SEOやマーケティングなどの付加価値を付けないと厳しい時代だ。今後は、サービス系のWEBサービスやアプリの制作の分野に移行するのも良いかもしれない。
