Loading ...
Sorry, an error occurred while loading the content.

Agile ux = zero or miminal upfront prototyping work?

Expand Messages
  • samfmsutton
    I m a designer based in a developer heavy web development company. We started moving towards agile over the last year or so. One argument I m facing at the
    Message 1 of 11 , Mar 24, 2010
    View Source
    • 0 Attachment
      I'm a designer based in a developer heavy web development company. We started moving towards agile over the last year or so.

      One argument I'm facing at the moment is that wireframes etc seem like bureaucracy that gets in the way of writing stories and implementing them.

      I can understand that, although I'm not strict about this, and we have had really useful, positive discussions about decisions when we had wireframes to guide us.

      But what do you think? Is it better just to write stories, put live code out there and test the results and then refine, or have you had positive benefits from using wireframes or just basic mockups to think about the functionality beforehand?

      -Sam
    • Gene Arch
      Hi Sam, I am in a similar situation. Our company has just adopted Agile over the past year or so, and I m struggling with the question of to prototype or not
      Message 2 of 11 , Mar 24, 2010
      View Source
      • 0 Attachment
        Agile ux = zero or miminal upfront prototyping work?

        Hi Sam,

        I am in a similar situation.  Our company has just adopted Agile over the past year or so, and I'm struggling with the question of "to prototype or not to prototype."  Currently, we do very little UX prototyping, though I see the benefit in doing so.  There have been a few projects I've been on where I basically forced time in there for wireframes of the interfaces, and it actually helped us foresee some difficult situations.  I think if you are doing spec reviews of the stories at the beginning of the sprint, maybe that's the time for (very) preliminary mockups?  I'm not sure.  I've also suggested to my scrum master the possibility of the UX people doing the prototyping work in a -1 sort of method (alongside the product owners writing specs for the stories - at least 1 sprint prior to when the stories are actually committed).  He hasn't responded on that yet.

        ~Gene

      • William Pietri
        ... I think there are three separate questions here: 1. What do you, as a designer, need to do personally to think through an interface? 2. What are the most
        Message 3 of 11 , Mar 24, 2010
        View Source
        • 0 Attachment
          On 03/24/2010 02:54 AM, samfmsutton wrote:
          I'm a designer based in a developer heavy web development company. We started moving towards agile over the last year or so. 
          
          One argument I'm facing at the moment is that wireframes etc seem like bureaucracy that gets in the way of writing stories and implementing them. 
          
          I can understand that, although I'm not strict about this, and we have had really useful, positive discussions about decisions when we had wireframes to guide us.
          
          But what do you think? Is it better just to write stories, put live code out there and test the results and then refine, or have you had positive benefits from using wireframes or just basic mockups to think about the functionality beforehand?   
            

          I think there are three separate questions here:

          1. What do you, as a designer, need to do personally to think through an interface?
          2. What are the most efficient ways for your team to meet and design things together?
          3. What's the most efficient way to get a good experience to users?

          I don't think there's a general-case answer to these: you're looking for the intersection of individual variation, team variation, and minimum waste. To me, the only way to find that is to be continually tinkering with your process, seeing how little you can get away with and still produce great work.


          So if I were in your shoes, there are some things I'd start discussions on:

          • Is everybody happy with the kind of products your team is turning out?
          • Does the team really iterate on things until they get to the right level of quality?
          • In what situations can some up-front thinking save your team time?
          • How can the team conduct experiments to settle questions like this?

          Really, this could go either way. I've seen teams waste a lot of time and money by going off half-cocked. I've also seen immense waste from too much design time and expensive design artifacts. Developers are prone to the former mistake; designers, the latter. It's only when you have a whole team working together that you can find the local optimum.

          William
        • Paul Spencer
          Hi Sam, We typical create mockups (wireframes) during Sprint 0. This helps us to understand the flow of the application and to iron out any issues ahead of
          Message 4 of 11 , Mar 24, 2010
          View Source
          • 0 Attachment
            Hi Sam,

            We typical create mockups (wireframes) during Sprint 0.  This helps us to understand the flow of the application and to iron out any issues ahead of time.  It is also an important part of designing a more usable system.  If you are looking at your application from a UX stand point the mockups are what you would use to test the usability of your design. Once a release has been made you can then test usability of the real system and create new mockups for the developers based on the feedback and results.  A good portion of our stories will have a mockup attachment as a point of reference for the developers.  We treat mockups as part of the iterative development cycle.  If we need to test the usability in an area or have new screens to think about then we create a mockup.

            Remember that you aren't interested in creating a mockup for every possible screen in the application in Sprint 0.  You are only looking to explore the high priority stories and to get an understanding of the basic flow of the system.  This should not evolve into a Big Design Up Front step.  It's something that will take practice and you will know when you are spending too much time on something.  Once you have a few screens and the basic idea of the system ready to go then the team should get started.

            From a developers perspective the mockups give them a good idea of what is expected and really helps them to get moving faster rather than designing or creating the page as they go.  If you already have the resources to create the mockups then I would suggest to go ahead and create them.  Agile promotes the idea of doing exactly what is needed and to not waste time on writing documentation that will never be used or kept up to date but I would not consider mockups to be useless documentation.

            Hope that helps.

            - Paul

            Paul Spencer
            Agile Software Development, UX Consultant

            On Wed, Mar 24, 2010 at 5:54 AM, samfmsutton <sam.superdeluxe@...> wrote:
             

            I'm a designer based in a developer heavy web development company. We started moving towards agile over the last year or so.

            One argument I'm facing at the moment is that wireframes etc seem like bureaucracy that gets in the way of writing stories and implementing them.

            I can understand that, although I'm not strict about this, and we have had really useful, positive discussions about decisions when we had wireframes to guide us.

            But what do you think? Is it better just to write stories, put live code out there and test the results and then refine, or have you had positive benefits from using wireframes or just basic mockups to think about the functionality beforehand?

            -Sam


          • Paul Spencer
            Hi Gene, That is generally what we try to do. If you have a resource available to create the mockups then they can be working along with the PO on the highest
            Message 5 of 11 , Mar 24, 2010
            View Source
            • 0 Attachment
              Hi Gene,

              That is generally what we try to do.  If you have a resource available to create the mockups then they can be working along with the PO on the highest priority items for the next Sprint so that they are ready to go.  Again don't get too far ahead of yourself because the PO can change priorities after the review.

              Of course all of this depends on your team and the goals of your project.  I agree with William, tinker with your process and get your team to a point where everyone feels they are being productive and creating a useful product.

              - Paul

              Paul Spencer
              Agile Software Development, UX Consultant

              On Wed, Mar 24, 2010 at 9:41 AM, Gene Arch <garch@...> wrote:
               

              Hi Sam,

              I am in a similar situation.  Our company has just adopted Agile over the past year or so, and I'm struggling with the question of "to prototype or not to prototype."  Currently, we do very little UX prototyping, though I see the benefit in doing so.  There have been a few projects I've been on where I basically forced time in there for wireframes of the interfaces, and it actually helped us foresee some difficult situations.  I think if you are doing spec reviews of the stories at the beginning of the sprint, maybe that's the time for (very) preliminary mockups?  I'm not sure.  I've also suggested to my scrum master the possibility of the UX people doing the prototyping work in a -1 sort of method (alongside the product owners writing specs for the stories - at least 1 sprint prior to when the stories are actually committed).  He hasn't responded on that yet.

              ~Gene


            • Sam Sutton
              Thanks for your responses guys, I realise my initial statement was a bit woolly, but trust me, you ve definitely helped me think this through. William - I
              Message 6 of 11 , Mar 24, 2010
              View Source
              • 0 Attachment
                Thanks for your responses guys, I realise my initial statement was a bit woolly, but trust me, you've definitely helped me think this through.

                William - I definitely agree with your statement that  we should be "seeing how little you can get away with and still produce great work". I'm certainly not in favor of producing documentation for it's own sake, but if it's going to help communicate ideas better and produce better decisions, then I will continue to advocate it.

                Gene - I'm not totally sure about the idea of ux sprints running parallel to development sprints; I kind of like the idea of devs and ux working together as much as possible.

                One thing I've done recently is pairing with developers with some ui implementation work and it's been really helpful.

                Apologies if there's any doubling up of replies here, I'm having issues with my gmail account and yahoo groups.

                -Sam

                On 24 March 2010 14:33, Paul Spencer <spencepd@...> wrote:
                 

                Hi Gene,


                That is generally what we try to do.  If you have a resource available to create the mockups then they can be working along with the PO on the highest priority items for the next Sprint so that they are ready to go.  Again don't get too far ahead of yourself because the PO can change priorities after the review.

                Of course all of this depends on your team and the goals of your project.  I agree with William, tinker with your process and get your team to a point where everyone feels they are being productive and creating a useful product.

                - Paul

                Paul Spencer
                Agile Software Development, UX Consultant

                On Wed, Mar 24, 2010 at 9:41 AM, Gene Arch <garch@...> wrote:
                 

                Hi Sam,

                I am in a similar situation.  Our company has just adopted Agile over the past year or so, and I'm struggling with the question of "to prototype or not to prototype."  Currently, we do very little UX prototyping, though I see the benefit in doing so.  There have been a few projects I've been on where I basically forced time in there for wireframes of the interfaces, and it actually helped us foresee some difficult situations.  I think if you are doing spec reviews of the stories at the beginning of the sprint, maybe that's the time for (very) preliminary mockups?  I'm not sure.  I've also suggested to my scrum master the possibility of the UX people doing the prototyping work in a -1 sort of method (alongside the product owners writing specs for the stories - at least 1 sprint prior to when the stories are actually committed).  He hasn't responded on that yet.

                ~Gene





                --
                www.twitter.com/superdeluxesam
              • William Pietri
                ... And well you should, Sam. One issue I see with some frequency is rooted in a difference in perception. Developers look at a UI and think it s fine.
                Message 7 of 11 , Mar 24, 2010
                View Source
                • 0 Attachment
                  On 03/24/2010 09:06 AM, Sam Sutton wrote:
                  > William - I definitely agree with your statement that we should be
                  > "seeing how little you can get away with and still produce great
                  > work". I'm certainly not in favor of producing documentation for it's
                  > own sake, but if it's going to help communicate ideas better and
                  > produce better decisions, then I will continue to advocate it.


                  And well you should, Sam.

                  One issue I see with some frequency is rooted in a difference in
                  perception. Developers look at a UI and think it's fine. Designers see
                  things that worry them. The only real way to settle the difference is to
                  see what happens when you put it in front of real users, perhaps in a
                  test environment, or perhaps by going live and seeing what results you get.

                  It may be that to persuade developers of the value of your approach, you
                  need to try some stories each way, and talk over what happens in the
                  retrospective. And if you can see things that they can't, find ways to
                  demonstrate it to them.

                  In college, I did tech support, and it really changed me as a developer;
                  seeing the details of how people struggled with software made me
                  appreciate good design in a way no amount of theory or persuasion ever
                  could.

                  William
                • Gene Arch
                  Sam, I m not entirely sure if parallel sprints is the way to go either. I m still working through the best way to do this myself. I do like the idea of
                  Message 8 of 11 , Mar 25, 2010
                  View Source
                  • 0 Attachment
                    Sam,
                     
                    I'm not entirely sure if parallel sprints is the way to go either.  I'm still working through the best way to do this myself.  I do like the idea of pairing with developers on UI implementations, however.  And come to think of it, if I'm spending all my time doing mockups in parallel, I wouldn't have the time for that kind of collaboration. 
                     
                    ~Gene


                    From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Sam Sutton
                    Sent: Wednesday, March 24, 2010 11:06 AM
                    To: agile-usability@yahoogroups.com
                    Subject: Re: [agile-usability] Agile ux = zero or miminal upfront prototyping work?

                     

                    Thanks for your responses guys, I realise my initial statement was a bit woolly, but trust me, you've definitely helped me think this through.

                    William - I definitely agree with your statement that  we should be "seeing how little you can get away with and still produce great work". I'm certainly not in favor of producing documentation for it's own sake, but if it's going to help communicate ideas better and produce better decisions, then I will continue to advocate it.

                    Gene - I'm not totally sure about the idea of ux sprints running parallel to development sprints; I kind of like the idea of devs and ux working together as much as possible.

                    One thing I've done recently is pairing with developers with some ui implementation work and it's been really helpful.

                    Apologies if there's any doubling up of replies here, I'm having issues with my gmail account and yahoo groups.

                    -Sam

                    On 24 March 2010 14:33, Paul Spencer <spencepd@gmail. com> wrote:
                     

                    Hi Gene,


                    That is generally what we try to do.  If you have a resource available to create the mockups then they can be working along with the PO on the highest priority items for the next Sprint so that they are ready to go.  Again don't get too far ahead of yourself because the PO can change priorities after the review.

                    Of course all of this depends on your team and the goals of your project.  I agree with William, tinker with your process and get your team to a point where everyone feels they are being productive and creating a useful product.

                    - Paul

                    Paul Spencer
                    Agile Software Development, UX Consultant

                    On Wed, Mar 24, 2010 at 9:41 AM, Gene Arch <garch@itagroup. com> wrote:
                     

                    Hi Sam,

                    I am in a similar situation.  Our company has just adopted Agile over the past year or so, and I'm struggling with the question of "to prototype or not to prototype."  Currently, we do very little UX prototyping, though I see the benefit in doing so.  There have been a few projects I've been on where I basically forced time in there for wireframes of the interfaces, and it actually helped us foresee some difficult situations.  I think if you are doing spec reviews of the stories at the beginning of the sprint, maybe that's the time for (very) preliminary mockups?  I'm not sure.  I've also suggested to my scrum master the possibility of the UX people doing the prototyping work in a -1 sort of method (alongside the product owners writing specs for the stories - at least 1 sprint prior to when the stories are actually committed).  He hasn't responded on that yet.

                    ~Gene





                    --
                    www.twitter. com/superdeluxes am

                  • SusRobson@aol.com
                    If any of you are in the Boston area or plan to be in the Boston area on June 9th, the Boston UPA is holding a conference. We are currently looking for
                    Message 9 of 11 , Mar 25, 2010
                    View Source
                    • 0 Attachment
                      If any of you are in the Boston area or plan to be in the Boston area on June 9th, the Boston UPA is holding a conference. We are currently looking for presenters. Agile is a big topic right now as everyone seems to be doing it yet nobody really knows how to do it (yes, I know that is an overstatement). If you are interested in presenting at this conference, please go to http://www.upaboston.org/miniconf10/call.shtml to submit a proposal.
                       
                      Thanks,
                      Susie Robson
                      Boston UPA



                      -----Original Message-----
                      From: Gene Arch <garch@...>
                      To: agile-usability@yahoogroups.com
                      Sent: Thu, Mar 25, 2010 4:24 pm
                      Subject: RE: [agile-usability] Agile ux = zero or miminal upfront prototyping work?

                       
                      Sam,
                       
                      I'm not entirely sure if parallel sprints is the way to go either.  I'm still working through the best way to do this myself.  I do like the idea of pairing with developers on UI implementations, however.  And come to think of it, if I'm spending all my time doing mockups in parallel, I wouldn't have the time for that kind of collaboration. 
                       
                      ~Gene


                      From: agile-usability@ yahoogroups. com [mailto:agile- usability@ yahoogroups. com] On Behalf Of Sam Sutton
                      Sent: Wednesday, March 24, 2010 11:06 AM
                      To: agile-usability@ yahoogroups. com
                      Subject: Re: [agile-usability] Agile ux = zero or miminal upfront prototyping work?

                       
                      Thanks for your responses guys, I realise my initial statement was a bit woolly, but trust me, you've definitely helped me think this through.

                      William - I definitely agree with your statement that  we should be "seeing how little you can get away with and still produce great work". I'm certainly not in favor of producing documentation for it's own sake, but if it's going to help communicate ideas better and produce better decisions, then I will continue to advocate it.

                      Gene - I'm not totally sure about the idea of ux sprints running parallel to development sprints; I kind of like the idea of devs and ux working together as much as possible.

                      One thing I've done recently is pairing with developers with some ui implementation work and it's been really helpful.

                      Apologies if there's any doubling up of replies here, I'm having issues with my gmail account and yahoo groups.

                      -Sam

                      On 24 March 2010 14:33, Paul Spencer <spencepd@gmail. com> wrote:
                       
                      Hi Gene,

                      That is generally what we try to do.  If you have a resource available to create the mockups then they can be working along with the PO on the highest priority items for the next Sprint so that they are ready to go.  Again don't get too far ahead of yourself because the PO can change priorities after the review.

                      Of course all of this depends on your team and the goals of your project.  I agree with William, tinker with your process and get your team to a point where everyone feels they are being productive and creating a useful product.

                      - Paul

                      Paul Spencer
                      Agile Software Development, UX Consultant

                      On Wed, Mar 24, 2010 at 9:41 AM, Gene Arch <garch@itagroup. com> wrote:
                       
                      Hi Sam,
                      I am in a similar situation.  Our company has just adopted Agile over the past year or so, and I'm struggling with the question of "to prototype or not to prototype."  Currently, we do very little UX prototyping, though I see the benefit in doing so.  There have been a few projects I've been on where I basically forced time in there for wireframes of the interfaces, and it actually helped us foresee some difficult situations.  I think if you are doing spec reviews of the stories at the beginning of the sprint, maybe that's the time for (very) preliminary mockups?  I'm not sure.  I've also suggested to my scrum master the possibility of the UX people doing the prototyping work in a -1 sort of method (alongside the product owners writing specs for the stories - at least 1 sprint prior to when the stories are actually committed).  He hasn't responded on that yet.
                      ~Gene




                      --
                      www.twitter. com/superdeluxes am
                    • rasmus4200
                      +1 To what William said. I find specific UX practices and how they get applied on agile projects is very team dependent (not so much company or process). How
                      Message 10 of 11 , Jun 26, 2010
                      View Source
                      • 0 Attachment
                        +1 To what William said.

                        I find specific UX practices and how they get applied on agile projects is very team dependent (not so much company or process).

                        How you incorporate UX into your agile process will be highly dependent on who you have on your team and how they work together.

                        I know this sounds obvious but it's not.

                        What if you have a developer with a really good eye for design?
                        Could they do the mock-ups the iteration before and share them with the rest of the team?

                        Or what if you have a designer who still knows how to code, but loves working with paper prototypes before building anything concrete.

                        Theirs a saying that you pick your architecture when you pick your team. I believe the same is true for how UX is used and applied in your project.

                        As William said, it's something you as a team need to come together on a figure out.

                        My advice is to look for people who are open to new ideas, aren't afraid to experiment, and can check their egos at the door and enjoy learning from others.

                        Because the experience matters. And there is so much the UX community brings to the process.

                        Good luck!

                        --
                        Twitter: @jrasmusson
                        http://agilewarrior.wordpress.com
                        The Agile Samurai - http://bit.ly/9wlCdz


                        --- In agile-usability@yahoogroups.com, William Pietri <william@...> wrote:
                        >
                        > On 03/24/2010 02:54 AM, samfmsutton wrote:
                        > > I'm a designer based in a developer heavy web development company. We started moving towards agile over the last year or so.
                        > >
                        > > One argument I'm facing at the moment is that wireframes etc seem like bureaucracy that gets in the way of writing stories and implementing them.
                        > >
                        > > I can understand that, although I'm not strict about this, and we have had really useful, positive discussions about decisions when we had wireframes to guide us.
                        > >
                        > > But what do you think? Is it better just to write stories, put live code out there and test the results and then refine, or have you had positive benefits from using wireframes or just basic mockups to think about the functionality beforehand?
                        > >
                        >
                        > I think there are three separate questions here:
                        >
                        > 1. What do you, as a designer, need to do personally to think through
                        > an interface?
                        > 2. What are the most efficient ways for your team to meet and design
                        > things together?
                        > 3. What's the most efficient way to get a good experience to users?
                        >
                        >
                        > I don't think there's a general-case answer to these: you're looking for
                        > the intersection of individual variation, team variation, and minimum
                        > waste. To me, the only way to find that is to be continually tinkering
                        > with your process, seeing how little you can get away with and still
                        > produce great work.
                        >
                        >
                        > So if I were in your shoes, there are some things I'd start discussions on:
                        >
                        > * Is everybody happy with the kind of products your team is turning out?
                        > * Does the team really iterate on things until they get to the right
                        > level of quality?
                        > * In what situations can some up-front thinking save your team time?
                        > * How can the team conduct experiments to settle questions like this?
                        >
                        >
                        > Really, this could go either way. I've seen teams waste a lot of time
                        > and money by going off half-cocked. I've also seen immense waste from
                        > too much design time and expensive design artifacts. Developers are
                        > prone to the former mistake; designers, the latter. It's only when you
                        > have a whole team working together that you can find the local optimum.
                        >
                        > William
                        >
                      • Fredrik Matheson
                        On a side note: in my experience it s not *too* difficult to craft an effective, learnable and pleasant interface in an agile context when you know the domain
                        Message 11 of 11 , Jun 26, 2010
                        View Source
                        • 0 Attachment
                          On a side note: in my experience it's not *too* difficult to craft an effective, learnable and pleasant interface in an agile context when you know the domain well.

                          So, if you know the domain well, the most effective approach is often to sit next to a front-end developer and sketch the interface on paper. This approach avoids the normal conflicts between how your sketch looked and what the coded result looked like, and lets you focus on what's on the screen now, and what needs to get in there.

                          Obviously you have to test things and you'll hopefully have an agile infrastructure that will allow lots of split testing and analytics. Still, don't forget the observation/interview/probing part of your process.

                          If you *don't* know the domain well, then make sure you carve out enough time for research and explorative prototyping. Here, the goal is not to make a interface but to learn:
                          - who are the users, and in what contexts do they use our offering?
                          - what kinds of tools are they using (mobile, WIMP, gesture-based, etc)?
                          - what are the competing tools like?
                          - are there business rules that limit our design freedom, and can we circumvent them?
                          - should we follow inefficient conventions that users are familiar with or introduce foreign but more effective mechanisms?
                          … and so on.

                          As always, you must be prepared to kill your darlings. If the produced interface isn't delivering the desired results, break it apart and find a way fix it. Working software is great, business value is even better.

                          - Fredrik
                        Your message has been successfully submitted and would be delivered to recipients shortly.