How do you optimize product design for user experience?

The key here is: “Fall in love with problems not solutions.” A repository of complaints and feedback is a great place to start (from Sales, Customer Support, etc.), but the biggest innovations often come from taking a step back and doing fresh ethnographic research. Pick an area that relates to your company’s strengths and/or emerging technologies, and keep an open mind. When you find yourself deeply attaching to a solution idea (almost inevitable), hold it lightly and stay more fixated on the problem it solves.

Talk to end user multiple times & see the patterns in conversation. Collect feedback from all user groups including testers. Document and refine the understanding at every stage.

One of the things where most people make mistakes is assuming that they completely know their target audience. No matter if you have done projects in the same domain before, always start your research fresh as if it were the first time. And combine previous research in a later stage. In contrast with company directors and stakeholders, product designers must advocate for their users and figure out what's best for them. What exactly do users want. In my experience, some of the templates from Figjam have been extremely helpful for conducting better and yet faster research.

You have to build relationships between Design & Engineering. Asynchronous communication, and proactive engagement to understand the problem, leads to asking questions. Creating a cadence between teams generates space for curiosity, insights, feedback, and customer survey data. Sequencing team structure to communicate across disciplines ensures that all scope items are considered. The standard practice here is gathering data from customer pain points, but internal alignment confirms you're solving for the right thing, to understand what users actually want.

Low-fi is generally the way to go at this stage: quick and dirty. All you’re doing is vetting ideas and assumptions in order to better define the solution. For example, if you think an app is the solution to a given problem, you can use screen mockups to walk through when and how the app might be used in real-world situations. At the end of this step, you should have a healthy starter list of major features and design constraints that lead to value for customers. Note that it’s *common* for brilliant ideas to get completely tossed out at this point (leading back to step 1), which is why it’s important to hold ideas lightly. Too often companies commit too early to a solution, which leads to building the wrong thing.

Creating paper wireframes is a great starting point. It gets the ideas flowing without the overhead of trying to prefect something. Capitalize on generating as much ideas as possible then start refining them. A great approach is highlighting parts you see fit in each of the designs you drew, then try to combine it in one awesome design.

I have met a few designers who directly open their design software and jump on creating designs. But for me, the best way has always been going old school - pen and paper. And the second thing is that no idea is a bad idea for a prototype. Those kinds of restrictions only restrict your creativity. I for one always pen down every and any idea I have. Once I have all those ideas on paper only then I start comparing them and use the rule of elimination.

Depending on the company size, this can vary greatly. Prototyping with a jumbled design system, where products are visually different, or utilize inconsistent patterns, you can waste valuable resources. Start with a User Flow Map (or User Journey), and pair with sketching boxes on paper, or white-boarding with sticky-notes. To test an idea, visibility is crucial to validate movement towards a lo-fi or hi-fi prototype in Figma or XD. If a validated Design System exists, the above items are still required, but it's less invasive to use this system to build something and may provide clarity for design validation.

More often than not, end users or stakeholders do not know what they want. The onus lies on developers to guide and lead them to express what features in the product would help make their life easier. I like the concept of tracer bullets elaborated in ‘Pragmatic programmer’ book by Andrew Hunt. Similar to prototyping but with a few differences. The idea is to build working features end to end and let users or stakeholders experience it. You get the feedback early and helps you optimize the user experience. Other ways from a software perspective are to use tools like Figma or Adobe XD and mock the products.

Data-driven iterations is one of the strongest approaches for design improvement. Also, as designers we need to remind ourselves to be flexible and open to changes.

According to me understanding business goals does not directly improve user experience. But I still think it's important to do it. For one, You need to present your design to stakeholders and directors and they don't exactly understand UX so as a product designer you translate the UX perspective to how it will be useful for business, because that's the language they will understand. And second, Understanding business goals helps you to figure out the overall scope of the product/project. Because honestly if you want a perfect UX, it can be an overkill or what they call - going overboard. It's always better to understand the business value proposition to avoid future frustrations from both ends.

Just as we put the user front and center of the experience, we should always refer to the business value proposition. In my opinion, the business value proposition sums up many business goals as well as the brand identity. Harmony between the user needs and the business value proposition yields a great user experience.

As Designers, we must consistently create a story for our design work. Buy-in is required at every step. This story should accommodate the goals of the target stakeholders. Translating your design decisions to how they align with Business Value or the Business Proposition provides clarity to outcomes. You're able to remove noise from the process of defining scope, while evaluating how to solve the problem through design.

Engage with engineering EARLY and OFTEN! The same holds true for engineering too. Additionally, engagement between all stakeholders should happen early and often. Asyncronous, weekly, Sprints Standups, Agile, whatever method is used, the earlier this communication begins, the better. The alignment reduces friction, and provides a platform for collaboration to understand what is possible on both ends, and what each needs to fulfill requirements. If you avoid this, and simply design a full product, chances are there will be extra work to adjust, change, or start over. (It happens to us all at some point)

This is something I can't stress enough. In my experience as well. A lot of times we as designers design a product that might not be technically or financially feasible. And altering your finished product to fit all the brackets is quite stressful and depressing. What I have started doing is, that after my research is done and I have a list of functionality/feature list in my hand I discuss that with other teams before sending it to the high-fidelity phase. This extra step helps me minimize extra changes in the end.