Strong Opinions Loosely Held, Design Rules vs Guidelines

‍

‍This is a transcript of my talk to 800 designers and product managers at the Front Conference in Salt Lake City, Utah in May of 2018. My comments have been lightly edited for readability and clarity.

All right! How’s it been so far guys?

Look at this! I don’t know if you all know, but I’m one of the co-founders of the conference and it makes me extremely happy to see everyone here. It takes many months of planning for us to organize these events and it’s extremely joyful for me to see all of you here.

For those of you that don’t know me very well, I’m gonna explain a little bit about my history here. I’ve been in the industry for a little while. For the first five years of my experience, I worked in agencies. So, I was designing software. Some for ski resorts, for the Utah Symphony, things like that. In the last eight years of my experience, I’ve worked for software companies. And five of those years was for a company called Experticity and then I went to a company called INSTRUCTURE, If people know about it around here, for a little while and designed an App for some parents and then I went and worked a company called Needle, which is a sales chat software for companies in eCommerce like Nike, Adidas, Reebok, maybe you’ve heard of a few.

Now I am currently the product design director for jane.com and I have some wonderful things to share about that experience in this talk.

Going back to Front a little bit, we’re in an amazing venue don’t you think? Yeah. If you would have asked me four years ago if we’d be in this amazing venue, I would have just laughed at you. The first year we did Front, it looked like this. So Nate Barrett mentioned in his talk that there was a swamp cooler blowing down and dripping on him basically. That was that venue. So, we’ve come a little ways. In the year after that we were at a venue where it was a little bit more tight knit, still kind of raw. Then last year we were at the Living Gardner Hall. But, it’s amazing to be here with you guys today.

Let’s get into it. My talk is called Strong Opinions Loosely Held Design Rules Versus Guidelines. I’m going to start walking into what I believe is how we should structure our teams and I believe most companies these days are starting to structure their teams with engineering, product, and design cross functionally. I think we’ve heard a couple times here, the EPD models, Spotify Squad model. I think most of you here are very familiar with that. That’s a very good structure to have to break down barriers or walls that we have within our organizations. But I feel like there’s still some challenges that we continue to have, even though we’ve broken down the facades of the walls between engineering, product, and design, and I want to talk a little bit about those things.

At Jane.com, when I joined a year ago, we had one designer, one PM, and 30 developers and it just wasn’t a good environment to actually get stuff done and move quickly and make good decisions. So at Jane.com we’ve invested a lot into product. They hired on Taylor Fisher, our head of product and I was the second hire to be the product design director and we scaled that team from one PM and one UX to 11 of us now. We now have one PM, one UX, to five to six developers. That’s set a good foundation for us. I won’t lie, that it’s not perfect yet and we’re making that better over time.

I want to go into a little bit of what the focuses are of these different organizations and how it affects design. I’m going to look at it from the design lens, but from the perspective of these different organizations that we now work cross functionally with.

Engineering is constantly struggling to balance technical innovation and tech debt. That’s their focus and that’s what they think about all the time. Whether we’re sitting next to them or sitting in the other side of the building, their focus is this, product is struggling to balance understanding and efficiency and design is struggling to balance consistency and vision. People talk about this three legged stool and to make a three legged stool balance and sit on it, you have to have that balance of all those departments.

As a product design director, I am constantly asking myself these questions. As we grow as a design team at Jane.com, how can we become more efficient? We went from one designer to five designers. How can we scale that? If I went from five designers to a thousand designers like Cameron Mole at Facebook, what would I have to have in place to be able to accomplish those things and how does that effect the other organizations like engineering and product.

So, when I look at a new project at Jane.com, I look at them in these three different lenses. This is borrowed from Nate Walkingshaw’s Directed Discovery and how he decides on what to work on.

1. Innovation story (Is this a net new offering that we’re providing?)
2. Evolution story (Are we building on an existing feature?)

