{"id":11433,"date":"2016-01-15T17:22:04","date_gmt":"2016-01-16T01:22:04","guid":{"rendered":"https:\/\/www.uxpin.com\/studio\/?p=11433"},"modified":"2021-03-08T04:25:18","modified_gmt":"2021-03-08T12:25:18","slug":"the-12-realistic-principles-of-agile-ux","status":"publish","type":"post","link":"https:\/\/www.uxpin.com\/studio\/blog\/the-12-realistic-principles-of-agile-ux\/","title":{"rendered":"The 12 Realistic Principles of Agile UX"},"content":{"rendered":"

Lean ensures we\u2019re building the right product and Agile helps ensure we build the product right.<\/p>\n

As the blog post Lean vs. Agile UX explains<\/a>, Lean focuses more on product strategy while Agile focuses on product design processes.<\/p>\n

In this post, I\u2019ll explain UX\u00a0design principles\u00a0inspired by processes from both Lean and Agile UX.<\/p>\n

First, a Super Brief History of Agile<\/h2>\n

First coined in 2001 by 17 well-known developers in the Manifesto for Agile Software Development<\/i><\/a>, Agile originally referred to a software development process that was flexible and \u00a0collaborative. Teams focused on creating working software through continuous customer validation rather than focusing solely on technical requirements.<\/p>\n

\"image02\"<\/p>\n

Photo credit: Four Worlds. Creative Commons<\/a>. \u00a0<\/em><\/p>\n

Specifically, Agile seeks to fulfill 12 principles:<\/p>\n

    \n
  1. \n
      \n
    1. Customer satisfaction<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
        \n
      1. \n
          \n
        1. Harnessing change<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
            \n
          1. \n
              \n
            1. Faster development timelines<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
                \n
              1. \n
                  \n
                1. Collaboration<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
                    \n
                  1. \n
                      \n
                    1. Building projects around motivated individuals<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
                        \n
                      1. \n
                          \n
                        1. Face-to-face communication<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
                            \n
                          1. \n
                              \n
                            1. Working software as the key benchmark for success<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
                                \n
                              1. \n
                                  \n
                                1. Sustainable development<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
                                    \n
                                  1. \n
                                      \n
                                    1. Technical excellence<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
                                        \n
                                      1. \n
                                          \n
                                        1. Simplicity<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
                                            \n
                                          1. \n
                                              \n
                                            1. Self-organizing teams<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
                                                \n
                                              1. Self-reflecting teams<\/li>\n<\/ol>\n

                                                If these principles just sound like the basis of a lot of good contemporary design work, that\u2019s no accident.<\/p>\n

                                                Jim Highsmith, one of the original authors of the Manifesto, <\/i>even said recently in his preface for the book Agile Experience Design: A Digital Designer’s Guide to Agile, Lean, and Continuous<\/i><\/a>:<\/p>\n

                                                \u201cSpecialisation wasn\u2019t the primary problem\u2014collaboration was. As the Agile movement matured, we\u2019ve added back specialists as we\u2019ve learned to integrate them into Agile teams. That\u2019s not to say that having a more general set of skills isn\u2019t very valuable, but in our complex world there is still a need for expertise.\u201d<\/p><\/blockquote>\n

                                                As we design more complex products like social media products and subscription-based services, our teams and processes are only going to grow.<\/p>\n

                                                So\u00a0while\u00a0Agile has undoubtedly made\u00a0a major impact on the design world, it might be time to update to reflect the realistic demands of current UX projects.<\/p>\n

                                                UX Is An Attitude, Not Just A Skillset<\/h2>\n

                                                I\u2019m always hesitant to describe to clients and fellow researchers a hard-and-fast list of skill sets that all UX developers should be versed in.<\/p>\n

                                                Unlike sister disciplines like web development, UX is a much broader discipline with more intangible skills. UX is more of an attitude than just a skillset.<\/p>\n

                                                UX designers are responsible for ensuring a high-quality user experience for a product or service. However, how <\/i>they do so changes from project to project.<\/p>\n

                                                \"image01\"<\/p>\n

                                                Photo Credit: Kissmetrics<\/a><\/em><\/p>\n

                                                Consider these two examples from some of my recent projects as a UX consultant<\/a>:<\/p>\n

                                                Project A:<\/b> A client needed \u00a0a content audit of their recently launched website. They were concerned the website structure wasn\u2019t optimized for their target users.<\/p>\n

                                                Project B:<\/b> A grant-funded web application developed through a university wanted a UX strategy for growing their application beyond its initial prototype.<\/p>\n

                                                Though I used my expertise in UX and Agile<\/a> to advise both of these clients, each client had very different needs.<\/p>\n

                                                Project A required a quick, lean audit with immediately-actionable feedback. Project B had a much longer timeline that much more closely resembled a waterfall approach, even though the project was being developed in a relatively lean, collaborative environment (two individuals besides myself doing most of the development work).<\/p>\n

                                                In fact, I would hazard to say that if I had tried to advise both of these clients in the exact same way, one of these projects would have failed. Had I tried to get Project A to more closely resemble a collaborative, Agile approach, the client would\u2019ve gone somewhere else for help with their problem.<\/p>\n

                                                Had I tried to get Project B to more closely resemble a lean approach with tight timelines, the clients would\u2019ve seen me as too pushy and sensitive to the limitations of their organization.<\/p>\n

                                                The bottom line is that a one-size fits all UX design process just doesn\u2019t work. You have to take it on a case-by-case, situation-by-situation basis.<\/p>\n<\/section>

                                                Grab design ebooks created by best designers<\/h3>

                                                All for free<\/p>