Design Reviews
For design teams, crits and design reviews are opportunities to share, learn, build on each other's ideas, and create a shared purpose. They are a key part of the design team's process and foundational in building a design culture.
Design reviews allow team members to express their goals, craft, and communicate their intentions in an open, friendly, and safe forum to test out ideas and stories. They provide recognition of team members' contributions, creating a culture where everyone's work is valued and brings visibility to areas of the team that might not get high profile executive reviews.
Design reviews also allow all design related disciplines, from research to front-end, ops, and UX engineering, to share their work and gain insights from the team. These disciplines all contribute to the team's success, and design reviews provide a platform for them to showcase their efforts.
Design reviews are different from product reviews, and this can create conflict in expectations for participants.
Product reviews need to have explicit goals, with the intent to drive product decisions forward and make progress on achieving key outcomes. Clarity is critical, as there are multiple stakeholders in product reviews, including marketing, engineering, and product management. Problem/Solution framing is crucial to show how the design addresses or makes progress to deliver results, whether the hypothesis was valid, what customer feedback and data were gained, what metrics were impacted, and the quality of the experience. Most importantly, product reviews determine what gets cut or built and whether the right things are being prioritized to deliver results.
领英推荐
Product reviews can become frustrating, as business and technology discussions can often overshadow the customer and user experience aspects. This can create a mismatch of expectations when design teams are in the exploration and concepting phase and seeking expansive input rather than convergence towards a single design solution.
Product team leaders, especially in engineering, are often overwhelmed by workloads and backlogs. When design teams come with more ideas, there can be pushback or a whiplash effect that can be deflating. The constant "no, can't do this”, “we don't have time" or "when is design done", “design is gating us”, "are you dragging or rushing" can be demotivating. Design leaders need to help the team navigate product reviews effectively by setting clear meeting agendas and doing the background work to set up the team for success. You need to build influence and set the framework for the right discussions at the right time with the right set of stakeholders.
Design leaders must recognize the differences between design reviews and product reviews to set up their team for success. Create the appropriate framing, set expectations for the team and for the participants. Be there for the team.
Design reviews build purpose, product reviews build products.?
Transformative Executive Design, UX, Brand, Product & AI Business Leader - Founder & President: Seichō Syndicate & SocioPunk | x Warner Bros. Discovery | NBCU | Microsoft | Global Speaker, Author, Advisor & Innovator
10 个月Great read and great context for all of those just entering the field of Design and reminder for those who have been in it “for a while” “Design reviews build purpose, product reviews build products.” - that’s the truth ????
Global Customer Experience | Director of Product Management | Nourishing a Better Tomorrow with Water, Soda & much more
10 个月I was a designer and design manager for a decade and today lead the Product management discipline in Strauss Water. There is definitely a distinction between product reviews and design reviews. There is also a distinction to Engineering reviews. I think it is crucial to keep these distinctions and not mix the reviews. The tricky part is realizing that feedbacks about design in Product or Engineering reviews will naturally occur, as Design maturally engages humans - Yes, even C-suites and engineers...However , once collected in the product reviews, these feedbacks need to be contextualized by the designers. Contextualized is not "automatically adopted" nor "automatically ignored if it doesn't fit my perspective", but rather: understood alongside all inputs in context of the target users, the brand, the project. Designers need to build confidence to hear the feedback and not feel the need to defend their design (separate design from designer). The design review should be super-professional in Design, and if Product managers or Engineers cannot respect the different vibe or content , they should not be present. BTW same rules apply for technical conversations in Engineering reviews, and economics in product reviews
Owner/Consultant at Mostar
10 个月I remember working with Chris Robinette on the GTM dates for Nike Timing. We referenced the Tour de France and the many ways to win the tour through the "other" jerseys beyond just yellow. The booklet we created kept us moving through the challenges of the product creation process. It kept us focused, included everyone at the table for design, dev and business line reviews. The deep dives and crits with des/dev still happened but in prep for these larger gates. It reinforced that every summit or intermediate sprint makes a difference. There are riders that have won the polka dotted jersey many times without ever winning the overall tour. Attention to detail throughout the process is critical. The process also provided awareness for everyone - who should be at the meeting, the deliverables, the decisions we are hoping to make and outputs from each meeting...
Product & UX Service Design Leader ? Speaker ? Professor ? ?? Top UX Voice ? Design serves humanity
10 个月The Purpose vs. Product framing is immensely clarifying for designers and for engineering, business and marketing functions. Most organizations in technology bill themselves as "learning organizations." However, when learning occurs that indicates a change needs to be made — often uncovered by design and design research — too many abandon this imperative and fail to apply that learning, sometimes for the reasons you have described. I'm curious if you are able share some cases of your own experiences of successful and failed reviews?