1. Infuse UX Design insight into the previous PM and UX Researcher insight to create initial designs – After the PM has validated their hypothesis with the UX researcher, they will work with the UX designer to create the initial designs.  At this stage, the UX Designer gains an understanding of the product goal and the strategies the Product Manager has proposed to achieve it. The designer then determines how this goal (and its related strategies) can be achieved given company design standards/patterns while also taking into account all of the items mentioned above (UI elements available, human psychology, design complexity, etc.).  The designer will also most likely simplify any preliminary designs you had in mind with respect to how the solution should look. Trust me, you may think you have the perfect design in mind, but it can and will be improved by your designer.
2. Redesigning initial designs based on engineering constraints – In this stage, engineers will take a look at your initial design to determine what is feasible based on the current technical architecture/infrastructure.  Note: engineering work has not started yet! Your engineers will tell you which aspects of the design can be done in your desired timeframe and which would take longer to implement. If you are on a time crunch to release the product and the ideal solution requires more engineering time than your engineers currently have allocated, you will have to re-design your solution to acommodate the current engineering constraints.
3. Re-designing after feedback from user concept testing – Before you release the design publicly, your UX researcher may suggest they conduct a user concept test to see if the new design resonates with members of your target audience. This concept test will give initial insight into whether your solution will actually facilitate in fixing your member problem. If many users deem that the design is confusing or the design does not efficiently help the member complete the desired task, then you, the PM, must work with the designer to re-configure the design. After completing the redesign, I highly recommend showing this new design to your engineering counterparts to ensure the new design does not clash with any other engineering constraints.
4. Redesigning the solution if new requirements or engineering constraints are uncovered. At this stage, the hope is that you will not have to create any new product requirements or that your engineering team has not uncovered any new design constraints which can extend your launch timeline or cause you to have to re-design your solution. Unfortunately, this is the real world, and sh*t happens. If you do get to this stage and have to create new requirements or find new engineering constraints, then you will have to work with the designer to create a new design solution. **insert sad face**

Two things you probably noticed when reading that last section:

1. This flowchart is considerably longer than the flowchart presented in our first best friend article “Why Your UX Researcher is Your Best Friend”. That’s because UX Researchers tend to have distinct points in which they interact with product teams, while the designer works with the product throughout the entire development process from start to finish (or at least they should).
2. You may be wondering, “Why don’t you include engineering first and then go to design? Or engineering and design simultaneously?” This is a personal decision that you have to make, or you may need to follow the standards of your company. From my perspective (and this is subjective), the possibility of engineering constraints is higher than the possibility of design constraints. Design tends to naturally be more flexible than engineering. For example:

   The designer can say “Sure, let’s add a button in this section and add another item in the drop-down menu.  It would make sense for the user to be able to access the feature here.” 

   While the engineer says, “Well, we could add a button in this section, but we only have room for one button (which is already there), and to add another button, we’d have to reconfigure the entire section, which requires significant validation work to ensure we don’t compromise functionality. For the additional item in the drop-down menu, we would have to work with any downstream teams (who rely on the data in the menu) to ensure that their systems accurately use this new item selection. Adding the button and new item would probably take an additional quarter of engineering time.”

See the difference?

The possibility of design constraints limiting your maximum level of creativity for the initial designs is lower with design than with engineering. When developing initial designs, you should limit the effect that constraints have on the creativity, innovation, and magic that you and your UX designer can create. That’s why I recommend approaching your engineering stakeholder after you and your designer come up with the IDEAL solution. Who knows, you may impress your engineering manager so much that they get extremely excited about your design solution and they’ll dedicate even more engineering resources than originally planned! Now you have your button and your drop-down selection item. Voila! It’s magic! You’re welcome.