Miguel Fernandez’s Post

Hypothesis: Design engineering as a role only exists b/c most designers can't build their ideas in high enough fidelity. Therefore the scale of the role is inversely tied to adoption of new tools that empower designers to contribute to prod. We'll all be "builders" in the end. Thoughts?

This is so true... To achieve a desired product launch, the project or product team must work in synergy. Thats only when transparency, inspection, and adaptation can be optimally incorporated.

🔄 Designers, put yourselves in developers' shoes, and developers, please do the same!🔄 🛠️ What makes a good engineer from a designer’s perspective? Let’s be real: design is often ambiguous, and specs are rarely perfect. That’s just part of the game! 🎨 So, here’s my request to engineers: embrace the uncertainty. The best products come from collaboration, and that means being proactive and open to ideas, even when the details are a bit fuzzy. Good engineers thrive in ambiguity. They don’t just wait for all the answers - they dive in, communicate constraints, and engage with the problem. When they care about user feedback and share their opinions, that’s when the magic happens! ✨ And designers, let’s be okay with engineers being opinionated. When we build great products, conflicts will arise because we sometimes have different goals, metrics, and KPIs. Developers want to resolve tickets quickly, while designers want to see their designs prioritized. But at the end of the day, we all want the same thing: a better experience for our end users. A few tips for better teamwork: - Pair up for brainstorming: Let’s chat early on to discuss design rationale and potential edge cases. - Skip the ticket sometimes: I know we’re all big fans of Agile, but instead of just opening a ticket, hop on a call to share the context and impact of the design changes. It makes a world of difference! From my experience, when I provide solid data and clear context, engineers are more engaged and come up with thoughtful solutions. 🧠💡 #UXDesign #Collaboration #ProductDevelopment #DesignThinking

Product Brief's aren't written BEFORE design happens. They're written FROM design happening. The Design Process—solving the right problem + solving the problem right, if you want to (over) simplify it—is discovery. It is the process of understanding what the opportunity or problem you're working on truly is, what it means to truly address it, and what solutions will achieve those objectives. The details of a Product Brief: problem statement/framing, contexts, audience details, goals, and solution are discovered and refined through the design process. Separating Discovery and Design, or trying to define these details concretely before the design process has started leads to confusion and frustration in teams. Treat the creation of the Product Brief as an output of the Discovery process. Work collaboratively—across PM, Design, and Engineering—starting from the general problem statement and goals identified. Use the Design process to explore what the problem or opportunity really is and identify a vision for how it can best be solved. Then work to iteratively define solution details, adjusting for capacity and opportunities to learn from real users.

EFFECTIVE DESIGN THINKING FOR ENGINEERS Design thinking is a problem-solving approach that emphasizes empathy, creativity, and iterative prototyping to address complex challenges and develop innovative solutions. When applied effectively by engineers, design thinking can lead to the creation of products, systems, and processes that better meet the needs of users and stakeholders. Here are some key principles and practices for engineers to adopt in order to leverage design thinking effectively: Empathy: Engineers should strive to understand the needs, preferences, and pain points of end-users and stakeholders through interviews, observations, and surveys to gain insights into users' experiences and requirements. Define the Problem: Clearly define the problem that needs to be addressed. Engineers should focus on identifying the underlying needs and objectives of users, rather than jumping to solutions too quickly. Generate Ideas: Encourage brainstorming and ideation sessions to generate a wide range of potential solutions to the problem. Engineers should explore diverse perspectives outside the box to come up with innovative ideas. Prototype and Iterate: Build quick, low-fidelity prototypes to test and validate potential solutions. Engineers should be willing to iterate and refine their designs based on feedback from users and stakeholders. Rapid prototyping allows for learning and improvement throughout the design process. Collaborate Across Disciplines: Design thinking encourages interdisciplinary collaboration, bringing together engineers, designers, marketers, and other stakeholders to work towards a common goal. Engineers should be open to collaborating with experts from different fields to gain diverse insights and perspectives. Embrace Iterative Design: Design thinking involves an iterative approach, with multiple cycles of prototyping, testing, and refinement. Engineers should be comfortable with ambiguity and uncertainty, embracing failure as an opportunity for learning and improvement. Focus on User-Centric Solutions: Engineers should prioritize the needs and experiences of end-users when designing solutions. User-centric design ensures that products and systems are intuitive, accessible, and meaningful to those who will use them. Communicate Effectively: Clear and effective communication is essential for successful design thinking. Engineers should be able to communicate their ideas, concepts, and prototypes to stakeholders in a way that is understandable and compelling. Stay Flexible and Open-Minded: Design thinking requires flexibility and adaptability, as solutions may evolve and change based on user feedback and new insights. Engineers should be open-minded and willing to pivot if necessary to achieve the desired outcomes. By incorporating these principles and practices into their work, engineers can leverage design thinking to drive innovation, solve complex problems, and create meaningful impact for users and stakeholders.

