スマホUI考（番外編） 顧客やユーザーの要望に全て対応すると、アプリは99%破綻する | fladdict
顧客や上司、ユーザーの場当たりな要望に対応しつづけると、どんなアプリもゴミアプリになる。たとえそれが理にかなった要望であっても。 なぜなら面積の限られたスマホでは「一画面の機能数とボタン数」が、使い易さと品質に深くリンクしているからです。 ということを、エラい人にプレゼンするのがお仕事の今日この頃。でも毎回毎回、同じことを説明するのがシンドイので資料をブログにまとめたいなぁと思うなど。 思考実験として、ここでは架空事例としてTwitterアプリを例に考えてみる。 何かの間違いで、日本の大手メーカーがTwitterを買収すると・・・UIデザイナーが体を張らないと99%ぐらいの確率でこうなるのです。 ここがオリジナル Request1: ダイレクトメッセージをトップ階層に ユーザーからの真っ当な要望。実際にはサービスの本質ではないのですが、要望はかなり多いはず。 ただTwitter社的にはme
スマホUI考（番外編） なぜ機能追加をし続けるとアプリが破綻するのか？ | fladdict
この写真は、アーミーナイフの名門ウェンガー社のジャイアントナイフという最高級ナイフである。141の機能を持つ、ギネス認定もされた厚さ24cm、重量1.3kgの世界で最も高機能なナイフだ。トップメーカーが自社製品の全機能を１つに集約したこの製品こそが、機能拡張の行き着く先を指し示している。 なぜ適切な機能追加であっても、機能を追加しつづけることで破綻をするのか？本エントリは、「スマホUI考（番外編） 顧客やユーザーの要望に全て対応すると、アプリは99%破綻する」の続きになる。 本エントリでは以下の４つの側面から、機能を追加するリスクを考える。まず第一に「選択肢の数が必ずしも善ではないこと」。次に「人間の判断力は使うほど消耗すること」。そして「画面スペースが有限のリソースであること」。最後に「どんなに機能を増やしても、一画面で強調できるものは限られていること」。これらの４つは全て、機能追加が最
Enterprise User eXperience Design - ユーザー中心設計の実践 - に参加してきた #devlove - Diary of absj31
Enterprise User eXperience Design - ユーザー中心設計の実践 - - DevLOVE 2012/11/08 Enterprise User eXperience Design - ユーザー中心設計の実践 - #devlove - Togetter (写真：会の冒頭、アイスブレイクな会話で会場を和ませる@papanda氏) 当初参加申込の勢いが結構凄くてあっさりキャンセル待ち状態になってしまってたんですが、日が近づくに連れて参加枠に入り込む事が出来たのでこの日参加して来ました。 開催会場は株式会社ぐるなび＠有楽町。お仕事終了〜会場来場まで慌ただしい時間が続いていたので地理的にはあんま良くわからない状態で来てしまったw 予定時刻から10分程遅れて本編開始。 (※この日は…というか数日前から微妙に体調悪く、この日も時折咳き込みながらの拝聴となってしまいました。併
UI, IX, UXデザイン，あるいは，スパイラル・モデル型UXデザイン | 8 million IDs
全く放置気味のこのブログだけど，最近UXデザインに関する話題が散見されるので，そろそろ筆者が過去に提案したデザインメソッドを応用して，UXデザインフレームワークでも構築してみるかと思い立った次第．せっかくなので，UIデザイン，IXDデザイン，UXデザイン，サービスデザインまで含めたテキストをつらつらと書きとめておくことにした． まずは，UIデザイン，IXデザイン，UXデザインについて，それぞれ説明するところからはじめよう． UI，IX，UX UIデザイン UI(User Interface)デザインは，ユーザからの情報の入力とシステムからの情報出力を実現する境界面のデザインである(図1)．UIデザインの場合，原則UIそのものに時間軸が存在しないため，平面もしくは立体物を表現するデータ，物理的に接触可能なオブジェクト，あるいは，システムへ情報を送ることのできる装置それ自体のデザインを指す．
UX/UIデザインガイドライン : 小野和俊のブログ
このところ、アプレッソの中でも、MIJS製品技術委員会でも、自分たちのソフトウェアのUX/UIをブラッシュアップしていくためにどんなことができるのかをディスカッションしている。 UX/UIデザインガイドラインとして各社の推奨する指針をまとめたものがWebで公開されているので、プログラマーであれデザイナーであれ、ソフトウェアの画面設計に何らかの形で携わるのであれば、基礎知識として主要なものには目を通し、プログラマーがデザインパターンの用語で手短にコミュニケーションが取れるのと同じように、「ここは○○ガイドラインの△△パターンを使うのはどうかな？」というような会話ができるようにしていきたいと思っている。 ■ Apple ・アップル ヒューマンインターフェースガイドライン ・iOSヒューマンインターフェースガイドライン(PDF) ・iPadヒューマンインターフェースガイドライン(PDF) ■ M
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Practical ux4publish