レガシーユーザーインターフェースにありがちな3つの病と治療法

[CrowdWorks Advent Calendar 2017](https://qiita.com/advent-calendar/2017/crowdworks) の17日目の記事です。

![image_01.png](https://qiita-image-store.s3.amazonaws.com/0/5583/e6e87afa-9d17-b8d2-aaee-c5dda27130a2.png)

こんにちは。
UXデザイングループのデザイナー上田です。

突然ですが、**「レガシーユーザーインターフェース」**と聞いて、皆さん何を思い浮かべるでしょうか？

自社サービスやクライアントのWebサイトなど、担当しているサービスの使い勝手の悪さや構造の闇深さを連想し、古く負債を抱えてしまったサービスに対してどのようにアプローチして解決すべきか頭を悩ませている方も少なくないのではないかと想像します。

エンジニアリングの視点で、成長し続けるサービスが抱えるジレンマとして「リファクタリングの工数を割けない」「中長期のアーキテクチャ設計を十分に検討する余裕がない」といった声を耳にし、実際に古く負債を抱えてしまったシステムやソフトウェアを「レガシーソフトウェア」と呼んだりするようですが、実はデザインの視点でも急成長するサービスの抱える代償として似た現象は起こりうると考えており、実験的に「レガシーユーザーインターフェース」と呼んでみます。

では果たして、**デザイン視点での「レガシー」とは何なのか？そしてどんなアプローチで「レガシー」を解決に向かわせるのか？**

今回は私なりの視点であまり多くは語られてこなかったこの**モヤモヤするユーザーインターフェースのレガシー感を「病」というフォーマットで言語化し、それぞれ実際に取り組んでいる「治療法」とセットでご紹介**することで、これから新しくサービスを立ち上げる方や既に古く負債を抱えてしまったユーザーインターフェースと対峙している方にとって少しでもお役に立てれば嬉しく思っています。

レガシーユーザーインターフェースにありがちな病は無数にあると思いますが、今回はその中でもありがちな3つに絞ってご紹介できればと思います。

## 病名1.「情報アーキテクチャ不全」

![image_02.png](https://qiita-image-store.s3.amazonaws.com/0/5583/a3a2e347-8bd2-550c-434d-ff5adb93cb47.png)

一つ目は、情報アーキテクチャ不全という病です。

情報アーキテクチャとは、対象のWebサービスやアプリが提供している情報を可視化し、ユーザーにどんな行動を取ってほしいのかを考え、適切な機能やコンテンツの配置に落とし込むアプローチのことです。

サービスが成長する中で、新機能を追加する際にリリース当初に設計した少ない機能の範囲での情報アーキテクチャでは対応できないことも多い一方で、情報アーキテクチャの見直しは検討難易度も高いし時間的なコストもそれなりにかかるため、**後回しにしてとりあえず機能を足してしまいがち**ですよね。そうすると**みるみるうちに情報の構造が複雑になってしまい、ユーザーが混乱したり、迷ったりしてしまう症状に陥る**ことになります。

※類似する考え方として[「誰のためのデザイン？」](https://www.amazon.co.jp/dp/478850362X)という本で、「機能症」という概念が紹介されています。

また、**新しい機能やコンテンツを追加する時に、ラベリングや導線で延々の議論が続いてしまい収束しない経験**はありませんか？ユーザーの混乱を招く複雑な情報構造になってしまっているということは、裏返すと開発チームの視点で見ても同じように整理のついてない状態なことがほとんどなので、大抵は**開発スピードの鈍化、自社サービスの展開力の低下**につながります。

いやー。怖いですねー。

### 情報アーキテクチャ不全の治療法：デザインシステムの導入

情報アーキテクチャ不全に陥った時、根本的な課題の解決としては、デザインシステムの導入を検討してみるのがよいかと思います。

デザインシステムとは、色、文字、レイアウトといった基本的なデザイン要素の原則を綿密に定め、Webやスマートフォンを始め、タブレット、ウェアラブルデバイスといった様々なハードウェアで統一的なデザインを実現することにより、適切にサービスの世界観やデザインそのものを機能させる狙いを持ったガイドラインのことです。デザインガイドライン、デザインシステムの違いの厳密な議論は省略します。

![1_RX55dDNFdlOM1CsbOC33BQ.png](https://qiita-image-store.s3.amazonaws.com/0/5583/0bbfd9e9-af16-53ad-9989-c3b4bd19879e.png)

（引用: [How we designed Foursquare Swarm 5.0](https://medium.com/foursquare-direct/how-we-designed-foursquare-swarm-5-0-d774b3164f3f)）

海外の事例だとAppleの[Human Interface Guideline](https://developer.apple.com/ios/human-interface-guidelines/overview/themes/)、Googleの[Material Design](https://material.io/jp/guidelines/)、Salesforceの[Lightning Design System](https://www.lightningdesignsystem.com/)などが代表的で、国内ですとVasilyさんやメドレーさんなどがブログで制作の裏側を公開されていますので、リンクを貼らせていただきますm(_ _)m

* [効率的なアプリ開発のためにデザインガイドラインを作成した話](http://tech.vasily.jp/entry/design_guideline)
* [デザイン言語システムを入れたらコミュニケーションコストがぐっと下がった話〜メドレーTechLunch〜](http://developer.medley.jp/entry/2017/08/03/160000)

デザインシステムとして**サービスの情報設計や見た目を整理し、画面構成やコンポーネントの使い方を設計**することで、効率的に日々の機能開発を進められるようになります。デザインシステムの構築は骨が折れますが、**ユーザー体験の向上や開発の生産性の向上につながる施策**になります。

### クラウドワークスの場合

かく言うクラウドワークスも、情報アーキテクチャ不全を抱えているサービスの一つです。

初期の段階でUIのコンポーネントをパーツ単位で管理するスタイルガイドは導入されていたのですが、ボタンや各コンポーネントのスタイルなどデザインの表面的なレイヤーのルールを策定したもので、**画面構成や各コンポーネントの使い分けを明確に示すガイドラインではなかった**ので、形骸化してしまっている部分がありました。

そのため、今年の10月からクラウドワークスのUXデザイングループでは新たにデザインシステムを構築するプロジェクトを正式に始動させ、現在進行中で策定を進めている最中です。現時点で詳細をお伝えできず申し訳ないのですが、そのうち [CrowdWorks Designer Blog](http://designer.crowdworks.co.jp/)
 で公開します。

![image_03.png](https://qiita-image-store.s3.amazonaws.com/0/5583/8767bb1a-0db6-7d03-e318-854001073970.png)
※画面構成の改善の一環で現状の画面構成を分析した資料の一部

また、デザインシステムのようなサービス全体に関わる大掛かりな取り組みではなく、日々のサービス改善の活動の中で適切に情報アーキテクチャの設計を実践し続けることも重要だと思っていて、具体的な事例としてはUXデザイングループの田村さんが以前に書いた以下の記事をご参考いただければと思います。

* [クラウドワークスにおける情報アーキテクチャ（IA）設計の実践例](http://designer.crowdworks.co.jp/entry/ia-practical-example-in-crowdworks)

## 病名2.「バナー依存症」

![image_07.png](https://qiita-image-store.s3.amazonaws.com/0/5583/76efb499-a364-433c-499f-1854c296a6d2.png)

バナー依存症とは、トップページやマイページなどアクセスの多いページがバナー置き場になる病いのことです。

実はこれ、オライリーで出版されてる「デザインの伝え方」という本でも紹介されてまして。

**トップページ症候群**
アプリケーションの起動画面やウェブサイトのトップページが「なんでもありのガラクタ入れ」と化してしまう事態。リンクやボタン、バナー広告がひしめきあって使い勝手が非常に悪く、デザイナーが「泣きながら寝入る」しかない。

・・・身に覚えのある方もいるのではないでしょうか。最近はあまり見かけなくなってきましたね。

バナー依存症が発症してしまうと、対象ページにバナーを五月雨に追加する形になりがちで、使い勝手が非常に悪くなってしまい、**ユーザーの適切なサービスの理解を損ない、ページの本来の役割を果たせない症状**に陥ります。

ユーザーの期待や目的と内容が異なるケースが多いので、**ユーザーの離脱につながりやすく、コンバージョンなどの成果も多くは出しづらいのかなと思います。**残念ですね（マイクロコンバージョン的なものはもちろんあると思いますが、あまりオススメできません。）

### バナー依存症の治療法：ユーザーの行動を阻害しないお知らせエリアの確保

具体的なアクションとしては、 ユーザーの行動をできる限り阻害しないバナー表示エリアの確保や、ユーザーが新着の情報を受け取りやすいお知らせ機能の整備などがよいのではないでしょうか。**ユーザーに訴求したい新サービスや新機能が増えること自体は喜ばしいことなので、伝えたい情報がしっかりとユーザーに伝わりやすい仕組みを作ることが重要と考えます。**

### クラウドワークスの場合

クラウドワークスはバナー症候群の感染に気づき、対策を進めていますが、まだ道半ばです。

実際にクラウドワークスのトップページやマイページでもファーストビューにサービスの機能とは関係ないバナーがたくさん表示されてしまう課題など、症状に現れていまして、現時点の対策としては、ユーザーのサービスを利用する行動を阻害しない形で新着の情報を露出できるように、**マイページのUI改善のタイミングでデザインを変更・リリースなどの手を打っている状況**です。

![image_04.png](https://qiita-image-store.s3.amazonaws.com/0/5583/7f085a9d-a224-c730-f835-a1294c326e92.png)

## 病名3.「ターゲット失調」

![image_05.png](https://qiita-image-store.s3.amazonaws.com/0/5583/6b685702-14d3-2ca1-6c4c-4bfe2b07c6ca.png)

最後の病名は、ターゲット失調です。

ターゲット失調とは、**サービスのターゲットとなるユーザーを曖昧にしたままサービス開発を進めてしまい、機能やコンテンツの一貫性を保てなくなってしまう病い**のことです。

**開発チームから「自分たちは誰のためにサービスを運営しているんだろう？」「これは誰のための施策ですか？」という声を聞いたことはありませんか？**ものづくりをする上ではターゲットの設定は当たり前のようにも思えますが、競合の動きや技術の進化に引っ張られる形でサービスを開発をすると、ターゲット失調にかかる可能性が高まります。開発チームもモチベーションにも影響しますね。

### ターゲット失調の治療法：定性調査・分析

具体的なアクションとしては、**ユーザーインタビューなどの定性調査によるペルソナやカスタマージャーニーマップを通じたターゲットとなるユーザーや体験の可視化が一般的です。**

定量ではなく定性的にユーザーの属性（人物像、価値観など）を明らかにすることは、プロダクトの戦略や施策を考える上での重要な材料としてだけではなく、**チームメンバーのユーザーについての共通の理解を促し、議論のスピードを加速させることにも役立ちます。**

![da_0.png](https://qiita-image-store.s3.amazonaws.com/0/5583/4f27f019-7217-7fa3-cab0-2335cb8a428c.png)

（引用: [CUSTOMER JOURNEYS AND PROFILES](https://ilab.dk/product/customer-journeys-and-profiles)）

### クラウドワークスの場合

クラウドワークスは今年から定性調査の取り組みを始めています。

ユーザーインタビューやユーザビリティテストの実施や分析の回数を重ねるごとに、少しずつ自分の中にもユーザーの人物像やニーズについての感覚が芽生え始めてるようにも感じますし、ペルソナやカスタマージャーニーマップといった形で具体的なアウトプットになりつつある状況です。

![image_06.png](https://qiita-image-store.s3.amazonaws.com/0/5583/db3b814e-1475-b7c1-b7f8-436ee914d8a4.png)
<small>※実際に社内で制作したカスタマージャーニーマップの一部</small>

具体的な取り組みは中心となって進めているUXデザイナーの八尾さんがブログで記事を書いているので、ご参考ください。

* [検索結果一覧のUI改善でKPIが17.5%向上した話（UXデザイナー編）](http://designer.crowdworks.co.jp/entry/ux_research_casestudy_vol1)
* [自社サービスでカスタマージャーニーマップを作ってみて見えてきた3つのこと](http://designer.crowdworks.co.jp/entry/customer-journey-map-uxdesign)
* [本だけではわからなかったユーザビリティテストのリアル](http://designer.crowdworks.co.jp/entry/usertest)
* [新卒の見習いUXデザイナーがユーザーさんの声を聞いて感じたこと](http://designer.crowdworks.co.jp/entry/2017/05/25/170000)

## さいごに

いかがでしたでしょうか？

レガシーユーザーインターフェースの抱える3つの病と、それぞれの治療法についてご紹介しました。

書き進める中で感じたのは、どの病いも症状が明らかに顕在化するわけではないので、病いの自覚や対策の打ちづらさがあるなーという点でした。数字でも表しづらい分野なので、サービスの成長フェーズや優先順位について適切に各取り組みの必要性を判断する力が求められそうです。

以上、この記事がこれから新しくサービスを立ち上げる方や既に古く負債を抱えてしまったユーザーインターフェースと対峙している方にとって少しでもお役に立てれば幸いです。

引き続き [CrowdWorks Advent Calendar 2017](https://qiita.com/advent-calendar/2017/crowdworks) をよろしくお願いします！

※本記事は CrowdWorks Designer Blog の [“デザイン” を重視しないプロダクトに発症しがちな3つの病い](http://designer.crowdworks.co.jp/entry/products-three-diseases) を改定・修正した内容です。