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

Process Entry Points...

Expand Messages
  • Brando
    I am currently working to implement a flexible, but consistent Agile UX process at a large enterprise-software development group. We typically have 4-10 large
    Message 1 of 9 , Mar 25, 2011
    • 0 Attachment
      I am currently working to implement a flexible, but consistent Agile UX process at a large enterprise-software development group. We typically have 4-10 large scale projects going at any one time.

      As I examine current processes and look at where projects went off-course, or progressed slowly, is because they did not get UX/Strategy involved early enough. Our current practices seem to put any UX involvment -AFTER- requirements have been generally collected.

      It seems that in an Agile/Iterative environment, it makes sense for the UX side of the project to:
      - Be engaged AT the time that Business Analsyts are assigned
      - This could be BEFORE any Product Backlog or Features List is officially complete.
      - Understand HIGH-LEVEL functionality (not necessarily details)
      - Create early 'customer journey' sketches / outlines
      - BEFORE the rest of the development team actually joins, have an early conceptual mockup/design so it also helps the project team have a quicker understanding of the project --- visually.

      It just seems that getting a requirements document 'dropped on my desk' is not the most effective way to design an application.

      I'm looking for opinions on the best place to inject into the project.

      Any opinions, trials, or suggestions are welcome.
    • Dean
      I am interested to hear this feedback as well. I agree UX should be engaged as part of Discovery or Inception. The question is the level of engagement. At my
      Message 2 of 9 , Mar 26, 2011
      • 0 Attachment
        I am interested to hear this feedback as well.

        I agree UX should be engaged as part of Discovery or Inception. The question is the level of engagement. At my current client, the push back is that UX tends to dominate the conversation with product managers. Ideas that are very difficult to deliver get baked into requirements.

        I'm recommending the following approach of two distinct conversations.

        First, the BA gets to a proposed feature set and a high level use case. UX, along with architects, can listen and ask clarifying questions but are mostly present to understand. So initially engagement is fairly low. They don't actually even have to be present.

        Then BA presents the initial discovery and gets input from UX and architects to produce options: Good, Better, Best solution sets. The Ba will Gain agreement and present these options to product managers. This may be the place for conceptual mock-ups.

        The BA intentionally iterates between these two conversations. The BA must hold the context of learning from the product manager/ business and then developing viable options with UX, architects and dev. These are distinctly different conversations. I call this dialog then discussion (my Peter Senge reference :).

        I'm looking forward to hearing other approaches. Dean Stevens

        --- In agile-usability@yahoogroups.com, "Brando" <brandonpmitchell@...> wrote:
        >
        > I am currently working to implement a flexible, but consistent Agile UX process at a large enterprise-software development group. We typically have 4-10 large scale projects going at any one time.
        >
        > As I examine current processes and look at where projects went off-course, or progressed slowly, is because they did not get UX/Strategy involved early enough. Our current practices seem to put any UX involvment -AFTER- requirements have been generally collected.
        >
        > It seems that in an Agile/Iterative environment, it makes sense for the UX side of the project to:
        > - Be engaged AT the time that Business Analsyts are assigned
        > - This could be BEFORE any Product Backlog or Features List is officially complete.
        > - Understand HIGH-LEVEL functionality (not necessarily details)
        > - Create early 'customer journey' sketches / outlines
        > - BEFORE the rest of the development team actually joins, have an early conceptual mockup/design so it also helps the project team have a quicker understanding of the project --- visually.
        >
        > It just seems that getting a requirements document 'dropped on my desk' is not the most effective way to design an application.
        >
        > I'm looking for opinions on the best place to inject into the project.
        >
        > Any opinions, trials, or suggestions are welcome.
        >
      • chris chandler
        Dean, With all due respect, that sounds horrible. I m probably a big jerk for saying so, but let me tell you that I operate in the UX portion of a gigantic
        Message 3 of 9 , Mar 27, 2011
        • 0 Attachment
          Dean,

          With all due respect, that sounds horrible. I'm probably a big jerk for saying so, but let me tell you that I operate in the UX portion of a gigantic enterprise, and I live something very close to the scenario you describe, so my reaction is based in my experience.

          Let me paraphrase your process:
          The product manager has an idea (or even mandate) for a feature. He describes this feature to the BA, who then describes it to the UX person. The BA goes back and forth between the two, (or three, or four depending on how you count architects and dev) until he wraps it all up and someone gets the go ahead to build something -- presumably based on all the "context" he's been saving.

          Again, I'm not trying to be harsh, and I'm probably exaggerating, but there is pretty much nothing relating to an "agile" methodology in anything you described.

          One other approach, would be to read the agile manifesto and see how the principles there, if applied, would alter the process you laid out.

          Individuals and interactions over processes and tools
          Working software over comprehensive documentation
          Customer collaboration over contract negotiation
          Responding to change over following a plan

          I'm not even going to get into the fact that the rationale you mentioned for this process is to keep UX from dominating the product managers vision -- but I will say to me, this hints at some fundamental cultural issues in the organization that stand in the way of effectiveness.

          -cc



          On Sat, Mar 26, 2011 at 12:00 PM, Dean <dean.stevens1@...> wrote:
           

          I am interested to hear this feedback as well.

          I agree UX should be engaged as part of Discovery or Inception. The question is the level of engagement. At my current client, the push back is that UX tends to dominate the conversation with product managers. Ideas that are very difficult to deliver get baked into requirements.

          I'm recommending the following approach of two distinct conversations.

          First, the BA gets to a proposed feature set and a high level use case. UX, along with architects, can listen and ask clarifying questions but are mostly present to understand. So initially engagement is fairly low. They don't actually even have to be present.

          Then BA presents the initial discovery and gets input from UX and architects to produce options: Good, Better, Best solution sets. The Ba will Gain agreement and present these options to product managers. This may be the place for conceptual mock-ups.

          The BA intentionally iterates between these two conversations. The BA must hold the context of learning from the product manager/ business and then developing viable options with UX, architects and dev. These are distinctly different conversations. I call this dialog then discussion (my Peter Senge reference :).

          I'm looking forward to hearing other approaches. Dean Stevens



          --- In agile-usability@yahoogroups.com, "Brando" <brandonpmitchell@...> wrote:
          >
          > I am currently working to implement a flexible, but consistent Agile UX process at a large enterprise-software development group. We typically have 4-10 large scale projects going at any one time.
          >
          > As I examine current processes and look at where projects went off-course, or progressed slowly, is because they did not get UX/Strategy involved early enough. Our current practices seem to put any UX involvment -AFTER- requirements have been generally collected.
          >
          > It seems that in an Agile/Iterative environment, it makes sense for the UX side of the project to:
          > - Be engaged AT the time that Business Analsyts are assigned
          > - This could be BEFORE any Product Backlog or Features List is officially complete.
          > - Understand HIGH-LEVEL functionality (not necessarily details)
          > - Create early 'customer journey' sketches / outlines
          > - BEFORE the rest of the development team actually joins, have an early conceptual mockup/design so it also helps the project team have a quicker understanding of the project --- visually.
          >
          > It just seems that getting a requirements document 'dropped on my desk' is not the most effective way to design an application.
          >
          > I'm looking for opinions on the best place to inject into the project.
          >
          > Any opinions, trials, or suggestions are welcome.
          >


        • chris chandler
          Brando, I completely agree that having requirements dropped on your desk is hardly the right way to do anything. I also have to say I m not a big fan of doing
          Message 4 of 9 , Mar 27, 2011
          • 0 Attachment
            Brando,

            I completely agree that having requirements dropped on your desk is hardly the right way to do anything.

            I also have to say I'm not a big fan of doing a protype so the devs can get up to speed faster -- this is pretty much an illusion in my experience. The logic of "things went wrong because the right people weren't involved early enough" doesn't stop with UX.

            Instead of "injecting" yourself into the process, your organization needs to figure out how the product owner, the designers and the developers are all equally responsible for delivering functionality.

            -cc



            On Fri, Mar 25, 2011 at 1:53 PM, Brando <brandonpmitchell@...> wrote:
             

            I am currently working to implement a flexible, but consistent Agile UX process at a large enterprise-software development group. We typically have 4-10 large scale projects going at any one time.

            As I examine current processes and look at where projects went off-course, or progressed slowly, is because they did not get UX/Strategy involved early enough. Our current practices seem to put any UX involvment -AFTER- requirements have been generally collected.

            It seems that in an Agile/Iterative environment, it makes sense for the UX side of the project to:
            - Be engaged AT the time that Business Analsyts are assigned
            - This could be BEFORE any Product Backlog or Features List is officially complete.
            - Understand HIGH-LEVEL functionality (not necessarily details)
            - Create early 'customer journey' sketches / outlines
            - BEFORE the rest of the development team actually joins, have an early conceptual mockup/design so it also helps the project team have a quicker understanding of the project --- visually.

            It just seems that getting a requirements document 'dropped on my desk' is not the most effective way to design an application.

            I'm looking for opinions on the best place to inject into the project.

            Any opinions, trials, or suggestions are welcome.


          • ElMohanned Ahmed
            Brando, This is exactly how we do it. The business analyst are involved together in business requirements sessions at the beginning of each sprint release.
            Message 5 of 9 , Mar 28, 2011
            • 0 Attachment
              Brando,
              This is exactly how we do it.
              The business analyst are involved together in business requirements sessions at the beginning of each sprint\release. They can demo some mock-ups or paper sketches to the customer to help elicit his needs and help him visualize the expected system. By the end of the requirements a storyboard is built either on paper or using any mock-up tool. The input to the team is the stories and the storyboard. The usability guy may actually build some sample pages to the team too.
              Regards,
              ElMohanned
            • ElMohanned Ahmed
              Just to clarify the analyst and the usability engineer are always a step a head of the whole team. While the team is finalizing sprint 1 the analyst and the
              Message 6 of 9 , Mar 28, 2011
              • 0 Attachment
                Just to clarify the analyst and the usability engineer are always a step a head of the whole team. While the team is finalizing sprint 1 the analyst and the usability guy are working on the backlog of sprint 2 sometimes involving the technical lead. It's more of a product owner team rather than the product owner as an individual.

                On Mon, Mar 28, 2011 at 3:46 PM, ElMohanned Ahmed <elmohanned@...> wrote:
                Brando,
                This is exactly how we do it.
                The business analyst are involved together in business requirements sessions at the beginning of each sprint\release. They can demo some mock-ups or paper sketches to the customer to help elicit his needs and help him visualize the expected system. By the end of the requirements a storyboard is built either on paper or using any mock-up tool. The input to the team is the stories and the storyboard. The usability guy may actually build some sample pages to the team too.
                Regards,
                ElMohanned

              • Brando
                Thanks for the feedback so far... the place where I m having the most heartburn is WHEN UX gets involved. What you describe below leads me to believe that UX
                Message 7 of 9 , Mar 28, 2011
                • 0 Attachment
                  Thanks for the feedback so far... the place where I'm having the most heartburn is WHEN UX gets involved. What you describe below leads me to believe that UX is not involved until it's time to gather requirements.

                  It would seem that UX needs to be involved at a higher-level, much sooner in the project --- before it's actually time to gather the detailed requirements.

                  If you could clarify, and anyone has other ideas, please chime in.

                  --- In agile-usability@yahoogroups.com, ElMohanned Ahmed <elmohanned@...> wrote:
                  >
                  > Brando,
                  > This is exactly how we do it.
                  > The business analyst are involved together in business requirements sessions
                  > at the beginning of each sprint\release. They can demo some mock-ups or
                  > paper sketches to the customer to help elicit his needs and help him
                  > visualize the expected system. By the end of the requirements a storyboard
                  > is built either on paper or using any mock-up tool. The input to the team is
                  > the stories and the storyboard. The usability guy may actually build some
                  > sample pages to the team too.
                  > Regards,
                  > ElMohanned
                  >
                • Natalie
                  Hi, I may be commenting too early on since I have not read the rest of the posts after this... But there is only one comment related to UX/ usabiity starting
                  Message 8 of 9 , Apr 5, 2011
                  • 0 Attachment
                    Hi,

                    I may be commenting too early on since I have not read the rest of the posts after this...

                    But there is only one comment related to UX/ usabiity starting ahead of the game where it needs to be... it is all about user research... which is a completely different understanding and viewpoint of a BA. I feel it is missing the whole point of finding the best way to integrate usability into the process. It is rare to find usability as any lead of discussions and that is where the problem is and I don't see these approaches helping but only reinforcing what is wrong with the current development processes... but this may be me projecting my own personal frustration I deal with day and out so I apologize if it is.
                    BAs need to work hand in hand with usability, not separate. Demos serve a minimal purpose and utility. Where is the usability testing... rapid iterations?? I may be speaking too soon but I find these posts missing the point.

                    --- In agile-usability@yahoogroups.com, ElMohanned Ahmed <elmohanned@...> wrote:
                    >
                    > Brando,
                    > This is exactly how we do it.
                    > The business analyst are involved together in business requirements sessions
                    > at the beginning of each sprint\release. They can demo some mock-ups or
                    > paper sketches to the customer to help elicit his needs and help him
                    > visualize the expected system. By the end of the requirements a storyboard
                    > is built either on paper or using any mock-up tool. The input to the team is
                    > the stories and the storyboard. The usability guy may actually build some
                    > sample pages to the team too.
                    > Regards,
                    > ElMohanned
                    >
                  • Justin Tauber
                    First, let me say how much i enjoy reading posts to this group. I ve learned a great deal lurking here. Thanks. Back to topic... It seems to me that there is
                    Message 9 of 9 , Apr 6, 2011
                    • 0 Attachment
                      First, let me say how much i enjoy reading posts to this group. I've learned a great deal lurking here. Thanks. Back to topic...

                      It seems to me that there is one artifact that BAs, UXDs and Devs can and should collaborate on early on, and that is the object model or ontology of the domain.

                      It amazes me how often the metaphor used to generate the object model is wrong, and how significant a difference fixing it makes to not only code quality, but also usability.

                      We call this different things, but I do think that the same model is expressed in an IA, or navigational structure, as in a data model, or more or less implicitly in the business requirements.

                      Interestingly, a focus on capturing all the user stories or paths through the system does not help with clarifying this model (though testing the relative priority of user stories with actual users may help to reveal a better domain metaphor, by shifting the primary context of objects users act on)

                      Maybe what's required to complement the more user-centred approach of agile development is a more object-orientated approach to user experience?

                      I could be wrong about this, but it's also tempting to suggest that the object model is particularly hard to improve iteratively. I think this is because the kind of stories you tell about users are restricted by it. Actions are like judgements, while object types are the ontology within which those judgements are formed. Worse, users will themselves adopt the implicit ontology of the system they are using, which often makes it difficult to tell when their difficulties are catastrophic, in the sense of compromising the entire conceptual scheme.

                      And for that very reason, it's best not to leave the definition of that model to any one of UX, BA or Dev - they all bring different sorts of constraints and intuitions that must be reconciled in the domain model, and they all need to buy into the same metaphor to ensure that they can validate it within user, business and system contexts.

                      Justin Tauber
                      Experience Architect, Profero Sydney
                      @brtrx
                    Your message has been successfully submitted and would be delivered to recipients shortly.