Getting Beyond "Designed by Developer"

This is the deck from a presentation to the 1871 Hackers meetup at 1871 Chicago on November 7, 2013. This was the description:

The term “designed-by-developer” gets thrown around to criticize web and mobile apps with poorly designed user interfaces. It’s unfair to point the finger at developers without explaining what the term means...and it’s generally unproductive to call people names. So, in the spirit of cooperation between developers and designers, this session will explore what the term really means (hint: designed-by-developer != bad design).

Michael will present real world examples, and suggest some better approaches. Additionally, he’ll offer some simple things developers can do to improve the user interfaces they build. Hopefully, everyone will walk out with an idea of how to create more intuitive and enjoyable user experiences. If we’re lucky, we’ll even heal some old wounds between developers and designers. Hugs optional.

Transcript

1. Getting beyond Designed by Developer Michael Boeke 1871 Hackers Getting Beyond “Designed-by-Developer” Presented to the 1871 Hackers Meetup at 1871 Chicago, on 5 November 2013. Original content licensed under Creative Commons Attribution-ShareAlike 3.0 Unported. All copyrighted portions remain the property of their respective owners.
2. We simplify payments for thousands of amazing companies Braintree is a full-stack payments platform that makes it easy to accept payments in your app or on your website. 2 I’m a product manager and designer at Braintree. Before that, I worked as a designer, front end developer, and product manager at a few other Chicago startups. If you’re not familiar with Braintree, we are a payments platform that makes it easy for developers to accept payment in their apps and on their website.
3. 3 Braintree powers payments for many of the companies that developers love, like GitHub, Heroku, and 37 Signals.
4. Pay your friends instantly with the first fun and social payment platform. Make ultra secure transactions without any fees. Braintree also has fantastic app called Venmo, which ensures you’ll never owe your friends money again. It makes it super simple to pay friends for things like cab rides, bar tabs, and even rent or utilities. My time at Braintree is spent working with our development and design teams, mostly on our payment platform. As part of that work, I’ve been helping the teams to find better ways to integrate design and development, and that’s what I’ll cover in this talk.
5. A few years back Jeff Atwood, of Stack Overflow fame, posted an article on his Coding Horror blog with this title: “This is what happens when you let developers Create UI.” And with that statement, we have this gem of desktop user interface design, which has buttons, checkboxes, and form fields mushrooming out of it in all directions. He was imploring readers to have designers design things and developers write code. And with efforts like this, you can see why he might suggest that.
6. Je! Atwood, @codinghorror “This Is What Happens When You Let Developers Create UI” A few years back Jeff Atwood, of Stack Overflow fame, posted an article on his Coding Horror blog with this title: “This is what happens when you let developers Create UI.” And with that statement, we have this gem of desktop user interface design, which has buttons, checkboxes, and form fields mushrooming out of it in all directions. He was imploring readers to have designers design things and developers write code. And with efforts like this, you can see why he might suggest that.
7. Ha! Ha! Copyright  Fox  Broadcast  Company It’s fun to point and laugh at bad UI, and we are going to look at a few more of these examples, but I think that Jeff drew the wrong conclusion. Rather than keeping developers out of UI and UX design, we need to acknowledge that they play critical part, no matter what. So instead of just trawling the web for examples of bad design to share with you, I’m actually going to share some examples from my own team and our own successful software platforms. Image copyright Fox Broadcast Company
8. Design is not just what it looks like and feels like. Design is how it works. You can’t have a design talk without the obligatory Steve Jobs reference these days. He’s become something like the patron saint of modern design. I’ll even give him a halo. I’m poking fun, but he deserves credit for popularizing this important notion: Design is not just what it looks like and feels like. Design is how it works. Image copyright Apple, Inc.
9. Art != Design Art is not the same thing as design. I’ve written it here in language that should be familiar to developers.
10. Art == Self-expression Art is about self expression. It’s focused on the artist, on her ideas or feelings.
11. No. 61 (Rust and Blue),Mark Rothko When Mark Rothko was painting this canvas, he was expressing something inside of himself. Maybe it was to communicate and idea, or elicit an emotional response, but it was all about the artist and the viewer. Image credit: http://www.wikipaintings.org/en/mark-rothko/no-61-rust-and-blue
12. Design == Problem-solving Design, on the other hand, is about solving problems. The designer is secondary to solving the problem, and the viewer may not even be aware of the designer’s hand in the process at all. Design uses many of the same tools as art - things like color, shape, composition - but it’s always trying to solve a particular problem for a specific client.
13. An example of design is taking the complicated banking system and turning it into something a developer can access with a simple integration. When you think about it that way, it’s something familiar to developers. It’s the same thought processes you apply to engineering, but with a different set of tools and concerns. Devs already know this - many of your resumes probably include OOD. I’ve seen the Braintree dev team obsess over naming things in the API, because they want it to be clear and intuitive for developers. They were already engaged in UX design, even if they didn’t identify it as such.
14. What’s best for systems is not what’s best for users. @MVBoeke Preparing for this presentation, I spoke with a few designers about the things they most want to say to the developers they work with. The first item on that list is “What’s best for systems is not what is best for users.” Developers are great at designing systems and optimizing for performance, scalability and even maintainability. However, these things don’t make a for a great user experience, and sometimes actively work against it.
15. Flickr: missmac For example, Rails scaffolding automatically generates views based on the app’s data model, which is a useful way for developers to avoid writing boilerplate CRUD code. However, the data model doesn’t always match the user’s mental model of an app or domain. One example I’ve seen multiple times is users and permissions as separate objects in the data model, but people wanting to see permissions as attributes of the user model when viewing a user’s profile. Photo credit: http://www.flickr.com/photos/maddi/
16. Here’s a more concrete example: our platform’s home screen a few years ago. Historically, Braintree was an engineering driven organization, and our primary product was essentially an API for payments (and that’s still essentially true, although we do much more now). The Control Panel, was essentially a GUI for our API, and that was reflected in a lot of ways, including this blank home screen. The API didn’t really contain a notion of a home screen, or starting point, so there was nothing that would manifest in the Control Panel. But this was far from an optimal experience for a user who logged in the platform, even if they were a developer.
17. We decided to take advantage of this space that every user hit when they logged in to our Control Panel, and actually put something useful in it. In this iteration, we included some navigation buttons, as well as information that developers need to complete their integration with Braintree, including their API keys. It was big improvement, but it’s still not perfect. It’s great for the case of new users, but it doesn’t offer much for our customers who have been with us for a longer time.
18. So we have been working on some new concepts. This prototype home screen goes beyond just using the available space to display something of value. The designers took a step back and asked what issues a user faces when starting out, and what changes for the user over time, and we can display information that is relevant to the user for wherever they are in the lifecycle with our product.
19. You are not the user. @AJKandy The next bit of wisdom from designers I spoke to was “You are not your user”. Even designers sometimes need this reminder. Many of us start building something to “scratch our own itch”, but as soon as we want someone else to use our software we need to accept that users are going to have a different point of view.
20. For a lot of developers, the command line is the ultimate UI. However, most people don’t type well, don’t have a mental model of how file system works, and are generally intimidated by a wall of text. This is an extreme example, but is a reminder of the gap between different people’s experience. It’s important to be aware of this and find other ways to get a real user’s perspective. The best way is to talk to actual users, and to watch them use the software you’ve built. They won’t have any of the assumptions you’ve built up over time, and will give a fresh look at how usable your product is (or isn’t).
21. This was an embarrassing dialogue in our recurring billing controls. Clearly, everyone working on the software was so habituated to our dialogue system, that we didn’t even notice how the term “Cancel” got overloaded here. However, when a user was actually prompted to decide whether they should delete some of their own data, they read the dialogue carefully and were understandably confused. The worst part about this bit for us, is that one of our users called-us-out in a blog post about this dialogue. Doh.
22. Luckily, we were able to fix it immediately. The library we use for the dialogue modals let’s us specify button text, so we change them to “Yes” and “No”. If we are asking a Yes/No question, we should give the user the chance to respond with the same language.
23. Design occurs regardless of whether a designer is involved. @RyanBurke One of the designers on my team, Ryan Burke, recently pointed out that design occurs regardless of whether a designer is involved. Design happens before a line of code is ever written, in the initial conversations about how a feature will work and when choosing which technology to use.
24. Flickr: avlxyz If you find yourself writing story cards, or talking about how a feature will work, and you aren’t explicitly considering the UX in that conversation, you’re probably on the wrong track. I hear developers say you can’t “bolt-on” quality at the end, because it has to be baked into the whole software development process. Well, you can’t bolt-on user experience at the end, either. If you hand completed software to a designer and ask them to “make it pretty” you’re not going to get great design work in return. Photo credit: http://www.flickr.com/photos/avlxyz/
25. Here’s an example of a feature that could have benefited from user-centered design thinking from the beginning. This is our platform’s advanced search screen. Since it simply displays all the options for transactions available in the API, it displays way too many checkboxes to users at once.
26. We recently took the time to reconsider the whole platform search and reporting feature. This mockup proposes to limit the number of options presented to the user to just a handful at a time. It accomplishes this by prompting users to add one field at a time, and by categorizing the fields into a navigational hierarchy. The best part of looking at this feature from the user’s point of view is that we discovered a new requirement - saved reports. We don’t need to store API search queries, because they are persisted on the merchant’s server. We humans, however, we need a way to re-run reports each day, week or month.
27. Design is not just what it looks like and feels like. Design is how it works. And now we’re back to Saint Steve. I want to revisit that quote. Design is not *just* what it looks like and feels like. Design is how it works. Which is to say, how it looks and feels is an important part of design, too. Humans are emotional creatures, and we form emotional relationships with the objects around us, even seemingly impersonal things like business software.
28. Design is not just what it looks like and feels like. Design is how it works. Steve jobs knew this, and it’s in full effect at at apple, where every few years we get a product line in an array of colors that are meant to help us to relate their products. Anyone in the audience who has recently bought an iPhone 5C knows exactly what I’m talking about.
29. Design is not just what it looks like and feels like. Design is how it works. Steve jobs knew this, and it’s in full effect at at apple, where every few years we get a product line in an array of colors that are meant to help us to relate their products. Anyone in the audience who has recently bought an iPhone 5C knows exactly what I’m talking about.
30. Design is not just what it looks like and feels like. Design is how it works. Steve jobs knew this, and it’s in full effect at at apple, where every few years we get a product line in an array of colors that are meant to help us to relate their products. Anyone in the audience who has recently bought an iPhone 5C knows exactly what I’m talking about.
31. Design is not just what it looks like and feels like. Design is how it works. Steve jobs knew this, and it’s in full effect at at apple, where every few years we get a product line in an array of colors that are meant to help us to relate their products. Anyone in the audience who has recently bought an iPhone 5C knows exactly what I’m talking about.
32. Where to get started with creating an attractive visual design? Lots of developers ask my opinion on Bootstrap - it’s almost like they’re asking for approval because they know some designers hate it. However, Bootstrap is great way to get 80% of the way to a visual design as long as your understand that it won’t help you with the “How it works” aspect of design, and that you’ll need to put in the last 20% of design effort to erase Bootstrap’s fingerprints and give your project it’s own identity. I also encourage people to check out the Foundation framework, from Zurb. It provides many of the benefits of Bootstrap, but the default styles aren’t so strong. Also, it has a wonderful mobile-first responsive grid. We use Foundation at Braintree, and I use it on my personal site.
33. The other thing developers can do is start to train their eye. The good thing about visual design is it’s very easy to get started (although it takes designers years of education and practice to hone their craft). Dribbble.com is a great place to see a lot of visual design work, and get as sense of what designers like, and why. A great approach is to follow the design teams from some companies you admire. Some of my favorites include Dropbox and Mailchimp - and the Braintree design team, of course.
34. Reading List Reading list for those who want to dive deeper into user experience and design. Steve Krug’s Don’t Make me Think is still a fantastic primer on web usability, even though the examples are dated. Don Norman is a UX pioneer, and Emotional Design delves into why we love and hate the things around us. I haven’t read Design for Hackers, by David Kadavy, but I hear great things about it and it’s on my reading list.
35. Design is about solving problems for people Your software is getting designed by someone (or something) Embrace your role in the design process 1 2 3 Since I didn’t include lots of bullet points, I’ll leave you with three takeaways: 1. Design is about solving problems for people, not systems or robots. 2. Your software is getting designed by someone (or something) so you can’t just pass the buck or bolt-on design at after you get the software working 3. Embrace your role in the design process by starting to think about the user and by including designers at the outset of your projects.
36. @mvboeke MichaelBoeke.com B BraintreePayments.com Interested in reading more? Follow me on Twitter @mvboeke or check out my (infrequently updated) blog at MichaelBoeke.com. For more about Braintree and our payments platform for developers, head to BraintreePayments.com.