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.
   

   View Slide

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.
   

   View Slide

3. 3
   Braintree powers payments for many of the companies that developers love, like GitHub, Heroku, and 37 Signals.
   

   View Slide

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.
   

   View Slide

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.
   

   View Slide

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.
   

   View Slide

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
   

   View Slide

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.
   

   View Slide

9. Art != Design
   Art is not the same thing as design. I’ve written it here in language that should be familiar to developers.
   

   View Slide

10. Art == Self-expression
    Art is about self expression. It’s focused on the artist, on her ideas or feelings.
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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/
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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).
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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/
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide