Middle Out Design
Download as PPT, PDF2 likes1,102 views
The document outlines the process of middle-out design as proposed by Audrey Crane from Dubberly Design Office, focusing on design methods and team collaboration in developing a medical order-entry system. It emphasizes the roles of various team members, the importance of iterative research, prototyping, and user testing, as well as handling software design issues and prioritization of tasks. Additionally, it discusses using a systematic approach to address design bugs and the need for clear documentation throughout the design process.
![Thank You. Audrey Crane [email_address] Dubberly Design Office Thumb twiddling images from artwork by Naomi Roberston.](https://image.slidesharecdn.com/presov9-1233266003145524-2/85/Middle-Out-Design-235-320.jpg)
Middle Out Design
- 2. Audrey Crane
- 3. Dubberly Design Office (DDO)
- 11. issues =
- 12. HandScript
- 14. product
- 16. physicians
- 17. hospital
- 18. writing
- 19. problems
- 20. hand-held device with WiFi
- 22. “ IVF to 100cc/hr ”
- 23. “ Reglan 10mg po 30 min qac TID”
- 24. client team
- 26. Kevin, engineering manager Eliot, voice interaction designer
- 27. Kevin, engineering manager Eliot, voice interaction designer Claire, “front end” engineer
- 28. Kevin, engineering manager Eliot, voice interaction designer Claire, “front end” engineer Howard, local doctor
- 29. Kevin, engineering manager Eliot, voice interaction designer Claire, “front end” engineer Howard, local doctor Dr. Famous, content expert
- 30. us him
- 31. David CTO Kevin, engineering manager Eliot, voice interaction designer Claire, “front end” engineer Howard, local doctor Dr. Famous, content expert David, CTO
- 32. 5 + 3 Kevin, engineering manager Eliot, voice interaction designer Claire, “front end” engineer Howard, local doctor Dr. Famous, content expert David, CTO
- 33. Kevin, engineering manager Eliot, voice interaction designer Claire, “front end” engineer Howard, local doctor Dr. Famous, content expert Audrey, design & project manager
- 34. Kevin, engineering manager Eliot, voice interaction designer Claire, “front end” engineer Howard, local doctor Dr. Famous, content expert Audrey, design & project manager Greg, interaction designer
- 35. Kevin, engineering manager Eliot, voice interaction designer Claire, “front end” engineer Howard, local doctor Dr. Famous, content expert Audrey, design & project manager Greg, interaction designer Hugh, principal
- 38. (so that has some implications)
- 39. privately funded
- 40. $ $ $ $ $ $
- 41. alpha (1 year old, some content)
- 42. 1 year to go
- 43. (1 year late)
- 45. “just a little help”
- 48. Claire, “front end” engineer Gino, designer ex-
- 49. frustrated
- 50. content entry tool ~ product UI
- 51. Dr. Famous content expert information architect Dr. Famous, content expert information architect
- 52. (designer) Dr. Famous, content expert information architect
- 53. Dr. Famous doesn’t need any stinkin’ designers
- 54. Dr. Famous, content expert information architect
- 56. getting started
- 57. first meeting
- 58. Santa Cruz
- 60. mostly Working At Home “WAH”
- 61. (so that has some implications)
- 62. no receptionist
- 64. lights off
- 66. ?
- 68. “What is an order?”
- 69. “NPO until procedure, then…
- 70. “…ice chips for 1 hour, then…”
- 71. “… full liquid diet until patient requests food, then…”
- 72. “…regular diet.”
- 73. “…regular diet. Low sodium.”
- 74. 1? 2? 5?
- 75. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
- 76. domain =
- 78. competition =
- 80. work =
- 82. product =
- 83. finite
- 84. DDO engagement =
- 86. DDO process
- 87. 1. Research 2. Model 3. Prototype 4. Test 5. Specify
- 88. 1. Research 2. Model 3. Prototype 4. Test 5. Specify - studies
- 89. 1. Research 2. Model 3. Prototype 4. Test 5. Specify - studies - reviews
- 90. 1. Research 2. Model 3. Prototype 4. Test 5. Specify - studies - reviews - analysis
- 91. 1. Research 2. Model 3. Prototype 4. Test 5. Specify - studies - reviews - analysis - synthesis
- 92. 1. Research 2. Model 3. Prototype 4. Test 5. Specify - studies - reviews - analysis - synthesis maps
- 93. 1. Research 2. Model 3. Prototype 4. Test 5. Specify - studies - reviews - analysis - synthesis maps wireframes
- 94. 1. Research 2. Model 3. Prototype 4. Test 5. Specify - studies - reviews - analysis - synthesis maps wireframes - comps
- 95. 1. Research 2. Model 3. Prototype 4. Test 5. Specify - studies - reviews - analysis - synthesis maps wireframes - comps - studies
- 96. 1. Research 2. Model 3. Prototype 4. Test 5. Specify - studies - reviews - analysis - synthesis maps wireframes - comps - studies - detail
- 97. 1. Research 2. Model 3. Prototype 4. Test 5. Specify - studies - reviews - analysis - synthesis maps wireframes - comps - studies - detail - document
- 98. 1. Research 2. Model 3. Prototype 4. Test 5. Specify 1. Analyze 2. Define 3. Ideate 4. Select 5. Implement 1. Define 2. Measure 3. Analyze 4. Design 5. Verify 1. Plan 2. Learn 3. Specify 4. Produce 5. Evaluate - studies - reviews - analysis - synthesis maps wireframes - comps - studies - detail - document
- 100. research or analysis
- 101. Work already!
- 102. 9 engineers sitting
- 104. …or worse!
- 105. What to do?
- 106. 1. Research 2. Model 3. Prototype 4. Test 5. Specify - studies - reviews - analysis - synthesis maps wireframes - comps - studies - detail - document
- 107. 3 participant user testing?
- 108. 1 week for modeling?
- 110. ?
- 111. 1. Research 2. Model 3. Prototype 4. Test 5. Specify - studies - reviews - analysis - synthesis maps wireframes - comps - studies - detail - document
- 113. OR
- 114. 1. Research 2. Model 3. Prototype 4. Test 5. Specify
- 117. “Um…sure.”
- 119. Admit/Xfr/Dschg Diet Regular diet as tol. Soft diet Full liquid diet Clear liquid diet NPO More Consistencies Mechanical Soft Diet Pureed Diet Sips of Water Ice chps Common / Diabetic Diets More Modified Diets Low / High / Amount Per Day Food Allergy Restricted Fluid Restriction Disease / Condition Special Advance as tol. Advance as tol. to… Regular diet as tol. Soft diet Mechanical soft diet
- 120. “What if the handheld is lost?”
- 121. “ Er…Log out after 30 seconds.”
- 124. ?
- 125. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
- 126. 1. Research 2. Model 3. Prototype 4. Test 5. Specify
- 127. 1. Research 2. Model 3. Prototype 4. Test 5. Specify
- 128. 1. Research 2. Model 3. Prototype 4. Test 5. Specify
- 129. what we did
- 130. wrote down questions questions
- 131. ? ?
- 132. ? ? ? ?
- 133. ? ? ? ? ? ? ? ? ? ?
- 134. ? ? ? ? ? ? ? ? ? ? ? ? ? ?
- 135. wrote down questions ? ? ? ? ? ? ? ? ? ?
- 136. prioritized ?
- 137. SQA tangent
- 140. Bug:
- 141. Bug: 1. Summary
- 142. Bug: 1. Summary 2. Description
- 143. Bug: 1. Summary 2. Description 3. Owner
- 144. Bug: 1. Summary 2. Description 3. Owner 4. Status (open, working, closed)
- 145. Bug: 1. Summary 2. Description 3. Owner 4. Status (open, working, )
- 146. Bug: 1. Summary 2. Description 3. Owner 4. Status (open, working, ) 5. (Severity)
- 147. Bug: 1. Summary 2. Description 3. Owner 4. Status (open, working, ) 5. (Severity) 6. Priority
- 148. P1 P2 P3 P4 P5
- 149. P1 P2 P3 P4 P5
- 150. (or whatever)
- 151. P3?? P4!!
- 152. P1 (p e wun) adj.
- 153. P1 - crash, data loss
- 154. (or whatever)
- 155. = issues
- 157. Design Issue Priority Definitions
- 158. Design Issue Priority Definitions P1: Global or core issue that prevents a significant number of other issues from being resolved.
- 159. Design Issue Priority Definitions P1: P2: Global or core issue that prevents a significant number of other issues from being resolved. Prevents some issues from being resolved, but not a large number.
- 160. Design Issue Priority Definitions P1: P2: P3: Global or core issue that prevents a significant number of other issues from being resolved. Prevents some issues from being resolved, but not a large number. Isolated issue, must be resolved but does not prevent other work.
- 161. Design Issue Priority Definitions P1: P2: P3: P4: Global or core issue that prevents a significant number of other issues from being resolved. Prevents some issues from being resolved, but not a large number. Isolated issue, must be resolved but does not prevent other work. Detail, does not prevent other work.
- 162. Design Issue Priority Definitions P1: P2: P3: P4: P5: Global or core issue that prevents a significant number of other issues from being resolved. Prevents some issues from being resolved, but not a large number. Isolated issue, must be resolved but does not prevent other work. Detail, does not prevent other work. Detail, resolution not required for beta.
- 163. An issue is resolved when…
- 164. ?
- 165. When are agreed that we have a good fix.
- 166. good?
- 167. ?
- 168. my good = your good?
- 169. Ha.
- 170. good (g ü d) adj. bet·ter, best 1. Being positive or desirable in nature; not bad or poor
- 171. (whole other talk)
- 172. team “good”= team “good”
- 173. Good :
- 174. Good: 1. Efficient, meaning… a. intuitive b. fast (application) c. quick access to information
- 175. Good: 1. Efficient, meaning… a. intuitive b. fast (application) c. quick access to information 2. Meets expectations; consistent, no surprises.
- 176. Good: 1. Efficient, meaning… a. intuitive b. fast (application) c. quick access to information 2. Meets expectations; consistent, no surprises. 3. Keeps users from getting lost.
- 177. Good: 1. Efficient, meaning… a. intuitive b. fast (application) c. quick access to information 2. Meets expectations; consistent, no surprises. 3. Keeps users from getting lost. 4. Minimal barriers and constraints.
- 178. consistency class
- 179. ANYWAY
- 180. Go!
- 181. tools
- 183. Design Issue Priority Definitions P1: P2: P3: P4: P5: Global or core issue that prevents a significant number of other issues from being resolved. Prevents some issues from being resolved, but not a large number. Isolated issue, must be resolved but does not prevent other work. Detail, does not prevent other work. Detail, resolution not required for beta.
- 184. Good: 1. Efficient, meaning… a. intuitive b. fast (application) c. quick access to information 2. Meets expectations; consistent, no surprises. 3. Keeps users from getting lost. 4. Minimal barriers and constraints.
- 185. document decisions
- 186. Log out when inactive. Let inactivity period be set by user in preferences.
- 188. systems?
- 189. Page Type and Widget Libraries
- 191. Widget Library: 1. default appearance 2. appropriate use case 3. behavior
- 192. 5 purposes
- 193. 1. Documentation
- 194. 2. Good work
- 195. 3. Surface issues
- 196. 4. Basic toolkit
- 197. 5. Final deliverable
- 198. ongoing process
- 199. met weekly
- 200. ? ? ? ? ? ? ? ? ? ?
- 201. ? ? ? ? ? ? ? ? ? ?
- 202. ? ? ? ? ? ? ? ? ? ? ?
- 203. ? ? ? ? ? ? ? ? ? ? ?
- 206. 72 issues
- 207. 48 closed
- 208. P1s and P2s closed
- 209. 15 P5s
- 210. 10 open P3 or P4 issues
- 215. what this means
- 216. interesting (?)
- 217. not unique
- 218. “clean slates” are rare
- 219. $
- 220. never enough time
- 221. all projects have “design bugs”
- 222. middle
- 223. or beginning
- 224. the main points
- 225. bugs : software development :: issues : design process
- 226. Middle-Out Design: 1. priority definitions 2. “good” definition 3. tracking issues 4. assigning priorities 5. important things first 6. document solutions
- 227. <boss’ slides>
- 229. design rationale
- 230. Horst Rittel
- 231. IBIS
- 232. design = argument
- 233. </ boss’ slides>
- 234. Try it!
- 235. Thank You. Audrey Crane [email_address] Dubberly Design Office Thumb twiddling images from artwork by Naomi Roberston.