I’m going to focus on the first two today and talk about some examples of how we’ve gone through those two different experiences and how we have to look at them differently when we’re making our decisions. From the design lens, we’re going to look at these two different areas as innovation and evolution. When we look at something as an innovative, we think of things that didn’t exist. The iPhone, things like that. We all have little stipulations when it comes to software of what we think as innovation, and sometimes designers can get a little jaded if someone preaches to us that we can go create something innovative and it actually doesn’t end up being innovative, it’s just them telling us or giving us lip service.

Designer’s Reaction to Innovation Stories…

When we think about innovation as designers, this is usually our reaction when we want to do something innovative. We say, “Let’s throw away the thing that we have now and build something brand new!” Right? And it’s just how we think as designers. We just get super, super excited about innovation.

Engineer’s Reaction to Innovation Stories…

Engineers! It’s like, “Oh, I just went and built something, now oh, you’re going to go and erase it now, and I’ve just went and built something and now we’re going to erase it now.”

Product’s Reaction to Innovation Stories…

Product looks at it and says, “Okay, I’m gonna throw some money at it. Is it gonna come back? Or is it going down the drain? Am I gonna get it … are we gonna … where’s the benefit?” Right? When you talk to these people in these different organizations, that’s how they’re thinking and if we can work cross functionally in a way that we can improve upon that, that that’s where we need to go.

“There isn’t some rule that says only CEO’s or product people or designers or engineers or designated visionaries can come up with great ideas.”
 — Julie Zhuo

That’s the purpose of these cross functional teams and going into more autonomous or flipped upside down models for our businesses.  We have this really cool thing at Jane.com where any employee across the whole company can go and submit an idea whether you’re a customer service employee or whether you’re the CEO. You can go and submit an idea and it’s on a level playing field and we go and validate whether that’s a good idea or not. So, it’s all about the validation.

One of the big areas where conflict happens in having strong opinions loosely held is, if I go to the CEO and I say, “I have this idea. We should go test it.” Is my opinion the same level as his opinion? Is it at the same level playing field?

We get this question a lot in many of our meetings. “Who makes the final say?” I think we ask ourselves this question a lot, I think we ask our teams this question a lot is…“who makes the final decision on this?” I put a lot thought into this, so setting clear boundaries is important when we create these cross functional teams.

If we were to set some boundaries on what decisions are made by each disciple within our cross-functional teams I feel that we wouldn’t have to ask ourselves this question as much or struggle less with where our responsibilities lie.

1. Engineering — They decide and communicate the architectural and technical strategy.
2. Product — They decide and comunicate the research, business, market, and release strategy.
3. Design — They decide and comunicate the interaction, visual and usability.

If we can create those boundaries and respect each other, we can get a lot more done. What happens, too often, is when we don’t respect each other. When we cross those boundaries and we say, “I’m going to, actually, derail your decision on whether this is a good design or not.” As an engineer or as a designer I say, “You coded that wrong, so I’m gonna tell you to recode it, or I’m going to code it myself.” That’s when we derail ourselves.

“We, as humans, often need to see something to clearly understand it. And so those of us that have the ability to effectively convey an experience in an individual way posses a special and important skill indeed.”
 — Julie Zhuo

As designers, we have this ability to be facilitators, to create and visualize, not only our own ideas, but the ideas of anyone within the organization. That’s a big responsibility for us because, I don’t know about you guys, but sometimes I’m pretty selfish and I think I have a really good idea, so I’m going to make my idea look good because I have the control of the design, right? I don’t know if anyone of you have ever done that. I see you all raising your hands right now, so I appreciate that. I know, I know.

Julie refers to this as a North Star. What is an innovation or an innovative North Star is kind of where I want to go.

A North Star is…

1. A visual output (a video, a storyboard, a series of high fidelity designs)
2. It is a method to get everyone on the same page.
3. It is inspiration, so think six months out, a year out, maybe even farther.
4. Achievable (shouldn’t feel like science fiction)

So, when you’re deciding on a new project or there is a new thing and we want to build it, and it’s an innovation story, you have to think a little bit farther ahead. And it needs to be achievable. It’s can’t be science fiction.

What an innovative North Star is NOT…

