blog.kur.jp

バイオリンと山、自転車をこよなく愛するkurのチラシの裏。たまには技術的なことを書いたりするかも知れません。

それ、とりあえずは標準的なUIで作っとこうよ

デザイナさんから送られてきたアプリケーションの画面デザインの中には、そのUIを実現するのは相当な工数が必要だなぁって思われる物があったりする。例えば、めちゃくちゃかっこいいチェックボックスとか、すんごいクールなテーブルとか、斬新な画面遷移やら、エフェクトがグイングインかかってたりとか。

個人的には、かっこいいUIって大好きだし、できることなら実現したい。UIがかっこいいだけで、アプリケーションを使いたくなったりもするし。例えばTwitterクライアントって、今世の中には凄いたくさんの種類があるわけですけど、私から見るとできる事にはほとんど違いがないように見えます。タイムラインが見れて、投稿できて、RTできてふぁぼができるぐらい。中にはゲーミフィケーション的な要素を取り入れたクライアントとか、独自機能に力を入れてるものもありますけど。こういうジャンルのアプリだと、UIが差別化要素になることが多々あるので、UIに力を入れるべきだと思います。

だけど、ユーザに新しいコンセプト、新しい価値を提案するようなアプリケーションの場合、最初からそこまでUIにリソースを入れる必要ってあるんだろうか。

どこにリソースを割くかを考える

特に最近は、リーンスタートアップの影響か、とりあえず価値仮設を最低限検証できるものを作って、ユーザの反応を見ながら改善していくというプロセスが流行っている。このリーン的なやり方で行くと、とりあえずは標準的なUIで作ってみて、ユーザの反応を見ながら、凝ったUIを導入していくのが良いと思う。

時間は有限なので、凝ったUIを実装するためには納期を遅らせるか、他の機能を削るかしなければならない。例えば、iPhoneアプリの開発を例に説明するんだけど、画面の中に複数のデータを羅列したいとき。やろうと思えば、テキストラベルを動的に生成して画面に貼り付けてってことをコードで記述出来るわけですが、テーブルを使えばそんな面倒なことをやらなくても一瞬なわけです。チェックボックスみたいなUIを実現したいなと思ったときも、やろうと思えばテキストラベルとボタンとを組み合わせて、ボタンが押された時に画像を切り替えてみたいなことをすれば、かっこいいチェックボックスが作れます。だけどこれも、テーブルを使えば一瞬なわけです。

また、新しいUIってのはバグの温床にもなりやすかったり、ユーザビリティ上の問題がある場合もあったりもするので、価値検証初期の段階でそこに多くのリソースを割くのはどうなのかなぁと思うのです。

見た目はそこそこで良い

もちろん、見た目がどうでも良いとは言うつもりはありません。以前、Webサービスを開発する際は開発初期段階から見た目に力を入れるべきという記事で書いた通り、見た目と開発効率には相関がある。ただし、この記事でも触れている通り、とりあえずの見た目はTwitterのbootstrapを使うとか、多くの手間をかけずに実現できるレベルでよいと思うのです。

まずは標準で用意されているUIや、そのへんに落ちてるテンプレートなどを使ってアプリケーション全体として一通り処理を通してしまう。その後、この部分のUIはこれじゃダメだよねとか、改善したほうがいいよねとか考えながら、検討していけば良いんじゃないかな、と。

UIデザインには意図がある

ただし、当たり前ですがUIデザインには意図があります。だから、アプリケーションによっては、標準的なUIで作ってしまうと操作上の問題が出てくる場合がある。それを無視すれば、当然ながら何らかの問題が出てきてもおかしくない。例えば著しく操作性の悪いものになってしまったりする可能性がある。日本人の私から見て、一見無駄に見えるデザインでも、文化が異なれば必須のUIである場合もあると思う。

だから、実際にアプリケーションを開発する上では、デザイナーさんの意図を確認しながら、限られた工数、時間の中で、どこまで実現可能かを検討していく必要があると思う。世の中には不思議な事に、デザイナーとエンジニアの仲が悪いチームがあったりするんだけど、デザイナーもエンジニアも、良い製品を作ると言う点においては目的は一緒のはずなんで。