The 12 Realistic Principles of Agile UX
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Simplicity
Again, it depends. The simplest solution isn’t always the best one, especially if that solution neglects user, organizational, or technical realities.
-
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.
-
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.