1. Is the future set in stone. (I went and created this thing. Now we have to go figure out how to make it exactly the way that I showed it to you, the first time I showed it to you)
2. A feature that we already know we need
3. Just the design or just the redesign or a reskin of what we currently have
4. Something users know they want.

Innovative Thinking

I’m going to jump into a case study here of an innovation story that we were able to do at Jane.com. So, JANE is a marketplace for sellers to sell online. It’s a daily deal marketplace. We have 600 new products that change every single day on our website. Our website is a whole new set of different products every single day. And the process to make that happen is, I won’t lie, it’s laborious for sellers to go through that process. And a lot of these sellers, they want to be more mobile or they are more mobile and they want to be able to submit deals. The goal was, okay, as a seller, build a native App that solves the needs of 80% of our Seller’s Jane experience … that Jane needs on the go. So, right now all of our sellers, we have thousands of sellers, they have to go to a desktop to submit deals to run products on Jane.com. But we can see that they’re trying to access those admin pages on their phone, so we thought, “What are the things that we can go build for that?”

And so what we did was we did a mini version of a design sprint. So, I imagine you guys are familiar with Jake Knapp, the Sprint book and we took that idea and said, “How can we take the idea of a North Star, of longer term vision of a native App for our seller and really focus ourselves to accomplish something?” So, as in the true model of the EPD model and getting together, we all got into this really awesome room that we have in JANE, which is our exercise room/ping pong room/go do a design challenge, design sprint room.

What came out of this was alignment. What came out this was, we had done a bunch of research already and getting all on the same page across engineering, product, and design, and at QA and really understanding what they would want out of an App, which then led to sketches that you saw on the wall which we realized that as a team, we were already really close to understanding or being on the same page and then as we evolved the design, we gave the designers some space to go and create a little bit more wire frame, a touch higher fidelity to have conversations around and make sure that we were still on track, which then resulted in a vision for this App.

Yeah! So, this is a video. It’s an innovation story. It’s something that drove a vision for where the App could be and in the end, it really was very simple core features that we had found through research, through qualitative testing, through data science, to figure out what it is that they cared about the most as sellers and that they would do on their phones. It’s not a replica of the App or the web App that we have online or the Admin. This is an Admin. It doesn’t feel like an Admin. It feels like a consumer App. It feels like thousands or millions of people could use it and we presented this at our conference called JaneCon and the sellers just flipped out. People just stood up and started clapping. They were so excited for this.

What I want to show through this example is that taking this idea of an innovation story or being innovative, you can time box that. Literally we accomplished this within two months. I mean, obviously we had a web App that supported this, but through a design sprint, through existing research or ongoing research that we did, we were able to accomplish something very quickly. We even took on new technology! We developed this within React Native, which is not what our core App is built in. There was a lot of speculation around whether that was going to be good. Whether that would feel native. Whether that would be suitable for everything and a lot of that was all through a lot of cross communication.

Evolutionary Thinking

Now I want to kind of shift gears into evolution. This is a little less exciting for designers, right? I want you to go and evolve this little thing over here.

Engineer’s Reaction to Innovation Stories…

When you say evolutionary and an engineer looks at it, they think something like this, like “I’m gonna evolve into this amazing thing and I can see the path and I don’t need to worry about changing into a different animal.”

Product’s Reaction to Innovation Stories…

Product looks at that and they say, “I can take this small idea that we have and I can make it more money. More money! More money! More money!!” Until it just is lots of money.

Designer’s Reaction to Innovation Stories…

What I want and what I hope is that designers would still have this same reaction. Because it’s just an amazing reaction. And honestly it’s not what designers are usually excited to go do.

“Constraints are hard because they represent the bar and the bar is high on existing, successful products. Designers who persevere to ship something beyond this bar have achieved something remarkable, but they’re often unsung heroes because what they accomplish doesn’t come across as big or splashy.”
 — Julie Zhuo

Every designer loves to start with v.zero. Everyone loves to have a clean slate and it’s a lot harder to take something that already exists that maybe it’s successful already to some degree and make it even more successful.

