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.