「学習というのはたいへんな作業なので、ユーザーのやりたいことではない。そんなわけで彼らはデザインについては最低限のことしか学習しないため、知識レベルは長年低いままで留まってしまう。学習曲線はすぐに平らになってしまい、その後、ほとんど変化しなくなるのである。」

多機能が素晴らしいことで、機能を有効に使いこなすのが熟達することだ・・・という考え方は、ちょっと20世紀的な気もします。

機能もサービスも「触り心地」のようなものを楽しむようなものになってくのかな・・・。

ユーザーの知識の停滞を少しでも軽減する方法も紹介されてます。
それが有効かどうかは、わかりません。

くわしくはこちら
http://www.usability.gr.jp/alertbox/stagnating-expertise.html

エスリンガーは81年頃にはSONYの仕事をしていて、技術者といくつかのプロトタイプを作ったけど、経営陣は興味を示さなかったとか・・・。

82年のシリコンバレーのパーティでApple IIの設計主任だったRob Gemmellに「スティーブ・ジョブズに会うべきだ。クレイジーな男だけど、ワールドクラスのデザインをアップルに持ち込みたがってるよ。」と言われた事が始まりだったそうです。

記事内に出てくるいい言葉・・・
『structurally determined mediocrity』
「構造的に決定された凡庸さ」とでも訳すんでしょうか。

当時のAppleは（家電メーカなどと同様に）「構造的に決定された凡庸さ」に苦しんでいました。

エスリンガーはジョブズとはじめて会ったときに「ワールドクラスのデザインは「構造的に決定された凡庸さ」は機能しない」と言って、あらゆるデザインに大きな権限を持ってデザイン言語をアップルの精神にどう沿わせるかを決定する、デザイン・リーダーの必要性をジョブズに説いたそうです。

一方、ジョブズは「とんでもなく優れた製品こそがアップルを変革していく」と信じていて、「まずはMacintoshを100万台売りたい。それからアップルを世界最高の企業にしたい。」と言ったそうです。

起業家とデザイナーの素晴らしい関係。

くわしくはこちら
http://designmind.frogdesign.com/blog/my-way-to-steve.html

それから、
ハルトムット・エスリンガーはこんな人
http://designers-union.com/blog/archives/1743

もともとデザイナーだったんですね。
損もしたし、辛い時期もあって、紆余曲折もあって、なかなか魅力的な話。

「・・・ここでの教訓は、創立時の企業文化はこの上なく重要だ、という点だった。プロダクトに注ぐのと同じくらいの注意を会社の文化を正しく育てることに注がねばならない。」

「・・・しかし私は人間第一、テクノロジー第二というのが正しい優先順位だと思う。まず現実の人間について考え、それからテクノロジーの活かし方を考えるべきだ。」

「・・・われわれはTwitterという新しいコミュニケーション・ツールのごく初期のプロトタイプがやっとできた時期に、私はTwitterにとことん情熱を傾けていることに気づく経験をした。これはものすごく重要な教訓だった。」

どんな状況からも学ぶ事と発見があるということのようです。

くわしくはこちら
http://jp.techcrunch.com/2013/11/08/20131106be-emotionally-invested/

「『キッドＡ』のころは、僕も心からネットに入れ込んでいたんだよね。人と人を結び、コミュニケーションを促す、素晴らしい方法になるんじゃないかって、本気で期待していたんだ。でも、そしたら僕たちがやっていることは“コンテンツ”だって言われるようになったんだよね。大手企業から送られてきた手紙をちらつかせて、携帯電話のメーカーと契約を結んだら大金になります、なんて話をみんながするようになってさ。どうしてもコンテンツが必要なんです、ってね。こっちはいったい何なんだ？って不思議で仕方なかった。感情とかで、ある程度の時間や場所を埋めれば、それが売り物になる。そういうことなのか？って」

テクノロジーによってメディアはどう変わっていくか・・・または衰退してゆくか・・・。

米国の話ですが、日本も似たようなことになってるかも。
「米国のニュース・ビジネスは、真の意味で崩壊しました」とか、恐ろしいです。

くわしくはこちら。

それにしても、embedのコードが長すぎるし、サイズを指定できないとか・・・
がんばれ東洋経済オンライン。

おもしろい世代論。

「タッチ」であるか「クリック」であるかは、こんなに重大な事だったんだー。フラットデザインもこの流れのなかで理解できる気もする。

『インタフェースというものも大きく変化した。現代のインタフェースには「キーボードショートカット」や「保存」、ないし「クリック」といった概念も存在しなくなってきている。代わりに用いられるようになったのは「ジェスチャー」や「シェア」（共有）そして「タップ」といったものだ。』

『アプリケーションないしデバイスが「タッチ」で動作するかどうかというのは細かい話に思えるかもしれない。しかし「タッチ」は非常に重要な要素だ。というのは、マウスやキーボードによって現実を「比喩的」に捉えるのとは異り、より直感的な振る舞いに繋がっているという点で大きな意味を持つ。人気を集めているアプリケーションは、いずれも「タッチ」動作を非常に有効に活用しているものばかりだ。』

『「タッチジェネレーション」が求めるコンシューマーテクノロジー』

デザインの講評（チームメンバーが集まってデザインやプロトタイプについてレビューするプロセス）は、痛みを伴い、長い時間がかかって、焦点の合っていない議論になりがちです。
そういった落とし穴を回避するためのガイドラインです。

チームがゴールとコンテクストを共有できていない場合は、講評は長時間になり、非効率で不明瞭な成果につながります。
率直に言って、お互いに心証を悪くすることもあります。
そうならないためのルールです。

