02 September 2016
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
Again, it depends. The simplest solution isn’t always the best one, especially if that solution neglects user, organizational, or technical realities.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Again, it depends. The simplest solution isn’t always the best one, especially if that solution neglects user, organizational, or technical realities.
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.
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.
