Making smart design decisions is harder than you think. First, you have to give up your personal preferences. Second, you have to scan yourself for biases refusing to consider alternative points of view and third, you must use data to design a product beneficial for the end user.
Today I’m talking to Jocelyn Lin. She is a Director of Design for Yahoo and Polyvore, where she manages a team of designers to create engaging experiences for Polyvore’s global style community. Prior to joining Polyvore, Jocelyn was a staff UX designer at Google, where she led design initiatives for Google Maps, Image Search and Universal Search. Prior to working at Google, she was a product manager for Oracle.
Read on to find out how to inspire, empower and lead design teams and make smarter design decisions.
Can you tell me a little bit about your role as Yahoo’s Director of Design for Yahoo View and Polyvore?
I lead a team of designers, but I am the most effective when I can get out of their way to let them do their best work. I do this by setting up product and design processes, reaching out to cross-functional leads, facilitating collaboration, and giving strategic product feedback. When things go awry on projects, I help play detective to find the source issue, and give my team any backup they need to resolve it. I also actively mentor my team to help them improve their skills and work on their career paths. In a pinch, I will play at being an actual designer too, but frankly, it’s better done by my team.
What do you consider to be “smart design decisions” and what are some examples of successful techniques?
A “smart design decision” is a decision that helps you move the design forward for a product. To do so, you need to have a good sense of your project objectives, and whether they are business or user-focused. Clear and early communication with your engineering, product, and marketing partners will correctly define the objectives before you get started. When you reach a crossroads, identify the most divergent paths at the highest level possible, decide with the right people in the room, and move on. By the highest level, I mean for example, that it’s useless to discuss color options when you haven’t nailed down the navigation model.
What are effective design review processes that have worked for Polyvore specifically?
Instead of a typical approval process, we have a twice-a-week peer review session. While everyone gives feedback, it’s up to the individual designers to decide what to do with it. This gives the team ownership over their own work, and they also realize the responsibility of being able to decide and consider feedback carefully. It’s a collaborative environment where we all work together to improve products, rather than the more traditional design critique where the presenter is often on the defensive.
For those presenting, they set context first before going through the design, and that includes the level of feedback they are looking to receive — is this an early interaction concept or a final visual icon? On the reviewer side, while suggestions and solutions are certainly welcome, they ought to be phrased in terms of the problem so that the designer isn’t just applying feedback blindly. For example, instead of “I think you should add more thumbnails”, one could say “I don’t get a sense of how much content the site actually has. One option is to add more thumbnails. Or ...”
As a design lead, I serve as a moderator, eliciting feedback from everyone and making sure we stay on task — not trying to design in the session, that would take too long! I also wait for my team to give their feedback first and only say something if I have something news to add at the end. This ensures that the session is owned by the team, not the boss. Or, at least I try. You can ask my team how well that’s going.
How has Yahoo View created engaging, smart designs, and how can others adopt similar techniques?
We had a short window to launch Yahoo View, so we quickly had to determine our product strategy. This ended up being a combination of barebones “tablestakes” must-have TV features plus some experimenting with delightful differentiators. For watching functionality, after identifying major user flows and doing a quick competitive analysis, we easily came up with a list of basic features. Differentiators are a little harder. We partnered with research to understand who our potential users and their motivations and behaviors are. From there, to narrow down brainstorm ideas, we user-tested some very different concepts at the storyboard and static prototype stages before committing the full design, engineering, and product resources to build them out.
What leadership skills have you implemented in your role managing designers? What soft skills should other managers implement for smarter designs?
I’ve found these two skills to be the most handy as a design manager.
One, the ability to analyze process and progress, then to make adjustments to improve them, results in a team that is happy with their work. For example, if a designer is not getting enough time to make good design decisions, I need to figure out whether it’s because product goals aren’t clear, timelines are unrealistic, or there’s an inefficiency, before I can help fix it. The solution then could be something like better integration of design into scrum, setting up more frequent reviews, or creating new Sketch templates for team reuse. Solving things at the process level improves things going forward for the whole design team.
Second, I’ve found the ability to understand the reasoning behind what people say to be invaluable. In heated discussions, it lets me surface the core point, which cuts the meeting time in half and brings forward the one item that people are trying to decide upon. This allows a direction to be set, which then allows for better design.
To make all of this work, I need to know when to step away and when to step in. I like to think of it as developing a stress radar — it detects how individuals are doing with their projects, and whether it’s a healthy stress from an intense project or an unhealthy one from interpersonal conflict, for example.
How do you avoid wasting time designing things that won’t get built? How do you make sure that everyone agrees on the next steps?
There are cases where we intentionally design things that may not get built or launched, for learning purposes. User research prototypes and bucket experiments fall under this umbrella, and as long as the team understands that killing ideas actually leads to better product and more efficient use of time in the end, that’s totally okay.
On the other hand, there are cases where the poor designer is on iteration 15 of the design, either because the product goals are unclear or feedback is inconsistent. We’ve all been there.
To prevent that from happening too often, we need to start with a solid agreement and understanding of goals between the product leads, partners, engineers and designer. Easier said than done, of course. During a project, what you can do is, first, notice when things are starting to meander. At this point, it is wise to stop your work and put your efforts into solidifying goals with stakeholders. Think ahead, keep designs at a high level, focusing on user flows rather than detailed wireframes until direction is more set.
How can you elicit feedback and input in an effective way?
When seasoned designers show work to each other or to cross-functional partners, they first identify who the stakeholders are, and whether it’s best to connect in a formal group presentation, casual desk show-and-tell, or an intimate 1-1 conversation. Each one has pros and cons, and really depends on the personality of your particular stakeholders.
During the session, they start by setting context on the project and goals they’re trying to solve. Then, they either state the level of feedback they’re looking for (pixels and specific copy? product strategy?), or point out the specific elements that require opinions. This gets everyone on the same page and results in more relevant feedback.
After the session, it’s a good idea to follow up with written summaries of what was agreed and action items, because making it concrete will expose any misperceptions among the participants. It’s kind of surprising how everyone can seem to agree in person but a week later, have entirely different takes on the conversation, but it always happens! This can be done casually, over chat, or more formally over email.
Update: after publishing the article I've clarified Jocelyn's position.
(Source: Tomas Laurinavicius, Forbes, FEB 5, 2017 <http://www.forbes.com/sites/tomaslaurinavicius/2017/02/05/smarter-design-decisions/2/#5513d24d76d3>)
...
Dr. YS RAO
