SlideShare ist ein Scribd-Unternehmen logo
1 von 24
Downloaden Sie, um offline zu lesen
AGILE AND ME  a story with just enough documentation
A typical waterfall project produces pages and page of end-to-end requirements for the entire project as it is envisioned (but not necessarily as it will be built). The people compiling these requirements are, of course, part of an assembly with only the most cursory involvement with others outside their department.
After all 9,238 lbs. of paper are heaved over the wall with a hearty “good luck!” and a cheery wave, the silos are once again in place and silence is golden.
? While agile was taking hold of development, design was still back in the waterfall method. So why not blend the two and run the entire project in an agile fashion, starting with requirements.
AGILE DESIGN  in theory
Individuals with Overlapping Skills Agile teams are self-organizing and highlight TRANSLATING AGILE METHODS TO DESIGN
T ,[object Object],Shaped Being OVERLAPPING SKILLS = T-SHAPED PEOPLE
UxD in an agile world ,[object Object],[object Object],[object Object],[object Object],[object Object]
UxD in an agile world ,[object Object],[object Object],[object Object],[object Object],[object Object]
AGILE DESIGN  in practice
insert uxd at the beginning ,[object Object],[object Object],[object Object],[object Object],[object Object]
DIAGRAMs THAT DEVELOPERS UNDERSTAND ,[object Object]
tasks TO USER STORIES ,[object Object],[object Object],[object Object],[object Object],[object Object],Expand your activity diagram to show subtasks and begin associating user stories with the persona.
from Personas to development ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
DESIGNING A FEATURE just enough documentation
Iteration 0 ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Feature a - stories & tests User stories state the feature’s user needs and the business benefits. Acceptance tests, which are written as scenarios and based off the user stories, define when a feature is complete. If a scenario is not defined, it is not a part of the feature that’s being developed for this iteration.
Feature a - Workflow diagram Workflows diagram the end-to-end flow for the feature. If a section of the flow is out of scope for the current iteration or for this feature but needs to be in the flow for clarity, include it in the diagram but note that it’s out of scope for this iteration.
feature a - ANNOTATED WIREFRAMES Annotations note behavior of various elements on the page.
feature a - functional specs Functional specs describe how a feature will work and are written entirely from the user’s perspective. Functional specs only describe the work for that iteration
AGILE DESIGN in summary
UxD in an agile world means: ,[object Object],[object Object],[object Object],[object Object],[object Object]
Agile UXD : Your sandbox just got a whole lot bigger
ALICE TOTH senior consultant, uxd [email_address]

Weitere ähnliche Inhalte

Ähnlich wie Agile Design - Chicago IXDA Presentation

Technical-design-for-Angular-apps.pdf
Technical-design-for-Angular-apps.pdfTechnical-design-for-Angular-apps.pdf
Technical-design-for-Angular-apps.pdfSakthivelPeriyasamy6
 
Coach as Facilitator   Please respond to the followingWatch the.docx
Coach as Facilitator   Please respond to the followingWatch the.docxCoach as Facilitator   Please respond to the followingWatch the.docx
Coach as Facilitator   Please respond to the followingWatch the.docxbrownliecarmella
 
Product and UX - are the roles blurring?
Product and UX - are the roles blurring?Product and UX - are the roles blurring?
Product and UX - are the roles blurring?Jesse Gant
 
Architecting for Change: An Agile Approach
Architecting for Change: An Agile ApproachArchitecting for Change: An Agile Approach
Architecting for Change: An Agile ApproachBen Stopford
 
Agile methodology
Agile methodologyAgile methodology
Agile methodologyTyler Rose
 
Introduction to UX for Mesiniaga Academy
Introduction to UX for Mesiniaga AcademyIntroduction to UX for Mesiniaga Academy
Introduction to UX for Mesiniaga AcademyZainul Zain
 
DAS Slides: Data Architect vs. Data Engineer vs. Data Modeler
DAS Slides: Data Architect vs. Data Engineer vs. Data ModelerDAS Slides: Data Architect vs. Data Engineer vs. Data Modeler
DAS Slides: Data Architect vs. Data Engineer vs. Data ModelerDATAVERSITY
 
The Agile Drupalist - Methodologies & Techniques for Running Effective Drupal...
The Agile Drupalist - Methodologies & Techniques for Running Effective Drupal...The Agile Drupalist - Methodologies & Techniques for Running Effective Drupal...
The Agile Drupalist - Methodologies & Techniques for Running Effective Drupal...Adrian Jones
 
Cross-functional team collaboration between Agile development and UX design
Cross-functional team collaboration between Agile development and UX designCross-functional team collaboration between Agile development and UX design
Cross-functional team collaboration between Agile development and UX designDug Falby
 
The Product Sketch - Writing Delightfully Effective User Stories
The Product Sketch - Writing Delightfully Effective User StoriesThe Product Sketch - Writing Delightfully Effective User Stories
The Product Sketch - Writing Delightfully Effective User StoriesThe Product Sketch
 
