Upgrade to Pro — share decks privately, control downloads, hide ads and more …

UseCase.org | Collaborating with designers

Alpha
July 01, 2015

UseCase.org | Collaborating with designers

How might I encourage a designer to be more transparent and collaborative? I’m not asking to be an art director, I would just like to open a dialog about the goals of our product and the experience we want to create, but she’s very private with her work.

Alpha

July 01, 2015
Tweet

More Decks by Alpha

Other Decks in Business

Transcript

  1. Question of the week How might I encourage a designer

    to be more transparent and collaborative? I’m not asking to be an art director, I would just like to open a dialog about the goals of our product and the experience we want to create, but she’s very private with her work. Submitted by: Anonymous Product Manager at Humana Perspectives from Marc Sirkin Molly Barton Josh Wexler THE PRODUCT COMMUNITY Valla Vakili
  2. Read more best practices on Usecase.org Marc has spent the

    past two decades focused on creating change by enabling businesses to use new technologies to drive revenue. His focus on digital change and transformation has led him to work in both B2B and B2C, as well as inside startups and enterprise organizations. He has led diverse teams focused on product development, product marketing, and digital communications, fundraising and social media. MARC SIRKIN Marc’s Perspective Well, speaking as a former (frustrated) designer, I'd suggest that you try "Beginner's Mind," a Zen technique and strategy. Help the designer understand that there is never a 'perfect' design or answer, instead, there are only choices. I'd suggest trying to build some rapport in-person and focus on finding things in common you can discuss, perhaps around creativity, design or art, but not the project itself. Perhaps they can be referred to amazing books on design and creativity (Creativity, Inc. or others) for example. I know for myself, I was HYPER sensitive to showing anything before it "was done" and refused to collaborate because my ego wanted to be the "design guy" - it took a very hard conversation and some time for me to feel comfortable enough to open up, but eventually, I did. And as a result, my designs got a hell of a lot better, and clients loved my work even more than they did before that. There is another way, which is to put some formal process in place, we have a workshop methodology that is deeply collaborative and you can't escape the transparency of it...and it changes how you look at problems when you are working alongside senior execs.
  3. Valla Vakili is a media and technology executive with a

    record of delivering product innovation and revenue growth in rapidly changing industries. He combines creative vision and business acumen to enable companies to anticipate and adapt to changing markets and opportunities. VALLA VAKILI Valla’s Perspective I suggest involving the designer early and often in the project, well before any actual design work is necessary. Product teams too often bring in the design team when they “need designs,” which is too late. Designers should be involved early, when user needs are being articulated, so they can have an early grasp of the problem being solved and the various stakeholders for the new feature/product/release. Bringing in your design partner early helps build trust and collaboration when no work output is at stake—and hence no judgment of the quality of that output. If by contrast your design partner feels you only come to them when you have “specs” and “need design” they will on the one hand feel left out of ideation/concepting and potentially also feel especially under the gun as the only work that’s often interrogated is design output. Involve them early and let them interrogate product requirements/user needs and I find this tends to go away. Finally, in design review meetings, I’d suggest staying away from subjective comments on the design and asking instead how the proposed designs address the stated needs, what alternatives were considered, and how the designer feels about the proposal—where does it stand tall, and where does it need work. This helps focus in on the thought process which tends to foster trust and collaboration versus a pure critique of the work product. Read more best practices on Usecase.org
  4. Barton has held marketing, editorial, business development, and digital strategy

    roles at Oxford University Press and Penguin, the world’s most recognized publishing brand and one of the world's largest English- language trade book publishers. Most recently she was Global Digital Director at Penguin Random House, reporting to the worldwide CEO and leading the digital business. MOLLY BARTON Molly’s Perspective Sharing information is usually only comfortable when there is a baseline of confidence and trust. It sounds like you’re either lacking confidence in her work and scared to share it or she doesn't trust how the shared information is going to be used. I'm not sure how big your team is or what the reporting lines look like, but she may also be trying to follow direction from her supervisor. Check on the reporting line / supervisor directives bit by quietly asking someone else you trust in the company who will know. Once you've eliminated that as a factor, a solid approach in this situation is to model the behavior you want to see -- try including her a bit more into your own work on the product side. Share with her your thinking, your approach to problem solving, and solicit her advice on your work or a particular issue you're currently facing. Spend time with her when you're not talking about the project at hand. Talk generally about how collaboration in the company works and point out good examples of when it's succeeded. Ask her non-threatening questions about design work at other companies. Show genuine interest in her views and share your own honest opinions to establish a deeper rapport and level of trust. In a few weeks time, circle back to your own product and the experience you want to create for your customers and see if she is more open to sharing. You need to have laid the groundwork in the weeks prior, so that she understands why you're wanting more visibility in to her process and what you're going to do when you have more visibility, so she doesn't feel threatened or encroached upon. Read more best practices on Usecase.org
  5. Josh is an expert on early stage software innovation. As

    a Solutions Director at Originate, he develops new business and helps potential partners shape their ideas into projects. He has advised global consulting firms, financial services companies, and early-stage entrepreneurs throughout every stage of the software development process, ranging from ideation and validation to fundraising rounds and commercial launches. JOSH WEXLER Josh’s Perspective There’s two sides to the answer: the process and the people. The people side is much more interesting. I’ve been working with a lot of designers that’re driving me bonkers, and I think the reason is because they’re often formally trained to take and give criticism. In a way, they’ve been scarred by a process that is critical rather than constructive and iterative. They expect that you are going to also criticize them, so they ensure that they only show you something once it’s perfect. But product management isn’t about criticizing, it’s mostly about problem-solving. For me at least, understanding where designers are coming from has helped me, so making clear to them the shift in modes from ‘critique’ to ‘problem solving’ and ‘here’s what that looks like.’ To quickly touch on the process part of the answer, it’s one thing to consider forced reviews, but there are two key elements that I see in terms of getting designers involved in the right way. The first one is as a product manager to bring them in to the earliest discussions. They need to feel involved in the process from customer discovery onward. The second is designer training. They think they iterate like crazy, but for them iterating is a private process until they get to perfection, and then they make minor improvements. Help and teach them to structure iterations involving other stakeholders. Read more best practices on Usecase.org