Engineers are very expensive. Here's a simple trick on how to save some money. Are you ready? The game is: You cannot code ANYTHING until your customers like the solution, find it valuable, and know how to use it. How? Start with the prototype. Use Figma or paper. Create initial designs of the solution you're thinking of. Don't write code. Not yet. Once your prototype is ready, show it to customers. Gather their feedback. See how they interact with the design. This step is crucial. It tells you what works and what doesn't. Open your eyes, open your ears. Iterate based on their input. Refine the design. Change the experience. Make changes until your customers like experience and find it valuable. Only then, start coding. If they don't like the solution, even if you iterated - trash it. That's the money you saved. To compare: if you're good, the prototyping phase takes a few days of work from the product designer and product manager and a few days to interview and iterate. After that, you're pretty much sure what to build and what impact to expect. That work is relatively cheap compared to building something by a team of engineers working full time for a few months without knowing whether the solution will be valuable for the customers. This approach saves you from building features nobody wants. It prevents costly reworks and wasted efforts. By involving customers early, you ensure the product meets real needs. You also build what is sure to resonate with your target users. Prototyping before coding isn't just smart; it's cost-effective. Remember, a dollar saved in unnecessary development is a dollar earned towards your product's success. Put your customers first. Let their feedback drive your development cycle and save big. This is how you build great products. There, I saved you tons of money. #productdiscovery #figma #prototyping

Engineers are very expensive. Here's a simple trick on how to save some money. Are you ready? The game is: You cannot code ANYTHING until your customers like the solution, find it valuable, and know how to use it. How? Start with the prototype. Use Figma or paper. Create initial designs of the solution you're thinking of. Don't write code. Not yet. Once your prototype is ready, show it to customers. Gather their feedback. See how they interact with the design. This step is crucial. It tells you what works and what doesn't. Open your eyes, open your ears. Iterate based on their input. Refine the design. Change the experience. Make changes until your customers like experience and find it valuable. Only then, start coding. If they don't like the solution, even if you iterated - trash it. That's the money you saved. To compare: if you're good, the prototyping phase takes a few days of work from the product designer and product manager and a few days to interview and iterate. After that, you're pretty much sure what to build and what impact to expect. That work is relatively cheap compared to building something by a team of engineers working full time for a few months without knowing whether the solution will be valuable for the customers. This approach saves you from building features nobody wants. It prevents costly reworks and wasted efforts. By involving customers early, you ensure the product meets real needs. You also build what is sure to resonate with your target users. Prototyping before coding isn't just smart; it's cost-effective. Remember, a dollar saved in unnecessary development is a dollar earned towards your product's success. Put your customers first. Let their feedback drive your development cycle and save big. This is how you build great products. There, I saved you tons of money. #productdiscovery #figma #prototyping

Designers should code and here's why...👇🏻 1. Better engineering collaboration 2. Improved design implementation 3. Enhanced problem-solving 4. Streamlined workflow 5. Empowered to iterate 6. Stronger product ownership Incorporating coding into a designer’s skill set not only enhances personal growth but also strengthens team dynamics and product outcomes. Embrace coding and see the difference it makes! 🚀👨💻 Do you code? #design #doding #collaboration #productdesign #designsystems

Engineers are very expensive. Here's a simple trick on how to save some money. Are you ready? The game is: You cannot code ANYTHING until your customers like the solution, find it valuable, and know how to use it. How? Start with the prototype. Use Figma or paper. Create initial designs of the solution you're thinking of. Don't write code. Not yet. Once your prototype is ready, show it to customers. Gather their feedback. See how they interact with the design. This step is crucial. It tells you what works and what doesn't. Open your eyes, open your ears. Iterate based on their input. Refine the design. Change the experience. Make changes until your customers like experience and find it valuable. Only then, start coding. If they don't like the solution, even if you iterated - trash it. That's the money you saved. To compare: if you're good, the prototyping phase takes a few days of work from the product designer and product manager and a few days to interview and iterate. After that, you're pretty much sure what to build and what impact to expect. That work is relatively cheap compared to building something by a team of engineers working full time for a few months without knowing whether the solution will be valuable for the customers. This approach saves you from building features nobody wants. It prevents costly reworks and wasted efforts. By involving customers early, you ensure the product meets real needs. You also build what is sure to resonate with your target users. Prototyping before coding isn't just smart; it's cost-effective. Remember, a dollar saved in unnecessary development is a dollar earned towards your product's success. Put your customers first. Let their feedback drive your development cycle and save big. This is how you build great products. There, I saved you tons of money. #productdiscovery #figma #prototyping

Engineers are very expensive. Here's a simple trick on how to save some money. Are you ready? The game is: You cannot code ANYTHING until your customers like the solution, find it valuable, and know how to use it. How? Start with the prototype. Use Figma or paper. Create initial designs of the solution you're thinking of. Don't write code. Not yet. Once your prototype is ready, show it to customers. Gather their feedback. See how they interact with the design. This step is crucial. It tells you what works and what doesn't. Open your eyes, open your ears. Iterate based on their input. Refine the design. Change the experience. Make changes until your customers like experience and find it valuable. Only then, start coding. If they don't like the solution, even if you iterated - trash it. That's the money you saved. To compare: if you're good, the prototyping phase takes a few days of work from the product designer and product manager and a few days to interview and iterate. After that, you're pretty much sure what to build and what impact to expect. That work is relatively cheap compared to building something by a team of engineers working full time for a few months without knowing whether the solution will be valuable for the customers. This approach saves you from building features nobody wants. It prevents costly reworks and wasted efforts. By involving customers early, you ensure the product meets real needs. You also build what is sure to resonate with your target users. Prototyping before coding isn't just smart; it's cost-effective. Remember, a dollar saved in unnecessary development is a dollar earned towards your product's success. Put your customers first. Let their feedback drive your development cycle and save big. This is how you build great products. There, I saved you tons of money. #productdiscovery #figma #prototyping