業務システムのUIデザインの課題に対してがんばってみた

自己紹介

SI企業で業務システムの開発をしているSE/PGです。
最近はwebアプリの業務システムを開発しています。
業務を通じて、もっと業務システムのUIデザインをよりよくすることはできないのか？と思うようになりました。

今回取り扱う内容

内容
- Windows FormアプリとwebアプリのUIデザインの比較と気づき
- Qiitaで言うポエム記事

今までのUIデザイン

私が入社して最初に携わったプロジェクトがwebアプリの業務システムでした。
UIデザインが完成し、PG開発に入るところからメンバーになりました。

そのwebアプリのUIデザインは、今までのWindows FormアプリのUIデザインをそのままwebアプリにしたというようなデザインでした。

課題は？

現在見えている課題は以下の点です。

- FormアプリのUIデザインを引きずりすぎ
- HTMLのコーディングが不慣れ

FormアプリのUIデザインを引きずりすぎ

今まで開発してきたFormアプリは画面スクロールがありませんでした。
そのため、グリッドビューを配置し、その中でデータがスクロールして全件閲覧するという形でした。

しかし、webアプリには画面スクロールがあります。
Formアプリと同じようにASP.NETでグリッドビューを配置するとどうなるか？
グリッドビュー内のデータがスクロールせず、画面全体がスクロールします。

たとえば、デメリットを１点あげます。
Formアプリのグリッドビューとwebアプリのグリッドビューを比較してみましょう。

前述のとおり、Formアプリではグリッドビュー内でデータがスクロールされます。
一方webアプリでは、画面全体でスクロールされます。
この動きでデメリットが発生します。

Formアプリでは常にグリッドビューのヘッダーが表示されているため、どの列がなにの列かがわかります。
一方webアプリではグリッドビューのヘッダーが画面スクロールによって画面表示外になってしまうため、どの列がなにの列かがわからなくなってしまいます。

このようにFormアプリと同じUIデザインをしてしまうと、Formアプリとwebアプリでは違う動作が発生します。
つまり、webアプリにはwebアプリ用のUIデザインが必要になります。
今までと同じUIデザインでいいだろうと思うのはやめたほうがいいか、今までと同じUIデザインでもwebアプリに対応したコーディングを身につける必要があります。

HTMLのコーディングが不慣れ

普段はPG言語のコーディングをしているため、画面描写のコーディングに不慣れなところがあると思います。
Windows Formアプリだと、GUIで画面を実装することができます。
webアプリももちろんGUIで画面を実装することは可能ですが、最終的にはHTMLコードにしないといけないので、コーディングが必須になります。

コーディングが「苦手」よりも課題だと思うのが、「古い」ことです。
webアプリの中で、古いHTMLコードでの実装を見かけることがあります。
たとえば、`<table>`タグを使用してレイアウトの調整を行ったり、HTML5で廃止された`<font>`タグを使用したり。

なぜ、コードが古いままでもいいのかを考えるとSEO対策不要ということが大きいと思います。
業務システムなので、その会社の人しか使いません。
つまり外部からユーザーを呼び込む必要がありません。
そのため、SEOで好まれるコードであるHTML5に必ずしも従う必要がなくなります。

SEO対策をしなくてよいのは楽になるのでいいのですが、画面のデザイン変更のときの改修が大変になってしまうので、コードもきれいにしておきたいです。

取り組んでみたUIデザイン

以上の課題を踏まえて、別件のwebアプリ開発に携わったときに改善しようとしました。

今までの課題を解決した点

- web用デザインにしてみた
- CSSフレームワークを使用してみた

新しく出た課題

- デザイン意図が消えた

web用デザインにしてみた

webアプリなのだから、webアプリらしいデザインにしようと思いUIデザインをしました。
主に気をつけてみた点は以下のとおりです。

- よくあるwebアプリと同じ操作手順でアプリを使用できるようにした
- 表示内容を消えたり表示させたり切り替えたりして画面に表示する内容を調節した

よくあるwebアプリと同じ操作手順でアプリを使用できるようにした

業務システムの場合、毎回操作マニュアルも作成します。
ユーザーにアプリの使い方について学習してもらうことになります。
このユーザーへの学習負担を軽減するために、よくあるwebアプリと同じ操作手順でアプリを使用できるようにUIデザインをしました。
iPhoneやAndroidといったスマートフォンに採用されているUIや大手SNSのUIなどを参考にして取り入れました。

実際に社内でアプリのレビュー時に、とくに操作の説明をせずに「UIデザインのレビューをお願いします」と伝えただけで、みなさんアプリの操作ができていました。
独自性や突飛なデザインが不要な業務システムだからこそ、メジャーなUIデザインを取り入れることで、ユーザーへの負担が減ります。

必要な時に必要なものを表示するようにした

前述のグリッドビューのヘッダーを常に表示するようにしてみました。
スクロールすると画面上部にヘッダーを表示するようにしました。
ただ、ブラウザによって対応非対応がCSSにあって不便だと感じますが、ユーザーに対してブラウザの指定ができるのが業務システムの強みとしてスルーします。
これによって、Formアプリのデザインを引きずりつつも、webアプリに同様のデザインを反映することができました。

CSSフレームワークを使用してみた

HTMLコーディングが慣れていないということで、CSSフレームワークを導入してみました。
HTML/CSS実装にかかる時間を短縮すると同時に、無茶なコーディングを防ぐことができます。

たとえば前述のレイアウトとして`<table>`を使用しても、CSSで用意されている`<table>`が適応されることで表を表示するタグであるということが明確にわかります。
また、グリッドを使用することで、`<table>`で実装しようと思っていたデザインをグリッドで実装できるようになります。

そして何よりも、開発者自身が楽しくなります。
地味なFormアプリと違ってwebアプリは画面が華やかです。CSSフレームワークを使用することでより華やかになります。
私たちSEはデザイナーでないからこそ、フレームワークを使用して工数を減らしつつデザインレベルをあげることが大事になると思います。

デザイン意図が消えた

新しく課題も発生しました。

デザインは私が担当しました。
複数のアプリを管理するシステムの画面をデザインし、各画面のパンくずリストのところにアプリ名を表示していました。
私の意図としては、ユーザーが今管理しようとしているアプリ名を表示したほうがわかりやすいだろうと思ったからです。

その画面を先輩にレビューしてもらった結果、パンくずリストは画面の遷移順を表示するところだからそこにアプリ名を表示するのはおかしいと指摘されました。
さらに先輩から、画面のタイトル下にアプリ名を表示したらいいとアドバイスをもらいました。

私は言われたとおりにパンくずリストからアプリ名を削除し、画面のタイトル下にアプリ名を表示しました。

ここで私はミスを犯しました。
ここでもう一度パンくずリストは必要か不要かを考えるべきでした。
しかし考えずに先輩からの指摘どおりに修正したため、パンくずリストは残ったままです。
そもそものパンくずリストを実装した理由を考えれば、画面のタイトルの下にアプリ名を表示したことにより、パンくずリストの存在意味は無くなります。
そこを考えずに言われたままに修正したのが間違いでした。

レビューを受けて修正するときに、再度、そのデザインにした意図を振り返ってその意図と修正しようとしている点に整合性が取れているかを考える必要があります。
今後はもっとなぜそのデザインにしたのか、なぜそのような修正依頼があったのかを考えてUIデザインを極めていきたいです。