Docstoc

Manual for Developing Web Applications

Document Sample
Manual for Developing Web Applications Powered By Docstoc
					 1

Red Shoes Consulting’s
Manual for Developing Web Applications:

Five Techniques for Making Methodology Deliver
2   Agenda


    1. CHALLENGES OF WEB APPLICATIONS
      Today’s complex work requires tweaking our methodologies


    2. REAL-WORLD TECHNIQUES
      Five techniques for making methodology deliver


    3. Q&A
      Questions and comments
3



    CHALLENGES OF WEB APPLICATIONS
4 Web applications have required us to tweak
  our methodologies

                                  The Web Today:
    The Early Web:                   A platform
                      Evolution     for business
    Mostly content
                                      process
                                     execution
5 Challenge: Methodologies need to work in a
  new environment
  We have more accountability to high-level stakeholders, greater need
  to communicate
  Our designs are now linked to business strategy
  We work with a more complex team make-up and structure
  Implementations tied to more technology
  Need our IA methods to gel with software development methods
6 Challenge: Methodologies need to work for
  large, domain-specific task-based products
  Highly task-based solutions, with tasks specific to domain workers
  Less browsing, more desire for efficiency gains
  Applying design to (similar to BPM) domain-specific workflows
           Healthcare records management
           Statistical research
           Engineering processes
  Need to address a wide range of domain-specific task-level
  functionality
7 We found it necessary to…


  Adjust our tools
  Add some new ones
  Refine our processes
  Rethink the importance and value of communication
  Ultimately, tweak our methodologies with some new techniques
8



    We’d like to share 5 methodology techniques
    that have helped us deliver web applications
9



    REAL-WORLD TECHNIQUES
10   Technique 1: Define and “Template-ize” Your
     Methodology

     Why?
     Need to gel with other methods
     Need IA in the appropriate places in the project plan
     May have to explain steps to new audiences
     Want smooth hand-offs
     Add value without delay
11   Technique 1: Define and “Template-ize” Your
     Methodology

     First Define the Approach


     Then Template-ize the Tools
12   Technique 1: Define




     Define the phases
13   Technique 1: Define




      Activities     Activities     Activities     Activities     Activities     Activities




     Deliverables   Deliverables   Deliverables   Deliverables   Deliverables   Deliverables




     Add activities and deliverables on a grid
     (great for planning)
14   Technique 1: Define




     Add activities and deliverables on a grid
     (great for planning)
15   Technique 1: Template-ize
16   Technique 1: Template-ize

     Project kick-off template
17   Technique 1: Template-ize

     User research template
18   Technique 1: Template-ize

     Persona template
19   Technique 1: Template-ize

     Task flow template
20   Technique 1: Template-ize

     Wireframe template
21   Technique 1: Template-ize

     Documentation can be easily put together
22   Technique 1: Template-ize

     Reference for future planning
23   Technique 1: Template-ize
24   Technique 1: Template-ize
25   Technique 1: Template-ize
26   Technique 1: Define and Template-ize


     Benefits:

     You can show, rather than tell, what you are planning to do
     You can hit the ground running
     Ease the burden and improve quality of documentation
     Communicate with team members and stakeholders visually
     Discuss trade-offs in advance
     Gain consensus in advance
27 Technique 2: Visualize Requirements


   Why?


   Prioritization of requirements may not include the user’s perspective
   Get the big picture communicated to everyone
   Good way to discover missing personas and requirements early
28   Technique 2: Visualize Requirements

        Pure Text Requirements   Visual Requirements




          Can be uncertain       Puts everyone on
                                  the same page
29 Technique 2: Visualize Requirements

   Get to Know the users…
30 Technique 2: Visualize Requirements

   Show the work environment…
31 Technique 2: Visualize Requirements

   Show their process flow….
32 Technique 2: Visualize Requirements

   Show their process flow….
33 Technique 2: Visualize Requirements

   Show their process flow….
34 Technique 2: Visualize Requirements

   Relate users to usage, frequency
