How I think about web design and development
I cut my web design teeth back in the mid-nineties designing and building two web sites for Virginia Tech's College of Agriculture and Life Sciences (Go Hokies!). This was back when they hired students to do this level of design work.
Over the last 20+ years building web sites and teaching how to build web sites, naturally I developed a set of opinions about how to do things:
Make it effortless
I worked for Circle.com, way back when Steve Krug's Don't Make Me Think! book was first published. It was to be the first in a series of books published by Circle.com and, I think ended, up as the only book published because of the Dot Bomb. But, I digress. Don't Make Me Think! is a big influence on how I think about approaching interactive design and usability. There are many ways to handle or manage UX design: creating wireframes, mockups, testing, etc. Whatever one uses though, to 'design UX', the goal is always to make the thing as effortless to use as possible--to get rid of the 'question marks' surrounding an interface or experience.
I think this principle applies to the design and dev process, too. If the design tool or code ceases to move the product towards usefulness, maybe it's not the right tool for the job. It's easy to get wrapped up in the deliverables, code, and processes and use the tool or process for the sake of using it because "that's what all the cool kids are doing."
Web standards
Standards are important. Adhering to standards as much as possible are important. Approaching web design and development with a focus on standards just makes things easier for everyone. Following agreed upon web standards is like having a guide to light your path through the chaos of browser support, accessibility, SEO, usability, and everything else that goes into building a web experience someone can enjoy.
Progressive enhancement
In a nutshell, progressive enhancement is a method or approach to designing and building web sites. The basic idea is to start with the least common denominator--what can most, if not all users, support--and build up from there. Users experience what they can support without being penalized for what they can't support. Ideally, a user shouldn't miss what they don't have access to. Conversely, graceful degradation is starting with the ideal experience and stripping away features as support wanes.
Over the time I've spent building web sites, I've tried both progressive enhancement methods and graceful degradation methods. Frankly, progressive enhancement is much easier to deal with. It is easier to build up than to tear down. A progressive enhancement approach also focuses on prioritizing what's important for users to get done what they need to get done without hindrance. A mobile first approach to designing and building for the web is an example of progressive enhancement thinking.
Semantics and structure
Semantic HTML and CSS is important. A good, solid structure is also important. This is true for any coding or mark up, but especially true for the document structure. Without a good HTML skeleton, the web page is little better than a pile of goo.
Kung Fu styling
CSS and styling shouldn't have to fight the browser. I feel like I'm in the minority on this one. Personally, I like to take a "Kung Fu" approach to my CSS and work with the browser to mold the design instead of shoe-horning it into shape. A good document structure makes this easier, as does improvements in the specs, standards, and browsers.
Like HTML, CSS should be semantic and structured. There are lots of opinions out there how to do it. Mine are:
- SMACSS makes the most sense
- Use classes as semantic labels describing the content, not the design
- Start with broad-brushstrokes (styles) and work towards the details
- Change only what needs to changing
Clean code is good karma
When I first got started in web design, back in the mid-90s (phew), I taught myself a lot by looking at other sites' coding. Even today, I'll inspect or view source to learn how someone built it (I especially appreciate Codepen for this). That always stayed with me and it's something I try to give back. As much as possible, I try to write code so that someone else can follow it and maybe even learn from it. For teaching code, this habit became a necessity. For going back and debugging work done months or years earlier, it's a Godsend.
Hacks are for dudes
This is an outgrowth of everything mentioned above. My experience is that if I'm down to using hacks to get something to work, it is time to find a different approach. Sometimes, maybe I'm not doing whatever it is right in the first place, or I misunderstood the problem, or I need to look at the problem from a different angle. Most of the time, I can get rid of the need for hacks by addressing one (or more) of these issues.
Always be learning
There was about a six-month period in the early 2000s where I think I knew all there was to know about web design. Then that window passed. Or, I realized I didn't, in fact, know everything. Either way, I'm glad the web industry is one that is constantly changing and evolving--even if that gets exhausting. There is always something new and interesting to learn. Teaching web design for so long forced me to stay on top of new techniques, trends, and evolving best practices. I want my students to go out prepared for what's coming and not what's already been.