■誰によるデザインなのかを明らかにする。
たいていは、プロジェクトに参加しているデザイナーです。
問題の解決に取り組む彼らの名前を、そのデザインと一緒に提示することで、会議の参加者は
「解決策を探るデザイナーの手助けをすることが、今日の私たちの仕事なんだ」
と思うようになります。

■司会者を指名する。
講評が自然にうまく進んでいくと思わないことです。
司会者を指名します。続く8つつのルールに従って迅速に効果的に進行できる人を選んでください。
デザイナーでも結構ですが、少し偉い立場に人が望ましいです。
司会者が、どのデザイナーによるデザインなのかを紹介します。

■プロジェクトの目標をおさらいする。
デザイナーは、まずプロジェクトの目標を簡潔におさらいして、チームの皆に思い出させます。
1～5の箇条書きのようなものが良いです。
できれば、そのうちの1つは測定可能なものであることが望ましいです。
これによって、チームの皆は情報に基づいた判断が下せるようになります。
ホワイトボードにこれを書いておきます。

■自分が知りたいことについて具体的に質問する。
ハイレベル・ユーザーによるフローについてのフィードバックについてか・・・
肝心のビジュアルについてなのか・・・
講評が焦点を失わず有意義なものであるために、具体的な質問をするようにします。
また、この講評の結果をホワイトボードに書き出します。
馬鹿げたことにも思えますが、なんでもホワイトボードに書き出すことは、参加者が正しいフィードバックをする助けになります。みんな制約に感謝します。

■セールスポイントを簡潔に。
各画面についてのデザイナーからの長い説明は、時間の無駄です。
自分の作品について語るデザイナーの話は（私自身も含めて）長くて曲がりくねっています。
さらに悪い事に、参加者に先入観を植え付けてしまいます。
まっさらな状態で見てもらってこそ、有益なフィードバックを得られます。
長い説明をしてしまうと、理解・認識・把握などについての問題を発見しにくくなります。

■話す前に書いてみる。
デザイナーを紹介して、プロジェクトの目標をホワイトボードに描いたら、5分〜10分くらい間、参加者が静かにデザインを見てメモを取る時間をとりましょう。
この静かな時間で皆をデザインについてより深く体験して考えることができるようになります。
これは実際のデザインでも体験することです。
さらに良い点は、集団での意見の出し合いが簡略化されることです。
自分の意見を言う前に紙に書くようにすると、皆で同じ意見が重複することは少なくなります。

■悪いことも、良いことも
もちろん、建設的な批判は奨励したい。モックアップ段階で欠点を見つける事は、単純にデザイナーを励ますよりもはるかに有益です。
だれかの心証を悪くしたくないと遠慮していると、ダメな製品をリリースすることになります。
でも、デザインの良い点についてもメモに残しておく必要があります。
たいてい、講評が終わると、デザイナーは取り組むべき問題のリストを作ります。
もし、すでに良くできている点をデザイナーに伝えないでおくと、デザイナーは誤解して、細事にこだわり大事を逸する可能性があります。

■講評中にデザインしてはいけない。（それはデザイナーの仕事です。）
ときには別のアプローチを提案する事もOKですが、デザイン講評で問題を解決しようとしないでください。
デザイン・ワークは（他の批判的思考法と同様に）個人によって行われるのがベストです。
問題点を洗い出したら、その答えはデザイナーに任せましょう。

■タスクリストを持ち帰る
司会者は、議論をタスク（各メンバーの作業）に落とし込むように進行します。
問題がタスクに落とし込まれたら、その問題については議論をやめて、そのタスクをホワイトボードに書きます。（魔法で問題を解決することはできないので、そうなったら別のデザインを検討します。）
タスクが出尽くしたら、講評は終了です。

これらのルールでデザイン講評をすれば、たいてい速く進行できます。
そして（デザイナーを含めて）講評の結果について皆がよい手応えを得られます。
真剣に講評に取り組むことは、デザインを真剣に取り扱うことになります。
それは、チームにも製品にも良い事です。

さらに詳しくはこちら
http://scottberkun.com/essays/23-how-to-run-a-design-critique/

原文はこちら
http://www.fastcodesign.com/3019674/9-rules-for-running-a-productive-design-critique

これは参考にして、ぜひ導入するべきかと。

「どんなブランドにも、どんなビジネスにも、その可能性を実現するために優れたデザインが欠かせません。
世界は、もう ”平凡な製品” を必要としていません。
優れたデザインを創るすべてのデザイナー、ブランド、企業はいずれも、未来を創造していると自覚してください。
ただ過去の焼き直しをする以上の、何ができるかを考えることです。
それが顧客が満足してエキサイトする製品やサービスを作り出すための、私たちにとってのデザインなのです。」

というような話をしてるようです。
（翻訳間違っていたらすみません・・・）

「世界は、もう ”平凡な製品” を必要としていない。」という言葉は重いです。

現代におけるデザインとビジネスの関係を示してるかも。

フラストレーションが溜まるクライアントに対して、創造的にどう対処すべきか・・・
という記事。

「お金が絡む前にサヨナラしよう。」
「ノーと言えるガッツを持とう。」
「世間に自分の価値観を示そう。」
「潜在的なクライアントにコンタクトしよう。」
「プロジェクトの目的を明確にしよう。」
　・
　・
　・
英語でよくわからないけど・・・読んでみよう。

http://designtaxi.com/news/361266/Amateurs-Get-Angry-With-Clients-Professionals-Educate-Them/

あまりに鮮やかだったので・・・。
「注意力」は状況によって、他人からコントロールされやすくなるってことなんでしょう。

人の注意力を自由自在に操れるとしたら・・・・何かのデザインやUX/UIに利用して効果を上げようと考えるのは、絶対にやめたほうがいいですねー。