35   Technique 2: Visualize Requirements
     Map requirements to users, prioritize
36 Technique 2: Visualize Requirements

   Benefits:


   Pictures can help explain physical complexity of workspaces
   Pictures help facilitate dialog
   Look at requirement’s from a user’s perspective
   Mechanism to involve all team members in prioritization and vetting of
   requirements
37   Technique 3: Think flow, then features

     Why?


     Web applications usually have a heavy process re-engineering
     component
     Engages BA, team to look at use cases as a whole, how one impacts
     the others
     Understand the impact of individual features on the intuitiveness of the
     design as a whole
     Resolve disagreements about how the application should work
38   Technique 3: Think flow, then features
39   Technique 3: Think flow, then features
40   Technique 3: Think flow, then features

     Create micro task flow - “the app on a page”
41   Technique 3: Think flow, then features

     Create micro task flow
42   Technique 3: Think flow, then features

     Benefits:


     Flow not left as an afterthought, features are discussed in context
     Provide developers, BA’s with an experience of the application
     Mechanism for iteration; flow is seldom obvious
43   Technique 4: Move the Project with Rapid
     Prototypes
     Why?


     Avoid conflicting visions among stakeholders, team members
     Make the best use of meeting time
     Provide a way to drive timely decision making
     Get scope defined where there is uncertainty
44 Technique 4: Move the Project with Rapid
   Prototypes

   You’ll actually save time the more quickly you can
   create a productive, engaging dialog usig something
   tangible
45   Technique 4: Move the Project with Rapid
     Prototypes

     Meetings can benefit from showing alternative
     prototypes
46   Technique 4: Move the Project with Rapid
     Prototypes
47   Technique 4: Move the Project with Rapid
     Prototypes
48   Technique 4: Move the Project with Rapid
     Prototypes
49   Technique 4: Move the Project with Rapid
     Prototypes
50   Technique 4: Move the Project with Rapid
     Prototypes
51   Technique 4: Move the Project with Rapid
     Prototypes
52   Technique 4: Move the Project with Rapid
     Prototypes
     Benefits:


     Prototype seeds discussions
     Prototype enables speed of decision making
     Less uncertainty as the design gets more detailed
     Able to involve more people early
     Can establish vision and then iterate the design details
53   Technique 5: Deliver blueprints to builders

     Why?


     Developers do not always interpret design correctly
     Design is not always communicated completely
     Avoid insufficient documentation of IA work
54   Technique 5: Deliver blueprints to builders

     Easier to change a visual “blueprint” than hard code
55   Technique 5: Deliver blueprints to builders

     Visual: Behavioral annotations for wireframes
56   Technique 5: Deliver blueprints to builders

     Visual: Errors and confirmations table
57   Technique 5: Deliver blueprints to builders

     Visual: Instructional text
58   Technique 5: Deliver blueprints to builders

     Visual: Style Guide
59   Technique 5: Deliver blueprints to builders


     Benefits:
     Deliver application code that is accurate to the design
     Have a mechanism for quality control
     Easier to communicate across the team
     Establishes a repeatable process the developers will appreciate
60   Summary


      We’ve gone from site to apps, the web as a
       platform for just about anything
      Complexity, more players, more functionality
       drove changes to methodology
      We suggest 5 techniques you can use
         Template-ize
         Visualize Requirements
         Think flow, not features
         Move the project with rapid prototypes
         Deliver blueprints to builders
                                   Product             Organizational

     Today’s Software
                                   Complexity          Complexity

61
     Organizational Complexity                  Domain
                                                Complexity




        Users                      Stakeholders




      Designers,        IA            Product
      Developers                    Competition


          Complexity necessitates methodology
62   Five Techniques to make methodology deliver
     1. Do a Methodology Walk-Through
        (key to planning)
     2. Step Everyone Into the User’s World
        (key to gelling with others)
     3. Discover the Flow
        (flow is seldom obvious)
     4. Dialog with Rapid Prototypes
        (key to speeding the process)
     5. Make Blueprints for Builders (key to
        successful implementation)