Bob Baxley: recommendation

Transcript context

…So let's actually follow the thread of design tenets and principles. This is something I've heard about you, that you're a big fan of design tenets versus design principles. What is the difference? Why is this so important? Yeah, so look, there's whole websites dedicated to design principles, and if you go and you read it, you'll see a lot of principles like simple, clear, beautiful, fast, secure. You'll hear these words and all these words are great. I mean, obviously I have nothing against any of these words, but they're not useful as decision-making tools because nobody would ever argue the opposite. Nobody ever sat in a meeting and said, "Oh, forget clear. Let's try to make it as confusing as possible." So the idea of clear, it's nice to have out there as, I don't know, sort of a platitude to move towards, but I just don't think it helps you make decisions. And so tenets are really decision-making tools and it's sort of like... A classic one is paper versus plastic. It's just too complicated to reconsider that every time you're at the grocery store. So you sort of make a rule for yourself and you're just a paper person or a plastic person, you move on from there. And so it's sort of that at scale. And the story comes from when they were starting to work on Keynotes, apparently the guy who was responsible for originating Keynote went to Steve and said, "How should we think about Keynote?" And Steve said, "I want you to keep three things in mind. One is it should be difficult to make ugly presentations. Two, you should focus on cinematic quality transitions. And three, you should optimize for innovation over PowerPoint compatibility." And if you take that last one in particular, if he hadn't kind of said, we're going to go this way instead of that way, that team would've spent the next 10 years gouging each other's eyes out over whether they should try to go for PowerPoint compatibility or innovation. And so when I was at ThoughtSpot, I realized pretty early on that I wasn't going to be able to have any sort of command and control over everything that was going to happen in the product. There was too many people involved, too many engineering teams, most of them were in India. I needed to move from a mindset of control to one of choreography. I needed to try to set the culture and set certain design tenets that everyone could internalize and follow and hopefully then make the right decisions in that groove, if you will. And so we had three, I think you can't have more than three or four because you need everybody to memorize them. They can't be consulting a handbook. And so, one of them was documentation is a failure state. In enterprise companies, a lot of times people think, "Oh, we'll just put it in the manual. It'll be part of the training." And I would constantly be coming back and go, "Stop it. Nobody wants to learn our software. Nobody cares. We are just one more browser tab in a world of browser tabs. We are not this user's complete world. They do not want to learn this stuff." Documentation's a failure state. Maybe we can't always avoid it, but we should do everything we can to simplify things so you can figure it out in the context of the product. ant to learn this stuff." Documentation's a failure state. Maybe we can't always avoid it, but we should do everything we can to simplify things so you can figure it out in the context of the product. That's number one. Number two is every interaction should start simple and the users should have to opt into complexity. So our main competitor at the time was Tableau. Tableau started with complexity. That was their whole value prop is like, "We're a super powerful tool. We can do all sorts of stuff." So when you sit down at Tableau, it feels like you're flying the space shuttle. And if you're a professional data analyst, that's great. That's the kind of tool you wanted. That wasn't what ThoughtSpot was about. We were trying to take data analytics into the hands of what I call mere mortals, also known as business users, people who didn't live in breathe this stuff every day. So our goal with them was they could sit down and it was an approachable piece of software and they could turn on all the bells and whistles and power if they wanted it, so that was the second one. Start simple, let the users opt into complexity. And the third one was the entire product should look and feel like it came from a single mind. And this was a tenet to try to combat the natural tendency of enterprise companies to really fragment because you have all these different teams working on their incentive to work just on their little piece. And so they think about what's right for them and they don't back up to look at the whole thing. And so we had this tenet, the whole thing should look and feel like it came from a single mind to just try to remind people, how does this fit into the whole system? And sometimes we need to go along and do things that work for the product that don't necessarily work quite the way we might want them to for our feature. And so those tenets were all... Again, they were all decision-making tools. And when we would have design debates, we could just come back to this, wait, are we actually starting simple and forcing them to opt into complexity or are we doing something else here?…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.