Effective User Story Writing
Effective User Story WritingEffective User Story Writing
Effective User Story WritingAhmed Misbah
 
Proteus - android layout engine
Proteus - android layout engineProteus - android layout engine
Proteus - android layout engineKiran Kumar
 
AtlasCamp 2013: ADG / Lean UX
AtlasCamp 2013: ADG / Lean UXAtlasCamp 2013: ADG / Lean UX
AtlasCamp 2013: ADG / Lean UXcolleenfry
 
Evolving your api architecture with the strangler pattern
Evolving your api architecture with the strangler patternEvolving your api architecture with the strangler pattern
Evolving your api architecture with the strangler patterndwcarter74
 
Design Software Driven by Domain
Design Software Driven by DomainDesign Software Driven by Domain
Design Software Driven by Domainssuser1a0b8f
 
Crystal Reports Review
Crystal Reports ReviewCrystal Reports Review
Crystal Reports ReviewJustin R. Rue
 
System performance en-2
System performance en-2System performance en-2
System performance en-2Michael Klein
 

Ähnlich wie Agile Design - Chicago IXDA Presentation (20)

Technical-design-for-Angular-apps.pdf
Technical-design-for-Angular-apps.pdfTechnical-design-for-Angular-apps.pdf
Technical-design-for-Angular-apps.pdf
 
Coach as Facilitator   Please respond to the followingWatch the.docx
Coach as Facilitator   Please respond to the followingWatch the.docxCoach as Facilitator   Please respond to the followingWatch the.docx
Coach as Facilitator   Please respond to the followingWatch the.docx
 
Product and UX - are the roles blurring?
Product and UX - are the roles blurring?Product and UX - are the roles blurring?
Product and UX - are the roles blurring?
 
Architecting for Change: An Agile Approach
Architecting for Change: An Agile ApproachArchitecting for Change: An Agile Approach
Architecting for Change: An Agile Approach
 
React Workshop
React WorkshopReact Workshop
React Workshop
 
Business Analyst
Business AnalystBusiness Analyst
Business Analyst
 
Agile methodology
Agile methodologyAgile methodology
Agile methodology
 
Introduction to UX for Mesiniaga Academy
Introduction to UX for Mesiniaga AcademyIntroduction to UX for Mesiniaga Academy
Introduction to UX for Mesiniaga Academy
 
DAS Slides: Data Architect vs. Data Engineer vs. Data Modeler
DAS Slides: Data Architect vs. Data Engineer vs. Data ModelerDAS Slides: Data Architect vs. Data Engineer vs. Data Modeler
DAS Slides: Data Architect vs. Data Engineer vs. Data Modeler
 
The Agile Drupalist - Methodologies & Techniques for Running Effective Drupal...
The Agile Drupalist - Methodologies & Techniques for Running Effective Drupal...The Agile Drupalist - Methodologies & Techniques for Running Effective Drupal...
The Agile Drupalist - Methodologies & Techniques for Running Effective Drupal...
 
Cross-functional team collaboration between Agile development and UX design
Cross-functional team collaboration between Agile development and UX designCross-functional team collaboration between Agile development and UX design
Cross-functional team collaboration between Agile development and UX design
 
The Product Sketch - Writing Delightfully Effective User Stories
The Product Sketch - Writing Delightfully Effective User StoriesThe Product Sketch - Writing Delightfully Effective User Stories
The Product Sketch - Writing Delightfully Effective User Stories
 
Effective User Story Writing
Effective User Story WritingEffective User Story Writing
Effective User Story Writing
 
Proteus - android layout engine
Proteus - android layout engineProteus - android layout engine
Proteus - android layout engine
 
AtlasCamp 2013: ADG / Lean UX
AtlasCamp 2013: ADG / Lean UXAtlasCamp 2013: ADG / Lean UX
AtlasCamp 2013: ADG / Lean UX
 
Evolving your api architecture with the strangler pattern
Evolving your api architecture with the strangler patternEvolving your api architecture with the strangler pattern
Evolving your api architecture with the strangler pattern
 
Design Software Driven by Domain
Design Software Driven by DomainDesign Software Driven by Domain
Design Software Driven by Domain
 
Crystal Reports Review
Crystal Reports ReviewCrystal Reports Review
Crystal Reports Review
 
System performance en-2
System performance en-2System performance en-2
System performance en-2
 
IIBA Multimodels
IIBA MultimodelsIIBA Multimodels
IIBA Multimodels
 

