Get Feedback or Fail

zurb.com のブログ記事 Get Feedback or Failの概要。

製品やサービスに対するフィードバックに対する 5 つの W について。

What: 効果的なフィードバック

  • Targeted: 質問に対する回答であること。「これについてどう思いますか?」といった質問に対しては、価値のあるフィードバックは返ってこないので、具体的な内容にする
  • Actionable: 次のステップを明確にするようなものであること
  • Valuable: Targeted かつ Actionalble であっても、価値のないフィードバックがある。例えば「ここの 5 px はもう少し暗くした方がいい」とか「Powerpoint 形式で Export できるといい」など。質問の的を絞って、こういった価値のないフィードバックを避ける

Why: 成功するプロダクト

カスタマーのためのプロダクトなのに、彼らのフィードバックなしでどうして成功できるだろうか。製品を作る事に時間、情熱やリソースを注いでも、カスタマーに正しい製品を提供できているかどうかを検証しないのは問題である。カスタマーこそが製品を作る、または壊す人々である

Who: カスタマー、クライアントそして (あなたの)チーム

  • Customer: カスタマーがあなたのプロダクトを使い、対価を払う。積極的に彼らのフィードバックを求めること。カスタマーのニーズを満たすプロダクトが成功する
  • Client: クライアントをあなたのカスタマーとして、エンドユーザをクライアントのカスタマーとして考える。定期的なフィードバックを通してクライアントを興奮させ、あなたのデザインに投資させ、彼らの意思決定を助けること
  • Your Team: 今あなたがどんな作業をしているかを常に共有し、質問を欠かさないこと。デザイナーだけでなく、エンジニア、プロダクトマネージャやマーケッターなどの意見に耳を傾け、様々な視点からのフィードバックを得る

Where & When: 今ここで!

製品サイクルのどの時点でも、カスタマーのフィードバックがその製品の方向性を決める手助けとなる。フィードバックの価値を学び、できるだけ早い時点で頻繁に行うこと。

A Personal Note

フィードバック得るのは最初はキツい出来事だった。ZURB で働き始めた頃、批判は才能や自分の仕事に対する攻撃のように思え、自身のエゴに大きな打撃を与えた。しかし 2, 3 年後、フィードバックなしでは仕事ができないようになった。フィードバックなしのデザインは、誰もあたなの決定に投資しないし、その仕事の価値を理解しない。飛躍を遂げるためには、フィードバックを受け入れ、それに対応し、効果的に製品を洗練させていくこと。

Advertisements
Get Feedback or Fail

API プロバイダが犯しがちな 10 の間違い

10 Common Mistakes Made by API Providers – ReadWriteCloudの要訳というか超訳。

1. いつも全部が正しく動作していると仮定する

データベースのエラーやバックエンドの処理遅延などによって API の出力がおかしくならないように、ユーザに提供する前に依存性を確認して、APIがどう動くかを確認すること。開発者(APIのユーザ)は stack traceなどではなく、正規のレスポンスフォーマットでエラーコードなどが返ってくることを期待している。

2. お粗末なコミュニティ管理

開発者を引きつけるには、コミュニケーションを取って彼らの役に立つこと。開発者をパートナーと考えて対応する。

3. API ビジネスプロセスの規模を予測しない

規模が小さいうちは、ガバナンスの必要性は少ないが、API のトランザクションの規模が大きくなると、ファイナンスや法務にとっても重要な問題になってくる。

4. API をウェブサイトと同じドメインに置く

ウェブサイトと API それぞれのスケーラビリティを別個に扱えるように、別のドメインにする(twitter.com と api.twitter.com のように)。

5. 実際の環境でテストしない

もし、ウェブサイトがその API を使っていないなら、API を使ったサンプルアプリケーションをいくつか作ってみること。そうすることによって、API で取得できるデータの内容(組み合わせ)が適切かどうかを知る事ができる。API を使ってあなたのウェブサイトを再現できないとしたら、その API は修正する必要がある。

6. 悪質な挙動を想定しない

意図的なもの (頻繁なリクエスト、渡される JSON や XML データによる攻撃、SQL インジェクションなどのテクニック)や、スケーラビリティに関係するものを考慮して設計する。

7. ブラックボックステストをしない

アップデート時にはウェブサーバの設定変更等も行う事があるので、ユニットテストだけではなく end-to-end のブラックボックステストも行うこと。

8. API をコアビジネスと認識しない

成功したメディア、オンラインショップ、ウェブ関係の会社は、しばしばそのトラッフィックの 50% 以上が API 経由になっている。従って API を製品の 1 つとして扱うこと。

9. API について役員レベルのマネジメントを行わない

他の新規プロジェクト、ビジネスや技術と同じように (API についても) 理解と明文化されたゴールや評価基準などを持ち、各部署レベルの目標に落とし込んでいく必要がある。

10. エラーを tunneling する

よくあるのが、エラーなのにレスポンスコード 200 OK で返したり、すべてのリクエストを GET, POST で処理したり (PUT, DELETE を使わない)、ユーザに content-type を指定させない、など。

API プロバイダが犯しがちな 10 の間違い

Usability vs depopulated atmosphere

I read an interesting posts about a storategy of creating online service/community.

She wrote about not adding functions consciously even though it seems basic function at the beginning of the site. There is a qoute from another post by kensuu who provides (actually his company provides) Nanapi. Nanapi is website where people post lifehack technique. And it is said the reason why Nanapi didn’t provide search function at the beginning.

In early stage of a site, number of users, number of contents/posts are small. If users search the site, there is relatively higher possibility that he can not found the information that he want. Then he must feel that the site is not popular. If there is atmosphere of under populated, people leave and will not visit again.

There seems to be a strategy that creating initial version of your service less usable for some points consciously to avoid making depopulated atmosphere.

Usability vs depopulated atmosphere

PRM: Contact

Contact page shows a persons detail information (e.g., name, description, email, phone and tag.) You can assign tags to a person. You can also assign tags to your profile as well.

This page also shows to-dos and activities that are related to the person.

Contact history in the sidebar can be sorted by ‘contacted lately’ or ‘long silence’, that means you can easily to figure out who you should contact to next.

Image