Back to Collections

The 12 Realistic Principles of Agile UX

These principles are key for running a successful UX project. They are inspired by processes from both Lean and Agile UX and are derived from real projects that Guiseppe's done.

Source: Studio by UXPin

The principles

  1. Customer experience (CX)
  2. Harnessing technological and social change
  3. Development timelines that make good use of resources
  4. Adaptive collaboration
  5. Building projects around motivated individuals
  6. Effective communication across team channels
  7. Working applications and high-quality UX as success benchmarks
  8. Sustainable development
  9. Technical excellence is relative
  10. Simplicity
  11. Cross-functional teams
  12. Adaptable, flexible teams

  1. Customer experience (CX)

    We don’t just want customers to be “satisfied.” We want to design user experiences that are cognizant of both business realities and customer contexts. Customers are not always users, but most customers are going to use one or more points of contact for a given organization.

  2. Harnessing technological and social change

    We need to define changes that we expect in the next iteration of a project, rather than just adapting to current changes. Instead of putting out fires, our job as UX professionals should be to create future-ready designs that help clients adapt to new challenges.

  3. Development timelines that make good use of resources

    Fast is a relative term. For some organizations, getting everyone in the same room once a month can be a huge improvement. Here’s where Lean is important: we should always strive as UX professionals to make efficient use of resources without short-changing our clients by focusing on process improvement, not on process perfection.

  4. Adaptive collaboration

    The degree of collaboration changes from project to project. Some problems clearly fall within the purview of a particular specialist, some will require an entire team to solve, and some require sub-groups of a team. Some clients can solve problems on their own and some require more hands-on guidance.

  5. Building projects around motivated individuals

    Organizational and technological constraints always matter. We can’t advise organizations to put all their investments into bleeding-edge solutions if they don’t have the capacity to recover if these solutions fail. We should encourage change, but always track ROI.

  6. Effective communication across team channels

    Rather than mandating one form of communication, strive to build more coordinated communication across individuals within teams. This would be more of a tactical, cross-functional approach to communication, rather than mandating everyone be in the same room for every project. Tools promoting collaborative design like Slack and UXPin help consolidate documentation and feedback in one place.

  7. Working applications and high-quality UX as success benchmarks

    Your application can make a million decisions for users at the first keystroke or gesture, but if users don’t see that value, your product will mostly likely fall flat. At the same time, the most bleeding-edge technology is useless if proof-of-concept isn’t achieved early through lo-fi prototyping.

  8. Sustainable development

    This goes back to principle 3. Some features within a specific application will probably become obsolete in future versions. New features are also the lifeblood of successful product launches. Product iterations should always be a balancing act between what existing customers expect and what new customers need.

  9. Technical excellence is relative

    In some organizations, like institutions of higher education or non-profits, for example, the most viable solutions might be considered obsolete in other venues. And that’s OK because we must consider price-point and organizational capacity. A small non-profit has very different technical requirements than a multinational corporation.

  10. Simplicity

    Again, it depends. The simplest solution isn’t always the best one, especially if that solution neglects user, organizational, or technical realities.

  11. Cross-functional teams

    UX specialization is nothing to be feared. Silos are the real problem. When specialists don’t talk to one another, we get products that neglect one or more elements. As long as productive, cross-channel communication is happening within organizations, then specialization is okay.

  12. Adaptable, flexible teams

    Self-reflection is great, but can teams adapt to new challenges? Can they roll with the punches? Are they comfortable with discomfort? We need project teams who are hungry to learn what users want and what technologies require. Great design teams are great improvisers.