Agile Design - Chicago IXDA Presentation

  • 1. AGILE AND ME a story with just enough documentation
  • 2. A typical waterfall project produces pages and page of end-to-end requirements for the entire project as it is envisioned (but not necessarily as it will be built). The people compiling these requirements are, of course, part of an assembly with only the most cursory involvement with others outside their department.
  • 3. After all 9,238 lbs. of paper are heaved over the wall with a hearty “good luck!” and a cheery wave, the silos are once again in place and silence is golden.
  • 4. ? While agile was taking hold of development, design was still back in the waterfall method. So why not blend the two and run the entire project in an agile fashion, starting with requirements.
  • 5. AGILE DESIGN in theory
  • 6. Individuals with Overlapping Skills Agile teams are self-organizing and highlight TRANSLATING AGILE METHODS TO DESIGN
  • 7.
  • 8.
  • 9.
  • 10. AGILE DESIGN in practice
  • 11.
  • 12.
  • 13.
  • 14.
  • 15. DESIGNING A FEATURE just enough documentation
  • 16.
  • 17. Feature a - stories & tests User stories state the feature’s user needs and the business benefits. Acceptance tests, which are written as scenarios and based off the user stories, define when a feature is complete. If a scenario is not defined, it is not a part of the feature that’s being developed for this iteration.
  • 18. Feature a - Workflow diagram Workflows diagram the end-to-end flow for the feature. If a section of the flow is out of scope for the current iteration or for this feature but needs to be in the flow for clarity, include it in the diagram but note that it’s out of scope for this iteration.
  • 19. feature a - ANNOTATED WIREFRAMES Annotations note behavior of various elements on the page.
  • 20. feature a - functional specs Functional specs describe how a feature will work and are written entirely from the user’s perspective. Functional specs only describe the work for that iteration
  • 21. AGILE DESIGN in summary
  • 22.
  • 23. Agile UXD : Your sandbox just got a whole lot bigger
  • 24. ALICE TOTH senior consultant, uxd [email_address]

Hinweis der Redaktion

  1. A typical waterfall project produces page after page documenting the end-to-end requirements for the entire project -- not for the phase or for the iteration but for the entire project. All of this work, of course, is done in a silo with only the most cursory involvement with development.
  2. Once all 9,238 lbs. are heaved over the wall at the handoff meeting with a cheery “good luck!”, the silos are once again inhabited and silence is golden.
  3. Whether the application is being implemented as designed is the big mystery until the final unveiling n months later. Unless you are one of those fortunate designers who’s embedded in a development team and is, therefore, accessible for questions. But those types were rare.
  4. While agile was taking hold of development, design was still stuck in the waterfall method. So why not blend the two and run the entire project in an agile fashion, starting with requirements.
  5. A great idea, I thought. But first I need to look into exactly what is it about Agile teams that makes them tick. And how can that translate to design.
  6. Well, the individuals with overlapping skills idea ties in with Tim Brown’s T-shaped people. Actually, it suits it to a “T” (ahem). And designers, like developers, are rarely one-dimensional and like flexing their creative muscles.
  7. So, blending Agile and UxD means we’re still using the same tools (task flows, wireframes, etc.) but we’re no longer separated from other team members and we’re designing as we go along. Sounds like a plan!
  8. The upside is that we now have a larger role in the overall project -- the rigid assembly line definition of requirement > designer > dev is losing it’s rigidity. The downside, if you can even call it that, is that as a designer you have to live with levels of uncertainty because you’re designing as the project progresses and sometimes there will be unknowns that will remain unknowns.
  9. Theory’s great but let’s get practical here.
  10. At Pathfinder, we do user driven software development which means the users’ needs and requirements define the features needed for the application. So much more accurate than throwing darts on a board or gazing into a crystal ball.
  11. User research yields user modeling; user modeling, in turn, informs data modeling. But it’s of no use if the research is ignored by the developers. Integrating design into the entire SDLC meant creating meaningful documentation. I’ve had very good luck diagramming personas in a UML style, which is a language most developers are comfortable with.
  12. And a tenet of Agile is user stories. I take the high-level needs of the personas and begin to diagram out the tasks. I also start to write the user stories for each tasks -- again, at a high level but at this point in the project, that’s all that is needed in order to get an idea of the overall scope of the project.
  13. Our high-level user stories generate the Feature List. Now we can start scoping the project and determining what needs to be built and when it can be built -- iteration planning. Once that is accomplished, we start writing requirements, but only for the features slated for development in the upcoming iteration.
  14. A feature, in our world, is something that can be developed in one iteration, regardless of how your team defines the length of an iteration. A feature page explains the design of that feature.
  15. Each feature page has the above listed sections -- examples follow.
  16. Our user stories state the user needs and the business benefit from meeting that need. Acceptance tests, which are written as scenarios and based off the user stories, define when a feature is complete, i.e., when all the defined scenarios are met. If a scenario is not defined, it is not a part of the feature that’s being developed for this iteration.
  17. User workflows should diagram the end-to-end flow for the feature. Sometimes a workflow can only be drawn with other features in the flow. If that’s the case, those areas need to be denoted as not being in this feature, to be developed later, etc. Some sort of indication that it’s in the flow to be helpful but not to be developed at this time.
  18. The wireframe shows the screen layout and the annotations note the various widget behaviors.
  19. Functional specifications describe how a feature will work and are written entirely from the user’s perspective.
  20. The last line is the most important benefit in my book. Instead of being shuttled off to the side or having only a brief involvement, designers are now an integral part of the team throughout the entire life of the project.
  21. Once you get out of the silo, you realize you have much more room to play.