Madera Labs | Five Things Every Developer Should Understand About UX

Five Things Every Developer Should Understand About UX

My friend Jacques asked me on twitter: “What are the top things you wish developers knew about interface design?”. Not feeling confident in my ability to expand on this in 140 categories, I thought I’d send this to the blog for exploration.

As a former developer (both front- and back-end), I enjoy a unique perspective on how the user experience-developer relationship goes. There are hundreds of things I’d love developers to know about user experience design, and this list represents a sampling of some of the more important things I want developers to keep in mind more often:

  1. People expect online interactions to follow social rules. Credit for this goes to my friend Susan Weinschenk, who covers this point exceptionally in her book 100 Things Every Designers Needs to Know About People. When people interact with a website, application, or any device, they expect that interaction to adhere to the same rules that govern in-person interaction.

    Feedback is a great example. If a friend of yours walks up to you on the street and says “Hi!”, what’s your response? Generally – unless you’re a psychopath – you respond immediately in kind, saying “Hi” back. What if, instead, you stared blankly at them for 15 seconds before responding? An awkward moment, huh?

    This happens all the time online. See, every interaction is really a conversation. We say something by taking an action, and we expect the interface to respond in kind, continuing the conversation. However, too often, users are left wondering if a website or app is actually doing anything. While the computer is off processing information or retrieving data, the user is left in the cold, staring awkwardly at the interface, wondering if it’s ever going to respond. The lesson? Just like in real life, provide feedback to users about what’s happening, just as you would in a real-life conversation.

    The same goes for all social rules. Be kind and humane in how you talk to users. “Invalid Data” is language a computer users…”Hmm, that doesn’t look quite like an email address. Mind checking it for me?” is how people talk to one another. Follow social interaction rules when building interfaces.

  2. People care about goals, not tools. At the end of the day, people care about getting things done and getting on their way. No one uses your software for the pure joy of it – they use it to accomplish a goal. Assuring that you’re developing a website or app to support that goal is one the keys to developing better experiences. Tools, while useful, get in the way if they’re not directly contributing to the completion of a goal.

    Jared Spool talks about goal time vs. tool time in this article, and it’s a great read for anyone putting together an interactive experience. Goal time is time that moves a user forward toward the completion of …you guessed it, a goal. Tool time is time that doesn’t move them forward, but supplements (and possibly distractions from) the goal time. As Spool notes, decreasing tool time and increasing goal time is a surefire way to assure your users achieve higher quality results, which means they’ll love you more.

    The lesson is this: as you’re building a website or application, gut check things you’re creating: does this element or feature really move a user forward toward a goal, or is it a tool masquerading as a goal-time element? Eliminate as many things that don’t keep users moving ahead. These might be extra form fields, customization controls, or other items that don’t move a user forward, but simply distract from the larger goal.

  3. Fewer choices make life easier. In a famous study, Sheena Iyengar tested the paradox of choice using tables of jam. The study aimed to understand how choices affect decision making, and resulted in a remarkable finding. It went something like this:

    The study involved a table of jam at a busy grocery store. During the day, the table rotated the selection: sometimes 24 jars of jam were available, other times, only six. During the course of the day, more people bought from the table when only six jars were available, rather than when 24 jars. The finding showed that more choices actually inhibit decision making, not expedite it.

    When you’re designing a website or application, less is more. Resist the urge to add more features, more options and more layers into the product. As you pare away these items, users have an easier time making decisions, and are ultimately more successful.

    As you’re building something, remember this famous quote: “A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away” - Antoine de St-Expurey

  4. 10 minutes of sketching will save you 10 hours of development. Every developer knows the pain of having to scrap a large chunk of code, just because a product manager or designer changed the requirements. These requirements changes aren’t typically the work of an A.D.D. manager – they’re the result of poor shared vision between all the players on the project.

    Underscoring the importance of planning first, Frank Lloyd Wright said this: “You can fix it now on the drafting board with an eraser, or you can fix it later with a sledgehammer.” Implicit in this quote is the idea that fixing problems before they’re built will save large amounts of money and time later down the road.

    Too often, products are built first, and planned second. Agile, with it’s “produce immediately” mentality has allowed the development process to get lazy with planning, and it’s unfortunate. This isn’t to advocate for a waterfall process, which also has moments of waste. When you go to build something – be it a screen, a form or an app, do yourself a favor: sketch it first and share it with the entire team. Erasing lines is much cheaper than deleting code.

  5. User experience work makes your life easier, not harder. Designers and developers love to pick on each other. Having worked in both roles, it’s easy to see why – the differences between the two groups couldn’t be more polarizing. User experience design work, however, doesn’t make the development process more difficult and time consuming (if done well). Instead, it allows developers to do more of what they love: write great code.

    Great UX work up front helps define the product, work through difficult process, flow and experience issues, and identify a set of items to be built. Instead of leaving a developer with a vague idea of the product to be built, great user experience designers carefully work out the details, relying on developers to carry out the technical aspects of the conceptual design. Like an architect and contractor working together, a UX-developer partnership results in better end products, and a project process that both groups enjoy.

  • http://www.islamiceventfinder.com Islamic Event Finder

    On #2 there are moments when users really want to waste/kill time and I believe that’s a considerable market segment. Antoine de St-Expurey quote is a gem!

  • http://www.maderalabs.com Justin Davis

    Yup! That’s very true. Browsing through content to kill time, gaming, social exploring and other activities are great examples of cases where killing time is exactly what users are trying to do. The key is this: in those cases, the goal *is* to kill time, so we should do everything possible to let users do that as easily as possible (if appropriate for the context, of course).

    Thanks for the comment!

  • http://www.facebook.com/profile.php?id=1221399865 Anthony Diaz

    So helpful and insightful, thanks so much Justin.

  • http://www.maderalabs.com Justin Davis

    Thanks Anthony! So glad you found it helpful!

  • http://twitter.com/slobodanmanic Slobodan Manic

    Loved the article Justin, I really like your selection of quotes to support it.

    Couldn’t agree more about everything you said, especially the bit about “goals vs. tools”, which I think is nothing more than egoism in disguise (“this tool I’ll build will be so cool that everyone will WANT to use it” – which is wrong 99% of time).

    I hope you don’t mind me asking something that’s only slightly related to this article. You mentioned you used to be developer before switching to UX design. Question might sound silly, but how do you do that? I’ve been working as a front-end and WordPress developer for several years now, doing some (web) graphic design work when I have to, but I know I want to design user experiences, not just enable them by coding, but I can’t just say that starting tomorrow morning I’m a UX designer, can I?

    Learning and reading about UX design is no problem, I’ve been doing that for a long time, simply because I enjoy it, but how do i change my hat and start doing UX work?

    Man, I hope that didn’t sound crazy! :)

  • http://www.maderalabs.com Justin Davis

     Slobodan –

    Not crazy at all! Thanks for the comment, and the great question.

    For me, switching to pure UX was a somewhat slow transition. I was working for a company, handling front- and backend dev work, as well as strategy and project management. Being a small team, we all had to wear many hats.

    As I gained more interest in UX, I slowly tried to position my work as less dev, and more pure user experience work. As an example, I’d contract out the development or UI design for projects, where before I’d handled it myself. With that extra time, I’d shift my focus to observing users, conducting tests, and iterating through the UX design portion of the process. My deliverables changed from comps and code to wireframes and flows, and the quality of the projects got better as a result.

    My advice would be this:

    First, study all you can. Continue reading and discussing UX, developing the vocabulary and point of view that user experience design requires.

    Second, change your role in your projects. If you work as part of a team, express to the team that you’d like to try injecting a more pure UX process into the mix. Choose a project, and only do UX. Do the research, user observation, sketching and strategy, and cut it off before visual design and development. Doing so will help you immediately understand better how UX fits into a larger project process, and will help to codify your role as the designer of experience, not the builder of it.

    Stephen Covey, in “7 Habits of Highly Effective People”, says: “Begin with the end in mind”. Start thinking of yourself as a UX designer. Tell yourself that UX is your role, and put the steps in place to become that.

    There is constantly an unrest in our profession around people calling themselves UX designers, when in fact, they’re not. I agree with the sentiment that we don’t want unqualified people representing the field. However, that comes with a big caveat: if you truly want to adopt UX as your role, and are willing to make the sacrifices to adopt that label appropriately, then yes – call yourself a UX designer. If to no one else, to yourself. When you look in the mirror in the morning, think that you’re looking at a UX designer. Honestly, only by adopting the right frame of mind will you start to move down the path you want to go down.

    This comes with a *huge* caution. Do not call yourself a UX designer if you’re not willing to sign on to everything that the field represents. Visual designers and front-end coders who appreciate UX are great allies to the profession, but they’re not UX designers. I do believe in protecting the sovereignty of the profession, so if you’re willing to take that leap, I encourage you to jump! For me, being a UX designer means that I don’t code any longer. I don’t work on projects where my primary role is to build the front end for a project. Instead, I focus solely on UX, and I sleep at night better knowing that I’m representing the profession appropriately. Conversely, I no longer call myself a developer (whereas I used to).

    This post by Whitney Hess helps may also help frame up the boundaries of the role, titled “You’re Not a User Experience Designer If…”: http://whitneyhess.com/blog/2011/04/23/youre-not-a-user-experience-designer-if

    I hope that’s helpful! Good luck!

  • http://twitter.com/slobodanmanic Slobodan Manic

    Justin, this is insanely helpful!

    Thanks for taking your time to respond, I honestly appreciate that. It reminded me of why it’s so great to have an internet-related job, there just isn’t, and probably never has been, another field where people are more willing to help.

    Perhaps that doesn’t always mean best for me, but I’m just not the kind of person that would call himself something he’s not, or charge for something I’m not really qualified for. However, the thing you said, convincing myself that I am (will be) a UX designer is great advice, and a great starting point.

    I know I will make this happen at some point, so why not start now.

    I’ll keep an eye on your blog, lots of useful info in the archives.

    P.S. Would you recommend “7 Habits”? I was thinking of buying it literally two days ago.

  • http://www.maderalabs.com Justin Davis

    Glad it’s helpful!

    I was listening to a career coach once as they counseled someone. This person wanted to become a dog groomer, but didn’t know how to start, when they could confidently call themselves that, etc. The coaches response was simple. He said, “The great thing is, you can wake up tomorrow and call yourself a dog groomer, and you’re right. The trick is, now you just have to convince other people of it.” I think it’s a great example of setting your mind right, then moving toward becoming that vision.

    As for 7 Habits, I’d definitely recommend it. It’s a bit academic in spots, but it’s a classic, and well worth reading.