Entries of 情報デザイン

企業サイトをスマホ対応するならば、地図はできるだけつけるべき

最近はスマホ対応サイトがだいぶ増えてきたけれど、PC版にはある地図情報を省略しているサイトが多い。

だが、ユーザーの行動を考えた場合、会社や会場のロケーションの確認は、移動中に行われる可能性が最も高い。このためPCサイトで地図を表示していながら、スマホ版では地図を表示しない・・・というのは、ユーザーのアクションを阻害してしまう。

実際、出先で会社の場所を調べようとしても、住所や地図にアクセスできない企業サイトはかなり多い。実生活でも困る事がしばしば。

ユーザー中心で考えた場合、階層が深くてもいいのでスマホ版にも、住所、電話番号、地図などはしっかり載せる方が良いと思う。一般論としての「スマホ対応サイトは情報を絞るべき」は正しいが、どの情報を削るべきかが精査するのは中々難しいなぁと思うなど。

適切なタイミングで適切な情報にアクセスできないならば、PCサイトだけのほうがユーザー体験は高くなってしまう。

ペーパープロトタイピング入門 – 第4回 見やすいペーパープロトの描き方

ペーパープロトタイピング講座シリーズ。第4回は清書の仕方。絵心なんて必要ない、エンジニアリング的アプローチからのデザインスケッチの描き方講座。チーム共有やプレゼン用に、スピーディーで効率の良い清書のしかたを紹介する。(第3回は準備に時間がかかりすぎたので、第4回を先に掲載)

  • シャーペンでアイデアを練る
  • サインペン3種類で太さに差をつける
  • マーカー3種類で濃淡をつける
  • ポップアップや状態変化をポストイットで作る

ペーパープロトタイピング入門 – 第2回 ペーパープロトタイピングに使う道具

ペーパープロトタイピング講座シリーズ。第2回は準備編。前回はこちら。プロトタイピングを始めるにあたって必要なものを列挙する。

ペーパープロトタイピング入門 – 第0回




先日リリースした、スマホアプリのペーパープロトタイピング用ノート

商品として販売した以上、お客様のフォローアップは必須。ということで、ペーパープロトタイピング講座をはじめようかと。
全体構成は以下のような感じで、5回ほどにわけて解説していければと思います。

第1回、どうして紙でプロトを作るのか?
紙で行うプロトタイピングの利点や特徴。ワイヤーフレームとの違いについて。
第2回、ペーパープロトタイピングに使う道具
自分でやってみるのに最低限必要な道具や、あると便利な小物などを紹介。
第3回、ペーパープロトタイピングの仕方
実際に紙をつかって、アプリケーションのプロトタイピングを行ってみる。
第4回、見やすいペーパープロトの描き方
チーム共有やプレゼン用に、見栄えのいいペーパープロトを手早く描く方法。
第5回、ペーパープロトから動作モックアップを作る
POPなどのアプリを使って、紙のプロトタイプからインタラクティブな動作モックを作る。

これさえ読めば、簡単にペーパープロトをプロジェクトに導入できる・・・そんなチュートリアルを目指します。

入れるべき機能と排除すべき機能の分類メモ

クライアントプレゼン用の覚え書き。
「機能」のほとんどは以下の5種類に分類できるので、搭載するまえにどのカテゴリに属するかよく考える。

スマホUI考(番々外編) 誰得の100徳ナイフを買ったというお話

久しぶりの更新。皆様は如何がお過ごしでしょうか? 僕は8月の休日が0日です。
あと左手から血が出てます。

スマホUI考(番外編) なぜ機能追加をし続けるとアプリが破綻するのか?

この写真は、アーミーナイフの名門ウェンガー社のジャイアントナイフという最高級ナイフである。141の機能を持つ、ギネス認定もされた厚さ24cm、重量1.3kgの世界で最も高機能なナイフだ。トップメーカーが自社製品の全機能を1つに集約したこの製品こそが、機能拡張の行き着く先を指し示している。

なぜ適切な機能追加であっても、機能を追加しつづけることで破綻をするのか?本エントリは、「スマホUI考(番外編) 顧客やユーザーの要望に全て対応すると、アプリは99%破綻する」の続きになる。

Photoshopとかのフォント選択UIを改善してほしい・・・

Photoshop… というか、Adobe系アプリのフォント選択が死ぬほど使いにくい件。
フォント選択で、こうズワーッと全てのフォントが列挙されても探しようがない・・・

Macディフォルトの挙動だからしょうがないっちゃしょうがない。
でもAppleルールを無視して独自UIを作ってるのだったら、こういうところこそ改造して欲しいなぁと。

