The First Law of Product Experience Design
As the discipline of User Experience Design evolves, it needs to self evaluate — admitting that prevalent conversations regarding design tools and processes are holding us hostage, rather than allowing us to meet the modern demands of technology.
I believe this change has to happen by reframing design — pushing the boundaries of our traditional responsibility and purview. With that in mind, I submit to the design community The First Law of Product Experience Design. This first law is simply a question which sets a foundation for designers to intentionally choose a “design way” that is best for their organization:
When do you pay for knowledge, and how much will it cost when you pay for it?
Clearly, such an axiom emphasizes UX design (and design in general) as a rational, measured, accountable process. It promotes reflection into both the investment a business should make in UX/product design, and the day-to-day design decisions made by each individual designer. It liberates UX/Product designers who see themselves responsible for only the technology experiences of customers and users to become stewards of the entire product building process, ensuring valuable design decisions make it into the hands of their users.
The First Law of Product Experience Design provides this backdrop for change by acknowledging that A) design effort has a cost, and B) design effort should yield something — usually knowledge and decision-making information. For example, an organization could ask if they should invest time into task-based, clickable prototypes to get feedback from only 20 users, rather than investing in an engineering effort to build a full experience in a real, evaluative A/B test environment for 2,000 users. Which is the right answer? It depends on your organization.
Design Value (Cost & Yield)
Similarly, individual designers can evaluate their day-to-day design activities (investment) with judgement by looking at their design work through a “design value” lens (cost and yield). I’m constantly asking my team questions like: What do you hope to learn by wire framing? What do you hope to communicate with this prototype? Is it accurate enough? Does it have a low up-front cost or a low iterative-cost?
Investing in design tools or design activities without understanding the cost and yield of such activities is like aimlessly mining for gold without considering the efficacy of your methods.
Imagine having a 100 acre gold claim somewhere in untapped wilderness. You know there’s gold in them thar hills. One can only pick up so many nuggets on the surface of the ground with limited effort before you have to start searching and mining. Eventually, you have to spend more resources to find additional gold. Think resources, methods, and time. Why would you pay to operate a CAT D Bulldozer (time, fuel, etc.) on your gold claim if you can’t yield a certain % of gold with each bucketload of pay dirt. You either have to find a new location to use your bulldozer, or you need to change your method of gathering and extracting gold from your efforts.
For design teams that want to make the evolutionary leap, The First Law of Product Experience Design situates design activities as “learning activities”. It reframes design tools as “learning tools”. Sketching, wire framing, mocks, prototyping, user research… are all just activities to learn and make decisions. Some design activities are for creating knowledge for the designer, other activities are for creating understanding for stakeholders, and others are for evaluating assumptions. Sometimes it’s better to hand dig and pan for gold before bringing in the bulldozer. What is the right method? Again — it depends on the project and how much investment you can afford for the results you need.
Application within a design team
An interesting thing has happened for my team as we have used The First Law of Product Experience Design to frame our design work. It forces us to be accountable for our efforts. We estimate work, evaluate risks, and measure capacity — all of which help us better understand the real value (cost and yield) of design.
With this understanding of the real cost of design, we are better able to make better design decisions — and better investment decisions.
For example, we’ll often punt on a thorough evaluation of toolbar icons in a design prototype; because compared to the investment of time it would take for us to get enough feedback through our own prototyping, it costs less to evaluate and change toolbar icons in the real product through A/B testing. This type of downstream testing is useful for us because we can evaluate the design decisions with hundreds of users, analyzing the impact they have on performance and behavior… something we can’t do upstream with prototyping.
Other decisions regarding workflow or information architecture — things that have a large impact (and often infrequent iterative cycles) at a system level — are relatively cheap to invest in with a design team, rather than build multiple options for users with real code and evaluate separately. Knowing what’s right and when to pay for that knowledge differs from project to project, and from team to team.
Application within an organization
Sooner or later, I believe a business has to pay to know if their product decisions and resource investments were correct. In other words, did their decisions yield enough value to keep the lights on, invest in more R&D, or triple the usability/satisfaction of users? And businesses need designers that can ask this question and force a level of reflection into their own product building philosophies and process decisions.
“When do we pay for knowledge and how much will it cost when we pay for it?” is a starting point for design teams to facilitate a conversation with their organization around the value (and assumed value) of user experience design. Does your organization want to pay for 100% certainty before building anything? Answering “yes” to this question may support or conflict with a design team’s philosophy to invest in lots of user research up stream. On the contrary, trying to gather product and experience knowledge after code release may be a bad decision if a business doesn’t have a philosophy or process to support iterative changes after first-generation features.
One of the reasons why I love working at Lucid Software is because we have both the resources and philosophy to test design decisions and measure the impact/value of design. We also have a great team of business analysts that has invested in testing systems to quickly evaluate different ideas in “the wild” with customers, allowing us to measure the results of product changes against key performance metrics. And finally, we have incredible engineering team that is willing to work quickly, take risks, and iterate on ideas.
The First Law of Product Experience Design has helped us focus on the most important experiences in our products and has influenced the way we collaborate with others — transforming product design into a more valuable business partner. And while it’s been nice to see product design grow and mature at Lucid, ultimately our customers win as better design decisions make their way into the product, across the finish line, and into the hands of our users.
(This is a post from the Director of UX at Lucid Software. We make collaborative diagramming and layout tools: Lucidchart and Lucidpress.)
