Shape Up - Chapter 2: Principles of Shaping - Shapingの原則
Shape Up - Chapter 2: Principles of Shaping - Shapingの原則
Wireframes are too concrete: ワイヤーフレームは具体的すぎ
デザインリーダーがワイヤーフレームやよくできたモックアップを突然作ってしまうのは、あまりに早い段階で詳細を定義している
デザイナーが創造性を発揮できる余地がなくなっちゃう
設計のオーバースペック化は見積もりのミスに繋がる
インタフェースを作ると複雑さや実装の詳細が隠れている場合があって、それを後々解決しないといけなくなる。
スコープが可変ならまだましだが・・・。
Words are too abstract: 文書は抽象的すぎ
プロジェクトの定義が数語で書いてあってもなんなのかわからない。
「カレンダービューを構築する」
「グループ通知を追加する」
なんか言ってるようだけど、実際何をすりゃいいの?
トレードオフを決めるのに重要な情報がない。何をやればいいのか、何は除いてもいいのかわからない よく定義されていないプロジェクトは境界線がないので、仕様が足りないプロジェクトってのは手に負えなくなる
Case study: The Dot Grid Calendar: ケーススタディ: ドットグリッドカレンダー
Basecamp3はカレンダー機能が最初なかった。「スケジュール」はあったけどただイベントが並ぶだけ
顧客「カレンダーを追加してほしい」
昔にカレンダーを作ったことがあって、めちゃめちゃ大変だった。半年くらいはかかる
なぜ複雑か?
セルの間でイベントをD&Dして移動できる
複数日のイベントを画面の端と端でwrapingしないといけない
月・週・日でタイムスケールの違う表示
・・・
昔カレンダー機能を作ったけど10%しか使っていなかった
6weekの1サイクルで何か満足いくものが作れるなら、やりたい。
6週間の作業では1/10くらいしか作れないので、どうやってそれを作るか?を考えた
色々調査した
解決したいユースケースを絞り込んだ
携帯のカレンダーに似たコンセプトにたどり着いた。二ヶ月間、読み取り専用のグリッドビューが作れる
イベントのある日はドットがあって、ドットをクリックしたらスクロールして表示
Dot Gridと読んでいた
Dot Gridのラフスケッチ
https://gyazo.com/2535f88f98a91c7bfdc0d87d450a6900
できたもの
https://gyazo.com/431c4f8b43e51e4ca1989d66d5a275ce
Property 1: It's rough: 大雑把である
Shaping中の作業は大雑把。誰が見ても未完成だとわかる。
自分たちの貢献はどこへ向ければいいのか、余白がわかる。細かすぎる仕事・早すぎる仕事は誰もが間違った詳細にコミットしてしまう。
Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge.
デザイナーとプログラマーは自分たちの判断や専門知識を適応する余白が必要
Property 2: It's solved: 解決されている
荒削りで未完成にも関わらず、Shaped workは考え抜かれている。マクロレベルでは全ての主要な要素が存在していて、それぞれが繋がっている。
仕事は個々のタスクには分割されていないけど、全体的な解決策は提示されている。
想定外のことは起きるかもしれないけど、どうすればいいかの方向性は示されている。
リスクを減らすために、未解決の疑問点などは取り除かれている。
Property 3: It's bounded: 境界がある
Shaped workは何をしてはいけないかが明確。チームがどこでやめるべきかを示している。
チームが作業できる時間は決まっている。決まった時間でプロジェクトを終了させるには、スコープを限定したり、いらないものは省かないといけない
the roughness leaves room for the team to resolve all the details, while the solution and boundaries act like guard rails
荒さは全ての残りの詳細をチームが解決する余地を残し、解決策と境界がガードレールみたいな役割を果たす
チームは多く作りすぎたり、さまよったり、行き詰まったりすることがないようにする
Who shapes: 誰がShapeするのか
Shapeingは創造的で総合的なもの。
インタフェースアイディア
技術的な可能性
プログラマーである必要はない
何が可能で、何が難しいのかは判断できる必要がある
ビジネスのプライオリティ
主にデザインの仕事。ユーザーの視点から見たインタラクションデザイン
Featureが何をするのか?どう動くのか?既存のフローのどこに収まるのか?
戦略的な仕事
欲求を設定し、解決策を考えるには問題に対して批判的になる必要がある。
何を解決しようとしているのか?なぜ重要なのか?何が成功になるのか?影響を受ける顧客は誰なのか?なぜこれをやる必要があるのか?
Shapingは閉鎖的で創造的なプロセス。
誰かに聞いてみたり、1人でスケッチしたり、率直に話して。。。
いろんなポジションからアプローチする、プライベートでラフな仕事
: 2つのトラック
Shapingの仕事をスケジュールに入れることはできない。あまりにリスキーで不明すぎる。なので、2つのトラックを用意する。
6週間のサイクルの中で、チームはShaped workをBuildし、Shaperは次のサイクルでBuildする可能性のあるワークに取り組む。
Shaping trackでは、Betすることが決まるまでは非公開にされる。チームには共有されない
WIPのものを休めたり、うまくいかなきゃ捨てたりできる
Steps to shaping: Shapingの手順
1: 輪郭を決める。
アイディアにどれくらいの時間をかける価値があるのか、どうやって課題を定義するのかを把握する。Shapeするための基本的な輪郭になる
2: 要素を書き上げる
解決策をスケッチするタイミング。ワイヤーフレームよりも抽象的なレベルでスケッチする。シュッと方向転換したり探索できるような、余白をしっかり残すことを意識する
欲求を解決するものではあるけど、細かいディティールは解決しない
3: リスクに対処する
チームが行き詰まったり時間を無駄にしたりするのを防ぐ。
4: ピッチを書く
Buildするだけの形になったと思ったら、解決策、制約、落とし穴、限界を要約する。ピッチが通ったらこれを使ってチームに説明して、チームが作る