“It’s often the quiet hum of a product getting better and better through the years, a common action made a little easier. A confusing interaction made simpler. A habitual gesture made more delightful. Maybe the average person never notices, but the product continues it’s upward trajectory. It grows from more popular. It has more impact in the world.”
 — Julie Zhuo

Evolution is…

1. Constraints. We just have to embrace the constraints.
2. Iterative. It’s baby steps. It’s additive.
3. It’s measured incrementally.

At Jane.com, we have alpha releases and beta releases and full releases, so if we change anything on Jane.com, we change it incrementally on a day to day basis and we know what broke what. And over time, you might look at what Jane.com looked like a year ago and you might look at what it looks like today and it’s very different. But it didn’t change over night like that. It was very incremental.

What evolution is not…

1. A reinvention of the wheel.
2. Scope Creep.

Everybody loves to put on their Scope Creep shirt, right? And say, “But what if we just did this little thing?” Designers are so good at this. Designers are the best at Scope Creep. I am the best at Scope Creep.

Here’s another great example. At Experticity, I was there for five years. We were … okay, this is really complicated and I only have four minutes, so! We had two products, 3.5 and promotive. We wanted to merge them to Experticity and to do that wasn’t a simple task. But we had the option of saying we can go and revolutionize it and start from scratch, or we can go and evolve 3.5 into what we wanted Experticity to be. And then just sunset ProMotive.

So we started here. We started to really high level and say, “Okay, we’ve got these two platforms. We’ve got an Admin. We’ve got this other stuff that I don’t want to talk about because it’s complicated.” And then we go into how do we merge those two applications together into a singular application that then is unified and it’s changing the vision of how people look at us as a platform and we’re unified in marketing. We’re unified in what we’re building in an application and everything. This was a strong vision that we all agreed to have it at Experticity.

The profile page of this was very core to it because we built software for experts. They were experts in biking, hiking, running and brands loved them. We had a retail audience and we had an industry influence or audience, we wanted to merge those two together because we felt like they were the same. Over time, I evolved what the profile page was iteratively, like I was used to, and trying to improve an application and finding what they didn’t understand, what they did understand, to help the experts understand what they were expert in, and understand how they were being ranked and how it evolved into what we wanted technologically. This was the strategy. We were trying to convert this into a new brand, a new Experticity, and then just flip the switch from 3.5 to Experticity.

What we learned about this experience of taking on the idea of evolution, which is usually very successful in a lot of ways. We learned…

“You can only pivot an existing product so much, sometimes, to deliver an entirely new kind of value. You have to do it in a different context. You won’t be able to iterate your way into it.”
 — Julie Zhuo

We found that out over a year long experiment of trying to evolve our way into a new value which then led us into, “Now, let’s flip the switch. Let’s actually make this evolutionary project into an innovation project.” And how do we take these ideas and go back to a little bit more of the drawing board of how we can create vision for how we wanted to approach this product, which then led to conversations over wire frames, we were able to have clear conversations, understanding, and vision for our product that led to more designers more focused on what we were trying to accomplish. Design systems to keep us in sync and creating a fully innovative new vision for what we wanted Experticity to become.

I no longer work at Experticity. I pulled this up last night to see what it would look like and this is what it looks like and obviously I haven’t used Experticity in a while, so sorry about that Experticity. I have no brand certifications.

“Shipping improvements, both big and small is a designer’s job. Usability is a designer’s job. Craftsmanship is a designer’s job. If you never find yourself designing a North Star, if you are only ever making existing products more usable or more beautiful, then maybe your talents are not being fully utilized.”
 — Julie Zhuo

So, what I wanted you to learn today from this is … the take aways here are…

1. Innovation starts with autonomy, team work and cross functional understanding of each other’s goals in their own organization.
2. Setting clear org decision boundaries is very important
3. Embracing constraints when we’re tasked with evolutionary design decisions
4. It’s not one or the other. Sometimes an evolutionary strategy turns into an innovation strategy and sometimes you’re working on both.

That’s all I have for you today. I really hope that you have really enjoyed this conference. I’ve stressed up until this point for you guys to enjoy it, so I really hope you say yes. And, thank you so much for coming out!

‍