【Tech Founders Japan】 Foodspottingから学ぶユーザーエクスペリエンス設計の勘所 - IDEA*IDEA ～ 百式管理人のライフハックブログWe'll be back soon! Our site is currently undergoing maintenance. Please check back later.
nanapiを作る上で気をつけたことのまとめ : けんすう日記
ライフレシピ共有サイトの「nanapi」というものをリリースしてみました。 nanapi[ナナピ] | 7分であなたの生活を便利にしちゃうライフレシピ共有サイト おかげさまでいろいろと紹介していただいたみたいでアクセス数高くていい感じです。 今回、どのような設計にするか結構考えて作ったのでそれを公開します。 ※ここでいう設計とは、どうユーザーに動いてもらいたいか、等のコンセプトに近い意味での設計で、システム的なものではありません！ 参考にしたサイトや記事 作るにあたって参考にした記事はこちら 『Stack Overflow』から学ぶ最近のコミュニティ構築術 - IDEA*IDEA すごくよくまとまってます。コミュニティを作る人には絶対よむべき記事ですね・・・。 デザインとかインターフェイスはこのサイトを結構参考にしました。 Kickstarter シンプルで伝えたいことを伝えているなあ、と
画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
fallinstar.org
オリジナルフォントが作れるiPad用フォント作成アプリ「iFontMaker」｜linker journal｜linker
