Design Basics
Podcast: Play in new window | Download (57.9MB) | Embed
Subscribe: Apple Podcasts | Spotify | Email | RSS | More
Design tends to be kind of difficult for software developers. Like marketing, writing, public speaking, music, or art in general, design seems to be an area that a lot of developers find intimidating. There is a general perception that design people are naturally artistic, better at reading the somewhat ambiguous rules of design, or have their finger on the pulse of industry best practices in a way that other people can’t grasp. While these things can be at least partially true, there are a lot of things that even a non-artistic developer can do that will result in better designs.
If you are a developer who is somewhat intimidated by design, that is no reason to despair. While an increasing number of companies are hiring designers and using design systems to build up their user interfaces, in many companies developers still have to design things. If nothing else, using good rules of design can allow your system to grow for long enough that a “real designer” can show up and fix any deficiencies. Best of all, if you follow these design considerations, you’ll often find that rather than immediately hating your work, that users will actually give you good feedback that makes you better at designing.
While you may not ever become a truly excellent designer, there is a lot to be said for a developer that can use basic design principles to produce a decent UI. Following the considerations outlined in this episode will make your user interfaces much better, while not requiring an undue amount of work on your part. Essentially this is the 20% of the work that will get you 80% of the results. These simple principles will make you a far better designer than many of the developers with whom you interact. And who knows? Once you get some basic principles down, you may find that you enjoy it.
Episode Breakdown
Why is this important?
There is not always a designer, and there is not always a good designer. Your team may not communicate very well with design, and doing decent work will help facilitate that. The design mindset is more user-oriented, rather than code oriented, but it will improve the quality of the code powering the design.
Why devs find design tough.
We tend to focus on WHAT, rather than WHY or HOW someone uses our software. We tend to be perfectionists, which inhibits our ability to make “good enough” designs to let us get moving. When we try to learn design, we tend to focus too much on design theory, rather than on the creation of useful feedback loops.
Basic Principles
UX elements in your system should be predictable and consistent. Your design should try to drive users to the pit of success and help them avoid errors. The language on screens should be sufficient, short and descriptive. Your screens should have a logical flow that matches the way the user thinks about the problem. You should use appropriate and consistent user interface elements based on the data that you hope to collect and how the user will interact with the system.
Color considerations
Picking appropriate colors is hard for many developers, especially because of the way we think about colors. Use HSL instead of RGB when picking colors. It makes it easier to find similar colors than the other schemes do. Consider color blindness and use software to test what your application looks like to people with this issue. Consider adding multiple color schemes or customization if your target market might demand it (like developers do with dark mode.)
Typography considerations
Your design should include a visual hierarchy, with the relative importance of elements denoted by their prominence on the screen. Font size, color, italics, etc. will help here a lot, as will the placement of the items on the screen. Things front and center are usually considered more important than things crammed off to the side. Typefaces should have good contrast with the background of the screen. In other words, make sure the colors are different enough that they stand out. When trying to make different elements stand apart from each other, do not increase scale linearly. Rather do so in a fibonacci sequence manner so that there is a bigger “jump” in size between larger elements that need to be kept distinct.
Image considerations
Images should be there for a reason other than decoration. Images should be relevant to what is occurring on the screen. Don’t use grainy images with low resolution. That wasn’t cool in 1997 and marks you as an amateur now. Consider having several sizes of the same image and making display adaptive so that you don’t waste bandwidth and you have sufficient quality.
Layout considerations
Use common patterns, such as the “holy grail layout” (header, footer, left and right sidebars). There are UX “design pattern” analogs. Use them. Use similar elements and structure across pages. Remember that being original is only good at the top level – being original everywhere is more properly denoted as simply being inconsistent. Consider working from a grid layout tool. It makes things easier to reason about and makes them easier to adjust, especially for non-designers. When scaling layout elements, using a fibonacci style of increased size is going to make more sense than a linear one.
Other concerns
Limit the amount of crap on screen. While it may be “cool” to make an app with high information density, it’s exhausting to use one. Don’t be dynamic with your layout unless it is truly needed. Reflowing of the design can be really annoying, especially on older or less powerful devices. It can even cause errors. Make sure and add ids to everything relevant on the screen. In addition to being able to address individual elements via CSS, this also makes it easier for other tools to interact with your system, including things like tutorial tools, such as Pendo, testing tools, etc. Be sure and include appropriate metadata for the elements in the design so that people using assistive technologies get a good user experience as well.
Book Club
The 17 Essential Qualities of a Team Player
John C. Maxwell
The thirteenth quality of a team player is Relational. “If you get along, others will get along too.” Maxwell starts off talking about Michael Deavers, chief of staff for Ronald Reagan. Deavers spoke to the fact that Reagan while a very shy person had a way of connecting with people, even opponents and press who disagreed with his policies. He was able to connect with so many because he genuinely liked people. He treated everyone with respect no matter their position. Maxwell goes on to describe five ways to know you have built a solid relationship with teammates. He states that everything begins with respect. You value each other. The next thing required for good relationships is shared experiences. Next is trust, a foundation for leadership and relationships in general. One way relationships are doomed to failure is when they are one sided, to build a team there must be a give-and-take relationship. Finally, teammates must enjoy being with one another to have a good relationship. Maxwell closes the chapter with four ways to better relate to your teammates: Focus on others instead of yourself, get to know them by asking good questions about them, spend more than just work time with them, and make an effort to show them they are special.
Tricks of the Trade
Showing up with table stakes is how you should try to get better at most things. Rather than simply showing up knowing absolutely nothing, show up having done some research and having learned some basics on your own. I notice this in some of the Russian facebook groups I’m in. Ask a detailed question and show your work and people will trip over themselves to help you; ask “how do I say ‘hi'” and people aren’t going to be friendly, because they’ve heard that question 15 times already today, and the day before, and the day before that. Be the kind of person that people actually want to help.