Lessons learned about Design by a Developer

Image source: http://www.huffingtonpost.com/william-morrow/6-reasons-why-web-designib_12128792.html

One thing I noticed after working with software developers for a short period of time is that they’re pretty smart (full disclosure, I’m a developer 😄 ). Ask us to create a piece of software that does some obscure task and we’ll have it done in no time with some extra functionality that you didn’t think of. We’re great at coming up with software solutions to complex tasks as long as the software doesn’t require a graphical user interface. Designing a GUI is like kryptonite for a lot of us. At least, it was for me until now.

Something I’ve found interesting after working at a few companies doing front-end software development is that we are rarely taught good UI design practices. I often hear of developers saying how it’s a good idea for designers to understand a coding language, but I rarely hear the reciprocal: that it would be useful for the front-end developers to understand some basic design principles. The projects I’ve worked on that have turned out really well are those created by developers using both design and development skills. Over my career developing software, I’ve collected some design tips that I’d like to share.

Design isn’t just visual

Think about the different people that use your site. We have unique user personas for our different types of customers. Any requests for feature development include references to the ┬átype of personas which ┬áprovides us with a richer understanding of the work to be done to make an excellent user experience. Too often when we get a new project, we spend our time focusing on the functionality of the software and largely ignore the design. It’s easy to think of design as just visual, but while the way something looks may be a large part of design, so too is the functionality of the software. Good usability lends itself to a better user experience.

I’ve learned to think about the types of interactions people would perform most frequently and what they might look for on a day-to-day basis. This has changed the way I think about designing an interface: regularly used actions should be quickly and easily available to the user. Information or tasks that are less common for the user to interact with can be hidden deeper. My rule-of-thumb is to keep in mind the number of clicks a user must perform to get to certain information from main pages. I use it as a means of measuring how easily accessible something is.

When I think about how to display information, or what my navigation system might look like, I keep in mind that there are already perfectly acceptable solutions available in the wild that will do this for me. No need to reinvent the wheel. Users are likely already familiar with common components and are experts at using them, so don’t change them! Manipulating the way someone interacts with your website too far from the norm will begin to make it feel strange and offputting.

Adapt for mobile

With the number of people browsing websites on mobile devices surpassing those on desktop in 2014, having a responsive webpage is no longer an option but a must. Website design must reflect the fact that a significant portion of the traffic going to it is from mobile devices, the majority of which have touch screens. Small links and buttons are no longer acceptable. All links, buttons, and interactions should be spaced out to allow for easy selection and input on touch devices. Improving the experience of users on mobile devices will result in them being more willing to interact with your website.

Start offscreen

Designs change as more thought and work goes into them, that’s just how it is. Because of this, building out a detailed prototype as your first attempt is a waste of effort. Just like how a programmer may write pseudo code or scribble down the general flow of information through a new program, designers will work on whiteboards or paper to sketch their ideas and share them with teammates. As ideas start to take shape, then move on to creating more detailed wireframes, mockups, and low-fidelity prototypes. A detailed design that looks like what you may actually want the product to look like should not appear until the final stages.

I’m not always right

Designing a website is an iterative process, part of which is gathering feedback from peers and users. Going over a design with someone else can bring insights as to how other people think, reason, and interact. Anytime I have access to someone familiar with design, I push to get them to explain why they want to make certain changes. This helps me gather constructive criticism and learn from them.

Every design decision I make is just a hypothesis until it is tested. No one knows exactly how certain design decisions will impact user interaction. This is when A/B testing becomes extremely useful. In A/B testing, two variations of the design are released into the wild and metrics about how users interact with each design are collected. This provides real world validation that certain design decisions are better than others. What you’re designing is for someone else, so why not let them (and the data we collect) tell us what they like?

Design is always changing, and no design is one hundred percent perfect. Educating yourself in the design aspects of software is a great way to take your projects, and your users experience with them, to the next level. Once I understood the reasoning behind design decisions, I started to participate in design conversations and learn what makes a solid user experience. At the end of the day, users should enjoy using your product just as much as they find it useful.

About the Author

Jason Dippel is a 4th year Software Engineering student at the University of Waterloo. He enjoys learning about various frontend technologies and how they can be leveraged to improve the user’s and programmer’s experience with a product. While programming is a big part of his life, he frequently spends his weekends exploring new trails on his mountain bike.