Brick by brick developer experience

Speaker 1: Have you ever thought about how much first impressions matter? We all know the cliche anecdotes about you know, dating and stuff like that, but that's not what I'm gonna talk about today. Today I wanna talk about how first impressions for your product matter. This is my space shuttle. It's from the Lego box six three four six producing 1992.

Speaker 1: And I recently put it back together after I went to see an actual space shuttle. I thought it would be nice to kinda have it back, it comes with a with a build in the Can arm and a little a little satellite to deploy. Now if you were fortunate enough to grow up with a lot of lego like I did. You probably know what lego is. But if you don't, It's the brick building toy for children that has many middle aged people still enjoying their childhood up to now.

Speaker 1: It's the toy that connects two rigs and then takes another two and another two until eventually, you've build a complex structure. With close little understanding as to what you've done and how you've done it. It was invented in the thirties kind of got defectors in the fifties, and it's still around and just like Ikea Allen key, there's certain things that have never changed. So who am I? I'm soon to be verified on Twitter.

Speaker 1: Apparently, I'm Run a small developer experience consultancy. And one of the things I like to do is to look at the onboarding of various companies and, like stripe in Twilio and see what's good and what particularly sucks. Today, I'm gonna take a similar look at what we can learn from Lego, from Lego onboarding experience. And then a longer way we'll learn a bit about human psychology, first impressions and how all of these things can affect your product, your product experience and the developers that try to use it. There's a lot of stuff on that.

Speaker 1: The big red logo, the product number, the indication of complexity, But there's so much there that isn't quite that obvious. Lego has done a lot of stuff to put us at ease with this design. It's often easy to forget that your external developers are not the awesome master builders that you are. And yes, a Master builder is a lego term for somebody who actually makes these pieces of art happen. They have an they haven't gotten an experience with your product.

Speaker 1: They don't have an experience with your industry. They don't know what your product does and probably don't know what it is for. And not unlike the average age of a first time lego builder, your average developer is probably going to be a lot younger than you. And with young age comes a lot less technical experience, a lot less life experience and probably a high ratio of lego experience. Lego job with the design of these boxes besides selling you the product is to overcome these deficiencies.

Speaker 1: The boxes are there to inspire you, to inspire you that you will be able to do amazing things with their product. They show you the finished product, the parts it's made of, and sometimes even the basic assembly steps. For the more complex products, it also shows different variations you could built with it. And this is core to the lego experience if you think about it. But if you really think about it, it's also core to your product because you don't want people to make the samples that you've written for them.

Speaker 1: You don't want them to make the guides that you've written for them. You want them to make their product happen. You want them to build their product with your product in it in ways that you haven't even thought about. So the real thing about a first impression isn't about looking good or having the best product. Rather it's about making sure you It's a it's about making sure that people have the confidence that they'll be fine.

Speaker 1: You want to inspire and motivate them. We also want to make sure that they know what they're gonna be able to do with this even if they've never used your product before or new to programming. In technical products, there's a few ways we could approach this. Firstly, we need to motivate and inspire people, we need to tell them that our product is going to solve a problem they care about or they might not even know they had, but they're intrigued by. I personally love the way pushing us this.

Speaker 1: Push has this sample on their website. It's about hard to see. They have this curl command, you paste it into the terminal and it changes the color on their website. In a few seconds, and without mentioning how it's done, they show you how easy it is to push any event to any browser. With one c command, they instantly get a developer thinking, oh, that's interesting.

Speaker 1: I could use that in x y z. And they did all of that without boring you with the technical details as to how this works. Which brings me to the second point. It's important to give our developers to confidence that they can do it. And not just you.

Speaker 1: We need to make sure that we make them feel smart, even if they have almost no dev experience, or experience with your product. Push it does a great job of keeping the jargon low. They don't talk about sockets. They keep the technical terms and acronyms to a low. The only remark I'd really have here is that you need to know curl.

Speaker 1: To make this demo happen, and that one step of copy pasting the crawl command to a command line, is still a point of failure where somebody might not experience your product. And if they can't experience your product that is a potential point where they will drop off. In general, I find that images, especially animated images that people just have to click on are a lot more full proof. That will work for everybody. So once you've reached these goals of motivation and inspiration, the real angle goal really is to put confidence into your end users.

Speaker 1: And lego is great. At getting people started with that confidence. This is the actual manual for my space shuttle. I surprised it was still in one piece. I was very careful putting it in my back this morning.

