先日、「iOS Safariで絶対配置(position:fixed)して惰性スクロールしてもロックしない、フリーズ回避方法」という記事を書いたときに、エンジニアのお友達からこんな嬉しいコメントをいただきました。

機能よりユーザビリティ

「ユーザビリティは機能に勝るという意識があるだけに、これはスゴイ」

デザイナーではなく、エンジニアの発言というのがポイント。
こういう思考を持ったエンジニアさんは超リスペクト。一緒にお仕事できたらいいなと素直に思う。

結局、どんなに優れた機能も使い勝手が悪いせいで、使われなくなることの方が問題ありだ。

逆に、機能よりUI/UXの優先度が低いサービスを見ると残念になる。
そんなサービスの特徴をピックアップしてみたい。

Badなケース

もし何かしら身に覚えがあり不快に感じたら、ぜひ逆説に捉えてほしい。ダメにならないよう配慮すればいいだけだ。もちろん、クライアントワークでどうにもならないケースもあるだろう。その場合は発注側への喚起につながると嬉しい。

• 学習コストと概念モデルの理解と経験が足りない発言者の発言力が強い
• ゲーミフィケーションの理解と経験が足りない発言者の発言力が強い
• インターフェイスデザインの知識と経験が足りない発言者の発言力が強い
• 営業やエンジニアがUI/UX担当より立場が強い
• そもそもUI/UX担当者がいない、もしくはステークホルダーにいない
• コンテンツより見た目を重視している発言者の発言力が強い
• 明らかに過剰な要件だが削除できない
• 広告モデルで広告の表示位置が優先されたデザインになる

それって必要最低限？！

新規サービスの立ち上げには、リーン・スタートアップのMVP（Minimum Viable Product）という手法が有効である場合が多い。これは、実用に足る最小限の製品を用意することで開発工数を減らし、仮説検証を繰り返していく方法なのだが、「実用に足る最小限の製品」の定義がズレていると仮説検証の精度は悪く、スピードも出ない。
言いたいのは、機能が整えば、使い勝手が悪くても慣れてもらうという考え方はかなりまずいということ。ここに、ユーザビリティは機能に勝るという意識があるとUI/UXをチューニングするための開発も機能を開発するのと同レベルで重視されるはずなのだが、残念ながらそうはいかない。

また、真逆のケースもある。ウォーターフォールモデルに慣れてしまっていると、必要最低限の要件を決める段階で、あれもこれもと過剰になってしまうパターン。残念ながら、この手の場合は、ウォーターフォール型を分割するだけでピボットという概念を取り入れることはできないことがほとんどだ。

デザインについて。
みんなの意見を都度確認しながら進行していては、正しいユーザーインターフェイスの構築はできない。折衷案は存在しない。それぞれの案を検証する必要があるだろう。ただ、そんなことをしていたら何も進まない。
スプリント単位で確認し、目的を達成するための手段として判断し、方向性は間違っていないかを確認し、それ以外は担当者に任せるべき。

Goodなケース

• 成果物の目的を明確にし、担当者全員が共有している
• 目的を達成するために、自分の役割を全うする
• 他の役割に意見をいうときは、解決案ではなく、問題点を指摘する
• 他の役割を尊重する

至ってシンプル。
このすべてが揃ったプロジェクトは、まず失敗がない。
関係者がポジティブにモチベーションを維持できるから、やり続けられる、というのがその背景にある。

これまでの体験談

ここに紹介したケースは、どれも実体験だ。これまで、さまざまなサービスやサイト構築に携わらせてもらってきた。プロジェクトによって、WEBディレクター、UI/UXデザイナー、SEO兼コーダー、アナライザー、などさまざまな役割を担当させていただいた。業界歴16年ともなるといろいろあります。

関係者がポジティブにモチベーションを維持しているのに、うまくいかない場合は、Badなケースに該当している項目がないか確認してみると、意外なところに課題打破できる糸口が見つかるかもしれない。