HOW TO GO

〜昨日の今日とは一味二味違うBlog〜

手書き風ワイヤーフレームで進める画面定義の話

主に企業向けの業務システムなんかを作ったりする仕事してます。
SIerなのでお客さんとどんなシステムを作るかあーだこーだ言いながら決めていくのですが、
いつも困るのが画面をどんな感じにする?ってところです。

ちょっと前に社内勉強会で発表したのですが、最近振り返る機会があったのでBlogにしてみます。

どんな画面が使いやすいの?

  • 要件は聴きます。どんな目的でこのシステムを作るのか、とか。
  • なのでなんとなくですが、画面の構成・画面遷移など考えることができます。
  • でも細かい使い方やは画面イメージを見てみるまでお客さんもわかりません。
  • 手戻りもイヤなので画面の定義はちゃんとやっておきたいところです。
  • 「なんかいい感じで」と言われても、お客さんの好みもありますよねぇ…。

そんな課題を解決すべく、iPlotzという手書き風ワイヤーフレーム作成ツールを使って画面の定義をした話です。

http://iplotz.com/
f:id:sugiim:20130427182338p:plain


最初からhtmlで画面作って見せれば?

よくマネージャーから言われます。なんどかやったこともあります。
でもなかなかうまくいきません。

htmlを作るのは手間が掛かる

htmlで画面を作る→お客さんに提案→修正する→また見せる、を短い期間でやるのは大変です。

最初からキレイな画面を作っていかないといけない

イケてない画面を持っていくのはダメです。お客さんは「このデザインになるの…?」「ここで指摘をして修正しておかないと」と感じてしまいます。かと言って最初からキレイなデザインのhtmlを作るは大変です。デザイナーも普通はいませんし。

「htmlで作っておけば製造で楽ができるぞ」のウソ

「流用すれば製造の手間が省ける」なんかそれっぽいですが、実際はあまり手間は省くことができません。
IDE、フレームワークなどを駆使してコーディングしていくので、結局作り直しってことが多いです。あればそりゃ参考になっていいんですが。

「画面定義とちょっと違うんですけど」という弊害が起きる

htmlで定義をしたので、完成品はそのままその通りの画面になるとお客さんは思います。作る側もそのままに出来ればそうしたいです。
だけどcssJavascript、他ライブラリの都合で微妙に違う画面になってしまうことが多いです。がんばって同じにしようと思えばできるのですが、その工数たるや…。

あえて手書き風

手書き風のツールを使うことで以下のメリットが得られると考えました。

  • 簡単に作れて修正も楽
  • 細かいデザインの指摘にならない
  • 画面の使い方をなんとなくわかってもらえ、業務のイメージをしてもらえる。→質の高いレビューになる。


注意したいところ

手書き風のワイヤーフレームでお客さんと合意をとりましたが、以下のことは注意すべきでしょう。

デザインをカッコよくする

手書き風で進めたので、「構成はこんな感じでいいから、いい感じの色とかにしておいてね」は必ず言われます。がんばりましょう。
幸いにもbootstrap.cssJQueryなどそれなりのUIを実現できるライブライが世の中にはあります。デザイナーがいなくてもそこそこ普通の見た目にはできるかと思います。

実装時のJSやCSSのライブラリをある程度想定しておく必要がある。

iPlotzで画面で使う部品を選ぶのですが、実際の製造時に「実装できない!!」ってなるとアホです。
実際に使うライブラリのことは知っておきましょう。