前回の記事の続きです。

前回の記事では主に個人制作アプリの話をしましたが、本記事では一般的なUIデザインと実装のプロセスについて考えたいと思います。

一つ、一般的な失敗例を紹介します。

スマホ画面操作の話なのですが、「縦スワイプでスクロール」かつ「横スクロールでドロワ表示」という仕様、一見破綻無いですが、実際作って触ってみるとスクロールさせるつもりがドロワ出てしまって、非常に使いづらくなります。
（最近ではスワイプを検知する条件がチューニングされていて、こういうUIを見かけることは減りましたが…。）

デジタルプロダクト開発の流れは概ね、スライドに書いた3つのパターンのどれかに属するのですが、デザインフェーズと実装フェーズが分断されていて、実装やテストのフェーズで問題が発見されても後戻りできない場合をよく見かけます。

ウォーターフォール式の場合は、テストの段階でインタラクションの問題が見つかっても、「仕様と矛盾してないから問題なし」とされてしまう場合があります。

問題ありとみなされても、デザイナーがエンジニアとは別の外注業者だったりすると、「追加発注するほどのことでもないか…」と看過されがちです。

アジャイル式であっても、デザイナーとエンジニアが分断されているとやはり同様ですね。

アジャイル式で、チームの中にUXデザイナーが居るならば、多くの場合で上手くいくと思われます。

ただ、このあたりはデザインに対するチームの考え方次第でもあります。
UXを阻害するものが発見された時に「これは即座に直さねば」と思えるチームならいいのですが、「これは（機能実装とか不具合解消の）後でやろう」と低く優先度付けされて、結局改善されないままリリースへ… となるケースも多いのではないでしょうか。

どんな開発方式であれ、デザインの修正は実装工程以降では行いにくい場合が多いと考えています。

前の記事（個人開発紹介）でお見せした図に戻るのですが、今述べたような「デザインを後から修正しづらい」という難点に対して、「デザインサイドでインタラクションの検証までやり切ってしまってから、開発チームへデザインデータを渡す」というのが一つの解決策となると考えています。

ここまで述べた思いを踏まえて、先日業務の中で「デザインサイドで、プロト実装してインタラクションの検証までやり切る」を実践してみました。

受託案件であり、また、未リリースのプロダクトであることから詳細は申し上げられないのですが、概ね成功し、お客様から好評をいただいています。

ただ、注意点がいくつかあります。

ソースぐちゃぐちゃ問題
プロトタイプは短期間でビルド&スクラップを繰り返すので、ソースの整合性・可読性は著しく低いものとなります。これをそのままエンジニアに「実装してね」と渡すわけにはいかず、リファクタしてから渡すか、エンジニアサイドでコーディングし直すことになります。

スケジュールやりくり
プロトタイプの検証終了タイミングを事前に定めることはできないので、スケジュールに柔軟性を持たすべく、期間的な余裕を設けたり、適切な体制を構築する必要もあります。

誰がプロト実装するのか
そしてやはり難しいのが、プロトタイプ実装を行う人員の確保です。デザインチーム内へエンジニアを引き入れるとして、都合よく空いてる人員が居るのは稀かと思われます。

プロトタイピングを過信するな
また、プロトタイピングをあまり過信してもいけない、ということを述べておきたいです。
長期にわたって操作して初めて問題が見つかるようなタイプのプロダクトの場合では、短期間でプロトタイプを作って1日かけて検証する、という形はあまり有効ではありません。

想定外のメリットもありました。

プロトタイピングを行う過程で、「実装作業上の問題はないか」を確認するためにアウトプットを実装サイドにシェアしていたのですが、どんどん良くなっていくプロトタイプを目の当たりにすることで、実装モチベーションが非常に向上したようです。

実際のところ、さきほどお話しした実業務の例ではかなり実装難度の高いUIをデザインしてしまったのですが、エンジニアさんは完全にデザイナーの意図通りのものを実装してくれました。

長々申しましたが、「デザインサイド内で実動プロトタイプを使用して検証し、その上で本開発フローに合流させる」という形、おすすめです。

と、ここまで自分で発見した新メソッドであるかのように語ってしまいましたが、実の所この話は目新しいものではありません。2016年に深津貴之氏の「確実によくするUI/UX設計」というスライドがバズりましたが、これの中盤あたりで書かれていることと主旨は同じです。
https://www.slideshare.net/takayukifukatsu/nikkei-renewal

LEAN UXとかデザインスプリントの考え方とも通じる部分が多いと考えています。それらの考え方を自分の置かれている環境に合わせてアレンジして実践してみただけのこと、とも言えます。

本記事で述べたことは、今後も実業務の中で適用・実践し、考えをアップデートしていく所存です。そのうちまた記事書きたいです。

なお、前記事の冒頭あたりで申したことの繰り返しになりますが、ここまで書いたお話はデザインチームと実装チームが分断されているような状況を前提とした内容となっております。
アジャイル式でスクラムチーム内にUXデザイナーが入ってるような、デザイナーとエンジニアが一丸となって協力し合えている状況ならば、話は大きく変わってくると思われます。

幸い、先日よりアジャイル開発を行っている事業会社さんに協力させていただく機会を得ましたので、そこで知見を得て、より好ましいデザイン実装フローを検討（＆実践＆検証）していきたいところです。

最後までお読みいただきありがとうございました。