PRO/Design

PROdesign

I was invited to speak at Nasdaq’s first PRO/Design conference, a free one-day conference about building design-driven companies. This is a brain dump of the experience, highlights, and major takeaways.

PROdesign

The Beginning. It all started at an informal UX Happy Hour meet in August where, I met Chris Avore, a Product Design Lead at Nasdaq. We had a great conversation about the dividing lines between product and UX teams, transitioning from one to the other, and the ideal ways to approach design in a company. A few weeks later, Chris pitched an idea: what if I presented at conference about design-driven companies? Obviously I said yes! The real question is how many exclamation points I used when I responded…

The Preparation. Then came the preparation. As I thought about the experiences and ideas I felt strongly about sharing, I returned to the idea that design isn’t a singular responsibility. Serving as a visual or UX designer doesn’t mean maintaining complete ownership over the company’s design; it should be a collaborative process. I used my experience at a Product Manager at a growing start up as a foundation to progress through what it means to move towards design-driven in a company.

The title, you ask: No One Team Should Have All That Power: Understanding Who Owns Design in the Product Development Process. Yes, that is a Kanye West reference.

Pre-Game Time. I arrived to New York on Thursday, January 29th – the day before PRO/Design. First stop: Totto Ramen, because New York ramen is fabulous. Second stop: PRO/Design pre-conference happy hour to meet the presenters and planners.

I met the Nasdaq Product Design team that, on top of their already demanding job-work, was turning this brilliant brain-child into a living, tangible thing. In their spare time. Huge kudos and lots of hats tipped off. Though, the best part was their genuine and unabashed excitement about the attendees, presentations, and network opportunities. The good energy in that room was contagious and I knew tomorrow would be amazing.

On conference day, I was fitted with Madonna-style microphone piece which really set the tone for how dope the day would be. My talk was scheduled after Sofia Millares, who delivered a brilliant talk about design and communication. Then, game time.

Game Time! My presentation was a geared towards talking through who owns design in the product development process, because no one team should have all that power. What’s that mean? That design is important and lives at the heart of the user experience. I think it’s crucial that companies put user experience first, eliminate bottle necks, and establish design standards to empower everyone to contribute to design. But before I dove into these things, I introduced myself.

I graduated from Wellesley College with a degree in computer science and have a strong web development background. I went on to spend four years as a Product Manager at a successful startup in New York. (Note: I intentionally left the name of the company out of the presentation, but this is not a secret in my real life. If you’ve ever received a holiday card from me you know the answer.) I worked in a small team, so my role as product manager included a lot of user experience and interaction design work. I loved that part of my job and decided to switch gears, move from New York to Atlanta, and be a UX designer while studying HCI at Georgia Tech. Basically, I understand the importance of collaborating between development, product, and design. I framed my presentation around understanding this concept in the context of my experience at a startup that developed a design-driven approach to product.

So the main question: who owns design? Is it the developers that code the product? The designers that mold the visual experience? Marketing that promote the product? Stakeholders that fund the initiative? Or the product team that plans the product? The short answer is that everyone owns design! Design will play an equal role when it’s being shared and utilized by everyone. Then, the question becomes: how do teams go about sharing that ownership? How do teams better collaborate in the design process? How can accountability for design be better distributed between various teams?

Working at a growing startup means growing pains. They’re not bad – they’re a fact. On a normal day at the company, I coordinated with developers about features for users and visual designers about styles and experiences. I noticed what we’ll call a traditional design approach, in which teams focus on users or design. The company recognized both of these as important, but separate entities. As you can see in the diagram, teams began initiatives with the user or design in mind.

For example, we had an excellent customer support team that understood, respected, and valued our users. When customer support approached a situation, feature, or bug-fix, they had the user at the forefront of their mind.On the other hand, designers, stakeholders, and marketing approached with a design-first mentality. For example, we had a wonderful marketing team that understood, respected, and valued our design. When marketing approached a situation, feature, or bug-fix, they had the design at the forefront of their mind.

Now, both users and design are crucial. That much is evident. So what connects them? In this traditional design approach, there are bridges, such as product managers, connecting users and design. We were small enough to not have hired user experience designers, but they would also be considered bridges in this model. What’s my beef with bridges? Bridges aren’t technically a bad thing, but could create a bottleneck, especially if the company relies too heavily on them. In my experience, it created a situation where I was constantly balancing “the user is always right” with “show users good taste in design”, reconciling sometimes competing priorities. This could be made more efficient by repositioning my role to a contributor, instead of a bottleneck or a bridge.

Though, the most important thing I want to point out is that none of the teams in this model are wrong for their alliances. The challenge is that there is an alliance to be chosen at all. The product process is a collaborative effort in which all teams share responsibility and ownership. I believe that design facilitates collaboration within and among teams. To quote a modern philosopher and rapper, “No one team should have all that power.” By that I mean that no one team should own a process or a product. For example, customer support shouldn’t be the company’s only insight into the minds of users. Visual designers shouldn’t be the company’s only connection to their design standards. Product shouldn’t be the company’s only ally advocating for the design and users.

As the company grew, and there were more teams and more resources available, we experienced a shift to a design-driven approach, which focuses simultaneously on users and design, understanding that they balance and guide one another. As you can see in this diagrams, users are at the center of the model, the yolk of the design egg if you will. What does this mean? A design-driven approach, in this context is synonymous to a user experience approach, in which users guide the design process and the experience is optimized for their wants and needs. So, all of the teams are guided by design, and therefore guided by users. For us, this started by establishing a design vision. For example, we increased transparency around annual and quarterly metric goals and visual design standards, meaning that everyone could look to the design vision to guide their team decisions. This was us aligning on a design vision to empower each team to contribute to design.

Notice that the arrows are two-way between the teams and the design-egg-user-yolk? Not only is each team guided by design, but they also inform and contribute to the design. The possibilities here are endless, but the bottom line is that this is how teams share ownership. By establishing and aligning to a design vision, we empowered each team to utilize design in unique and powerful ways.This was an amazing evolution! All of a sudden teams had fluid conversations about users and design, and they were empowered to do so. This is also solid proof that growing pains lead to great things.

So, what lessons did I learn moving from a traditional approach to a design-driven approach? First, to align on a vision, mission, and goals. Establishing a design goal and standard helped us empower each team to use and contribute in unique and powerful ways. Each team’s use of design doesn’t have to look the same, as long as it follows the company’s design vision.

Second, empower everyone to contribute to design. We put users and design at the center of the company’s product development process and encouraged teams to craft an experience around those standards. By following that design vision, to create positive user experiences, teams effectively contribute back to the design. It’s a continuous cycle.

Third, always consider the user’s experience – they are, after, the yolk of the design. A design-driven approach is a user experience focused approach. Continuously start with the users and the design, and revisit frequently to reiterate the product’s focus on users.

Lastly, eliminate bottlenecks, for efficiency sake. In the traditional design approach, there were bridges connecting the user-first and design-first teams. Serving as a liaison is valid, but for us, product managers became bottlenecks. Remove unnecessary bottlenecks from the product process and enable teams to access design and users…leaving time for other bottles, like champagne!

Proof. Check out link to my presentation slides. I’m working on getting a recording of the presentation and Q&A session. Check back soon!

View Slides