Hey everyone and welcome to Developer Tea my name is Jonathan Cutrell and today I'm going to be talking about creating obvious systems. If you stay up to date with hacker news or designer news or some kind of weekly email about UI design, then you've probably seen a few articles recently and a few opinion pieces about how obvious design is better. Specifically, the example that's used is a menu and that menu has two different variants. The first variant has some of the pieces of the menu hidden behind some kind of icon, like a hamburger icon of some sort. And then the second shows that menu explicitly showing each of the pieces in that menu directly to the user. And the piece also shows the user's engagement when they made the shift from the obvious explicit design to the obscure design, the first design that hides those elements behind some kind of icon. And what the study found was unsurprisingly, users were much more likely to click items that were not obscured behind an icon. The study is now being used to justify the opinion that obvious design wins. Now what is obvious design? Well, it's very simple when you consider how our brains work. Our brains construct systems, our brains construct ways of understanding things that are built on some kind of predictability. These systems are called models and our brain uses these models to take shortcuts. I've talked about shortcuts in the past on this show, but basically our brain uses these models to take shortcuts and to assume things about a given object or a given pattern that we're seeing. This principle is actually how a lot of optical illusions work, but it's also why we can learn complex grammar rules and apply them to create virtually infinite combinations of words that have meaning. And communicate with one another because we have a model for understanding how these words fit together and the underlying system that provides meaning when we put them together. So how does this relate to development work? I'm going to take a quick break for a sponsor and then I'm going to come back and tell you how it relates to development work in two different ways. Both for the end user as well as for other Developer That might come in contact with the code that you have written. Today's episode of Developer Tea is sponsored by Digital Ocean. Digital Ocean is simple cloud hosting built for developers. They're dedicated offering the most intuitive and easy way to spin up a cloud server. And in just 55 seconds you can deploy a solid state drive cloud server. Plan start at only five dollars per month for 512 megabytes of RAM, a 20 gigabyte solid state drive, one CPU and a full terabyte of transfer. In addition to offering simple and affordable SSD cloud hosting, Digital Ocean is dedicated to building out a strong community and supports open source software. They offer a vast collection of hosting tutorials and invite Developer To submit articles and they pay $50 per published piece. Deploy your SSD cloud server with Digital Ocean today by going to digital ocean dot com. Now Digital Ocean has been kind enough to provide Developer Tealisteners a discount of $10 when you use the code Developer Tea. So go to digital ocean dot com and use the code Developer Teato get $10 off today and you'll get up and running with your own SSD cloud server in just 55 seconds. That's digital ocean dot com. So you create predictable systems for your end users specifically, especially when you are creating the user interface. This means that you have a rhythm a visual rhythm you have different conventions that you should adopt across the entire user interface. You might have different contextual shifts ways of queuing the user in to the idea that maybe their context has shifted. For example, if they've logged in, maybe you change the context that they are looking at a great example of this is the acorns app. The acorns app has different background colors in the application and each of these colors signifies a different part of the application a different thematic section of the application. So maybe the the admin part of your application is a red color where the front end user part of your application is a blue color. That is a very simple obvious example, but perhaps you have a more sophisticated situation and you can apply this idea of systems of continuity so that your end users can begin to create in their minds, a mental model to know what to expect and to know how to interact with the thing you have created. So for your end users make sure you are creating interfaces that they can understand and create models very easily and that are predictable. The second audience is other developers make sure you are writing code that follows some kind of convention and it's not just any convention it's a convention that is accessible to anyone who is approaching the code. For example, you probably want to follow the syntactic style of the community of people who write in the particular language you are writing in. So for the Ruby community, you probably want to use snake case instead of camel case. There are a lot of different idiosyncrasies and patterns and best practices for given languages that you could adopt and allow other people who come in contact with your code. An easier way of identifying what kinds of constructs you are using, what type of system you are using and their mental model of your code is going to be easier to create and they will be able to interact with your system easier. They are going to be able to write code faster that integrates with your code. They are going to be able to fix bugs in your code better than they would if you had just written it without any consideration for predictability in your code. So when do we know when to break the rules? Well, I like to think of variety and surprise as salt. If you think about how we use salt on food, this is how we should be using surprise and abstraction in our applications. So if you think about what you use salt for when you put it on food, it's intended to help bring out flavor. Now I'm not a chef, but that's what I use salt for to help bring out the flavor of a given food. Now if I use too much salt, the only thing I can taste is a salt and I don't want to eat that food anymore. I can't even taste what that food is. If we use surprise in our applications, all the user is going to understand is that they are constantly being surprised if we overuse surprise in applications. We should be using surprise to outline and encourage our brand, our underlying identity, not overwhelming the user with this taste of surprise with just like with salt. So this salt, a small pinch of surprise is enough to make a very big difference. A great example of this. This is really a great example that you might have already heard about because it's such a famous one at this point, but there's these little scissors at the bottom of the footer and you can cut the bottom of the footer off. It's a very simple, but yet still surprising delightful moment when you are on the Kickstarter page. But if you go to Kickstarter website, most of the things on the page are not some revolutionary thing. They aren't trying to be flashy. They are simply giving you a system for you to work in so that you can back projects. That is the point of Kickstarter is to allow people to create projects and then subsequently to allow audiences to back those projects. And that is what Kickstarter does. That is the underlying taste of what they do and those little pieces of surprise that are scattered throughout the Kickstarter user interface. Those are the salt. So don't overuse surprise. Don't give it more value in your application than it truly deserves. Create obvious systems and create easy pathways for your users and for other Developer To begin to create mental models about the system that you have created. Thanks so much for listening to today's episode of Developer Tea. I hope it has been enlightening. You can contact me on Twitter at at Developer Tea, or you can email me at Developer Teagmail.com. If you have questions or thoughts or any kind of feedback, I always love hearing from all of you. There is a comment thread on developertea.com and all of the show notes can be found on developertea.com as well. If you would like to reach out, there is even a contact form on developertea.com as well as an RSS feed. There's tons of stuff there that you should go and check out. So once again, developertea.com. Thanks so much for listening to today's episode and until next time, enjoy your tea.