Speaker 1: And we're all quite familiar with manuals. A a lego instruction manual is the ultimate getting started guide. Right? It's included in pretty much every box unless it has, like three pieces and it's hard to figure out. It's hard to do it wrong.

Speaker 1: And it helps people go all the way from zero to hero, helping them in every step along the way. It's an amazing achievement that all of this is done without any text. Without providing any technical explanation of what what is happening. See, the human learning process is kinda circular. It's a feedback loop.

Speaker 1: That promotes really small steps. We learn, reflect and repeat. Learn, reflect repeat. And if between reflect and repeat, we look at what we've done and what the expected outcome was, and we see if there's any difference and then adjust our next steps. Now, when we find a really big discrepancy between what we expect and what we got.

Speaker 1: We get very confused and it's really hard to compensate, and this is where people drop off. Lego has mastered this process in their manuals. As you can see, every manual just starts with a with a few bricks at the top, and then a few bricks more and a few bricks more. And if you've assemble lego books is like I have, you'll notice a few patterns. There's a...

Speaker 1: For example, there's a few ways to ensure that your product is structurally sound. You can do that but kind of inter looking the brakes so that they're the the joints aren't all on the same spot. That makes your product stronger. What is interesting is that is this is a common practice in architecture, aerospace engineering, and in many, many other industries. Yet, it's never labeled like that in the lego manual.

Speaker 1: It's never explained what it is. It's just there. Instead, people are simply shown step by step how to do things the right way. And they do this without labeling it without resort to jargon without creating an artificial divide between amateur and amateur and professionals. Now When take a little sidestep step here.

Speaker 1: Which is you can overs shoot this and think that your product is an apple product. Your product is not an apple product. Apple has mastered the design of products that do not need manual. And all of that, I love to just... I'll love products that are intuitive and easy to use that are forgiving and self correcting.

Speaker 1: These products don't need manuals, but like I said, your product is not an apple product. The user base, any expectations of your products are vastly different than that of an apple product. Inherently, any developer product if you think about it, whether or not it's an Api and the sdk or some kind of tool is going to require very specific input to do very specific things. Input that's less forgiving less self correcting and therefore more painful to bugs. But your product is also going be highly efficient to solve certain problems.

Speaker 1: So people do want to use. It. So just like legos inter locking bricks will teach people how to make a sound structure, your manual will need to teach people to how to do things that even know they need it. I wanna reiterate how important is that these manuals take people from zero to hero all the way through from break number one to a full space shuttle. If Lego would only take you halfway there, halfway towards making a real product.

Speaker 1: The satisfaction would be immensely lower. If they just went, hey, you know, here's the of first five bricks, you can figure out the rest, you wouldn't be happy at the end. Yet, many of the sites I've looked at have a big get started button on the on the front page. That will take you to sign up, take you to the dashboard and then leave you there. That is not getting starters.

Speaker 1: That's getting me signed up, and that shows that your business is really just all about collecting emails and not about creating success stories. And this is, you know, this is really the core of what I'm trying to tell you is that in reality, every step in your process matters. If you get started guy, get somebody through the first steps as we mentioned, and managed to inspire, motivate and sign up a developer. You then need to make sure that you help them make their first Api call that second Api call, become a good become an actual product and become successful to finish their space shuttle. Now, have you ever looks at how people find pieces?

Speaker 1: Who cares kids? Must be few. Who hair still feels like a kid? Great. Okay.

Speaker 1: You you might remember this is like, when you look at how people find pieces of lego, it's it's very interesting. I mean, similarly, like, how how do people find their I... Next piece for their ikea asset set. They do not evaluate every piece on the table. They don't go, okay.

Speaker 1: What is exactly the piece that I need? That would be insane. That would take ages. Instead, they just look around for the right color or approximate right size, grab it see if it fits if it's not grab the next one. This behavior is called sat.

Speaker 1: It's the same behavior that we see in firefighters when they come to a fire. They don't go ahead and start randomly, start making an exact plan of what is the best approach, the number one best approach to to deal with this fire because in the meantime, the fire is still going on. People do the same thing when they read websites, people come to your website and they just look at what they probably want and click on it and try it and see it. If it doesn't make sense, they reevaluate what they wanna do, they go back and adjust along the way. In an Api, this forgiveness can be achieved by adding some level of self correction or forgiveness to the product.

Speaker 1: One way to do this is to add detailed error messaging that signals to the develop what mistake they made. I often see errors that are just either a coat or some message that is nothing more than invalid. Now we'll be tempting to provide some notes on your guide. You know, let's put it in the developer documentation, because that's where people should be reading this, and they should be reading this because this is important, and this happens so often, we should write this down somewhere. Now, lego dust this sometimes like when there is confusion around certain pieces like which piece do you need.

