The Creative MBA #12
Discover more from Better by Design
The Creative MBA #12
Stated & revealed preferences, NNg principle #2, value propositions, Object-oriented programming, and why you should always be bargaining
“If I had asked people what they wanted, they would have said faster horses.”
Intro
Welcome back to Better by Design, the multi-disciplinary corner of the internet where I attempt to explain concepts like Object-Oriented Programming in under 300 words (pray for me 😅).
Whether you’re new here or an OG, say hello! I love meeting people and hearing about all the cool stuff you’re making. If you know anyone else who might like to join our little tribe, spread the love! 👇💚
Social & Behavioral Science
Stated preference vs. revealed preference
Stated and revealed preferences are two concepts used in behavioral economics to understand consumer behavior.
Stated preference is what people say they want, usually captured through interviews, surveys, or questionnaires.
Revealed preference is what people actually choose in real-life situations. By observing someone’s choices, we can infer what they prefer, even if it contradicts their stated preferences.
I started today’s piece with Henry Ford’s (supposed) quote because I think it’s a good reminder of the limits of relying only on stated preferences. The truth is that stated preferences often don’t reflect what consumers do in real life; people act differently than they say they would. This isn’t to dissuade you from talking with your customers. That’s critical. Rather it’s a reminder not to take stated preferences at face value.
You need to interpret that input, not just reflect it.
Then, if possible, pair what you’ve understood with insights from their actual behavior in the real world. By paying close attention and connecting the dots across those inputs you’re well on your way to giving your customers something better than they ever could have imagined 😇.
Prompts
What are some situations where you think stated and revealed preferences diverge the most? What might contribute to that discrepancy?
Consider instances in your own life where your stated preferences may have differed from your revealed preferences. What motivated these inconsistencies?
Resources
What Is Revealed Preference in Economics, and What Does It Show? - Investopedia
The Elusive Green Consumer - Katherine White and others (HBR)
Design Principles
Match between the system and the real world
NNg Principle #2
The design should speak the users' language. Use words, phrases, and concepts familiar to the user, rather than internal jargon. Follow real-world conventions, making information appear in a natural and logical order.
The second usability heuristic from Nielsen-Norman Group is really about meeting your users where they’re at.
When creating a new digital system, you inevitably have to invent concepts to model and describe all its otherwise abstract parts.
Aligning your description and presentation of those parts to concepts and language that your users are already familiar with in the real world can help make your software more approachable and intuitive.
Prompts
What’s a concept in your software that you think is well-matched with your users’ real-world experience?
What’s one that feels misaligned? How could you improve it?
Resources
Business
Value Proposition
Think of a value proposition (or “value prop”, for short) as the unique blend of features, benefits, and pricing that sets your product or service apart from the competition. It's the answer to the question, "Why should customers choose my offering over others?" A well-crafted value prop highlights the key reasons why your offering is the best choice for your target audience.
Three key components to consider when developing a value prop:
Features: What does your product or service offer? This can include anything from materials, design, or functionality to a memorable experience or outstanding customer service.
Benefits: How does your offering improve your customers' lives? This might involve a clear, tangible benefit or a benefit that’s more emotional and identity-driven.
Pricing: How does your product's price compare to competitors? Are you offering more value at a similar price or the same value at a lower price? Make sure your pricing reflects the worth of your product without alienating your target audience.
Prompts
Analyze your favorite brands' value props: What makes them stand out in the market? How do they communicate their unique selling points?
Revisit a product you made: Can you clearly articulate its value prop? How can you refine it to better resonate with the target audience?
Explore pricing strategies: How might different pricing approaches impact the perceived value of what you’re selling?
Resources
Technology
Object-Oriented Programming
Object-Oriented Programming (OOP) is a coding style that organizes code into "objects" representing real-world entities. Think of objects as digital containers holding data (called properties or attributes) and actions (called methods or functions) that belong together.
OOP is a fundamental concept in many modern programming languages. Even if you’re not writing any code in your job, getting familiar with thinking in terms of objects can make a big impact on designing an experience that’s not only intuitive to use but that’s also resilient and scales well over time.
Three key concepts to understand when working with OOP (that we’ll probably dive into more another day):
Classes and Instances: Classes act like blueprints that define the structure and behavior of objects, while instances are the actual objects created based on those blueprints. This distinction allows you to create multiple objects with the same structure and behavior but with unique data.
Inheritance: This concept allows you to create new classes that build on existing ones, inheriting their properties and methods. When used smartly, inheritance promotes code reusability and makes it easier to manage complex systems.
Encapsulation: This is the idea of bundling related data and actions within objects. Encapsulation helps you keep your code clean and modular by separating concerns and preventing unwanted interactions between different parts of your code.
Prompts
Design a fake OOP-based system: Sketch out a simple system using objects, like a school, a zoo, or a line of cars (like the image above). How would you structure the objects and their relationships?
Resources
Craft
Always be bargaining
Good software is the result of a million trade-offs.
I know something’s wrong in the design & dev cycle of a company if there isn’t some bargaining going on.
On the one hand, if product or design is always winning then the odds are you’re forcing some dumb technical choices on the engineering side that you’ll live to regret. And on the other hand, if engineering is always winning you’re likely either playing it too safe or getting lost in the weeds of engineering for its own sake.
Embrace the fact that a bit of a tug-of-war actually results in better outcomes. Bring a strong POV to the table, argue for it, and if it doesn’t hold up, let it go. It’s all a part of the process. Be respectful, remember you’re on the same side, and then fight to the death! Just kidding 🤣. Talk it out, negotiate, go forth, and prosper!
If you got a little value from this post, consider subscribing, sharing, or following me on Twitter. If you got a lot of value, consider pledging to support my work with a paid subscription in the future.