せめて下図のように、親階層に「ユーザー定義の分類フォルダ」を作ったり、「このPSDファイルないで使われている書体」みたいなスマート分類があるといいなぁと思うのです。



これだけで、欲をいえばこのフォント分類がAdobe製品共通で使えると、すんごい便利だと思うのだけど、そうなってくれないかなぁ。
もちろんAppleが直してくれてもいいんですけど。

わかりやすい「エレベーターの開閉ボタン」ってどんなんだろうね?

Twitterで「ボタンと間違いやすいサイン」について呟いたら・・・
いつのまにか「間違いやすいエレベーターボタンのデザインの話」に巻き込まれてたでござる。

面白そうだったので、自分でも考えてみたり。コアコンセプトは以下のような感じ。

  • 安全側にマージンを設ける
  • 表現の為に安全を犠牲にしない
  • 迷ったらコンサバに。チューニング芸で頑張る。
  • 視覚的/言語的にハンディキャップがある人にリスクを負わせない。「ってか、そこは周囲の人で吸収する社会にしようぜ!」という思想を、そこはかとなく埋め込む。

Amazon流の開発術では、まずプレスリリースを作る

Amazonでは製品開発をするとき、まず最初にプレスリリースを書くらしい。これは”Working-Backwards“と言うデザイン手法。面白げなので色々と調べてみた。

Working-Backwards法の商品開発では、お客様の視点をスタート地点にするため、開発前にプレスリリースを作成する。プレス内容は、既存プロダクトの問題点と、それを新製品がどう解決するかが中心になる。

プレスがユーザーに響かなかった時点でプロジェクトはボツ。そもそもその商品は作らない。これにより見当違いな商品を作るリスクを、一番最初の段階で低コストに回避できる。

このWorking-Backwards法で書くプレス内容は主に以下のとおり。

    見出し
    顧客が商品を理解できるタイトル
    副題
    ターゲット層と、彼らのメリットを1行で。
    概要
    商品の特徴と利点をまとめる。この段落で全てを理解できるように。
    課題
    このプロダクトが解決する課題を説明。
    解決
    プロダクトがどのように課題を解決するかを説明。
    コメント
    自分による紹介コメント(社長のコメント的なもの)。
    使い方
    どれくらい使い方が簡単かを説明。
    ユーザーからの声
    仮想ユーザーからのコメント。
    締め
    最後にしめ、次にユーザーがどうすればいいかを示す(Amazonで買えます!等)。

プレスは1〜1.5ページほどに納め、長過ぎる場合はFAQなどを作って補足する。

ちなみに、Amazonでは社内グループでのパワポは非推奨だとか。なぜなら口答プレゼンは、プレゼンターの話術に依存するからだとか。最終出力であるプレスやQ&Aに落とし込むことで、商品価値を中立的に見極める為。

Amazonの会議では、最初の10-15分はみんなプレスを読み、完全の沈黙状態になることも珍しくないのだそうです。

一般的なWorking-Backwards法では、最終的には本開発スタートまでにプレス、Q&A、ユースケース、マニュアルなどを作る。

プレスリリースを作る
その商品の存在意義と魅力を説明できるプレスリリースを作る。ユーザーに響かなければ、プロジェクトは終了
Q&Aを作る
プレスリリースを元にQ&Aを作る。プレスを読んだ人が疑問に思うこと想定し、プロダクトの魅力を理解できるようにする。
カスタマー・エクスペリエンスを作る
このプロダクトお客が、いつ、どのように使うのかのシナリオをまとめる。ここでリアリティがなかったら作り直す。モックアップや、エピソード、デモビデオなどを作ってみる。
マニュアルを作る
このプロダクトは何か? どのように使うか? 注意することは?といった「お客様が知るべきこと」をまとめた、簡単なユーザーマニュアルを作る。

同様の手法としては、「ゲームストーミング ―会議、チーム、プロジェクトを成功へと導く87のゲーム」にて、パッケージから製作を開始するDesign the Box法が、「Innovation Games」という洋書でProduct Box法として紹介されています。このInnovation Gamesのほうは未訳らしいので、日経BPとかから翻訳でて欲しい。



確かにこういった作り方をすれば、確実に誰得の地雷プロダクトを作らないですみそう。

<追記>
ここら辺の手法を調べるのには、Inspired: How To Create Products Customers Loveと、「リーンソフトウェア開発と組織改革」という本もいいらしいです。リーン・スタートアップならぬ、リーン・ソフトウェア開発。ここら辺はまだ未読。