Speaker 1: Like, here on the top, like just to make sure you have the right one. There's a one on one comparison of kind of the size of the piece that you need. But as a product owner, I'd almost always recommend to instead improve your Api and estimate sdk to be less ambiguous. To remove the confusing elements rather than patching them with text that nobody's gonna read. So if that really brings me to the core of the message, which is If you take one thing away from this entire talk, is that nobody reads.

Speaker 1: The average website visitor takes less time than it takes for you the bling you're honest to determine not just what your site does, but what page they're on within your entire website when in within your entire domain, what they can click on and what they could potentially achieve with your product. As much as you might be some artisan crafter of excellent technical copy, People are just not gonna read it. Instead they're gonna try and build what they think they can use your product for and if they can't, they'll adjust along the way. That piece is actually part of a larger set. There's a there's a whole trailer that the space shuttle can fit on.

Speaker 1: There's is a little car. I've have you ever seen the little doors where they open and stuff like that. That they're almost in every little set that has a car or anything in it. You've got the little doors. It's easy the thing that your product like this door has a specific purpose that you thought of it first and that it's the only thing people ever want to use your product for.

Speaker 1: The reality is very different, though that just like a lego break has a million different use cases, your product will and should be able to be used by people with crazy ideas. You that you never imagined. The door is one of examples, but I've seen it used as the wings of a small plane. The ears of a bunny as a speed bump and much more. The lego experience doesn't end with the set that you bought, though.

Speaker 1: It goes much further beyond that. For example, this space shuttle has actually spent approximately sixty years, completely in shatter in a box at my parents, because when I was about 18 or something, I went to Uni, and I never got around to putting it back together until a few weeks ago. Now, Lego has embraced this idea of people wanting to build other things with the lego pieces they have though. They have something really catchy corp the lego.com digital designer or virtual building software. Quite a mouthful, which you can use them to then create new creations and share them on ideas that lego.com.

Speaker 1: And if you make something and it receives over 10,000 votes, then Lego will consider it as an official box and release it. And they'll put your name in the manual, and you'll be an official master builder from lego that has an actual box box created and shipped and you get a part of the revenue. They'll make you a master builder. Now if you flip this with my experience recently with Amazon Echo. It's very different.

Speaker 1: Often with developer products, we we stop supporting people after the first implementation. I recently build on Alexa scale, and Amazon besides having a pretty bad getting started experience has a pretty horrible experience when it comes to went you when you submit the skills. It took me three attempts to get my skills submitted, even though I had to fill in, like four or five forms of documentation. And in the end, when my skills did get accepted There was no congratulations. No celebrations, nothing nothing to kind of celebrate my success.

Speaker 1: And it's important to celebrate the success of your internal developers, and your external developers. The support for developers should not end with that first implementation, rather it should continue all the way to every product they built. Every product they use your product in, every crazy variation of what they're doing, they might consider. The developer experience should not be that of learn build reject. It should be that of learn built share.

Speaker 1: So to wrap things up, there's a couple of things I wanna summarize. Some of the real lessons we can learn from lego. One of the big ones is that we all learn differently. We all have different ways to assimilate information. We have different starting points about where we start when we want to start building something new.

Speaker 1: We have different experiences, both technical and in life. We have different cultures. We offer all different needs and different motivations A hacker at a hack has different motivations than somebody working for an enterprise trying to build an actual product into an existing one. But that product should be built for all of us for the amateur here and the professionals for the startups and the enterprises. And when we start building every ten seconds matters, even the first and then the next and the next because the first one influences the next 10 and next then influences the next then, etcetera.

Speaker 1: If you don't allow people to succeed if you're not flexible to failure if your product doesn't self correct. The next text that ten seconds will be where you competitor. And finally, you know, celebrate success. When a developer succeeds on your platform, just remember all the hurdles they overcame. All the learning they did about you, your platform, your industry, And everything they did not think they needed to know, but they still learned because you had to put that in their way.

Speaker 1: When you've spent this intense effort to inspire a motivate people to give them to give them in you that chance for them to build something you couldn't have imagined, then celebrate that success is yours, Making it easy for your users to succeed, makes it easy for you to succeed. So I'll leave you with this. You can write the best copy in the world. You can have the best instruction videos ever made, and the best developed product ever invented. But when somebody steps on a piece of lego, it's still hurts.

Speaker 1: So that's it for me. Happy to show you more of the lego. Thank you for joining me.