For engineers building user interfaces, I find there’s heavy emphasis on technical chops and little to none on design comprehension. Yet a subset of design skills can distinguish great from merely good UI engineers.
I’d term these skills “pre-visualization”: understanding design specifications before writing any code, and at a level beyond what designers formally deliver. A big part of pre-visualization is the ability to break down specs into reusable components. You discern visual patterns from existing parts of your app, site, or larger OS, and apply them to a designer’s work. In many, if not most cases, much of the spec maps cleanly to what came before. Common UI patterns like buttons, form elements, and navigation generally repeat themselves. Some will not.
To become a better web UI engineer, study design, communication, and vocabulary. Even if you cut back on some extra technical training, it’s worth it. That’s because the difference between good and great UI work rarely comes from technical prowess alone. It’s distinguished by creativity, visual insight, and sound organization.
Reusability is a bigger issue. Every time you change styling or write a new UI element, consider its impact elsewhere. Think ahead to where the application will grow and how you can cut repetition. It’s more than an blind grep through the code. It’s finding patterns. And visual patterns or usage trends are especially tricky to detect.
Flexbox is a powerful web styling tool, one my favorite recent CSS additions. It’s an effective replacement for hacky, float-heavy layouts. Given its wide browser support and mature feature set, I lean on Flexbox for most project work.
However, I’m surprised many developers stay away from Flexbox. They’re worried about browser support, a big learning curve, or otherwise strange behavior. They shouldn’t. Here’s how to get started.
Yet the effort necessary to keep web styling lean and efficient is overblown. The key is abstracting page level styling into reusable components.
Components are distinct groups of elements on a page. Common examples include navigation bars, carousels, and form sets. Components should be standalone, easily moved to different pages without breaking layout. Some styling methodologies substitute other terminology for components, calling them modules or blocks. And the size and scope of component usage differs widely among projects. Large projects, given their size and scope, tend to rely more on components than smaller works.
Web styling advances at a ferocious rate. Vanilla CSS is a rarity. Almost every web presence relies on new frameworks, preprocessors, and workflows. Yet even in the midst of progress, the fundamentals often trip up our work.
Our CSS fights against the natural DOM (Document Object Model) flow. The DOM flows from left to right, and from top to bottom. Block elements expand as wide as possible within a bounding container. Elements grow only as tall as absolutely necessary. The more we resist this flow, the more likely things break.
To avoid this, I follow three rules. Whenever my layout feels janky or otherwise hard to debug, it’s usually because I’ve strayed off course from these guidelines.
As a publishing platform, the web is on hard times. Paywalls and subscription plans are rarely successful. That makes ads and trackers the primary source of revenue. Yet ad tech is usually poorly designed, intrusive and inefficient. It slows down pages and pisses off users. That’s been underlined in recent articles highlighting the performance of The Verge , iMore and others. An otherwise simple news post bloats into megabytes of data, with ads and trackers taking the overwhelming share of that weight.
In the face of web bloat, users are opting out. Many strip out ad and tracker content with tools like AdBlock and Ghostery. Or they abandon the web for faster native publishing platforms like Facebook’s Instant News and Snapchat. Along these lines, Vox’s Ezra Klein predicts publishers morphing into a wire service, where the web becomes just one of many content platforms to publish on. Large publishers like Buzzfeed and The New York Times have already moved in this direction.
This is concerning. In reality, the web can be performant with ads, a subject matter for another post. A weakened web presence makes for an ugly future for publishing. It hurts the publishers themselves, and us, as readers.
Apple Music shares a lot of the same DNA as other streaming platforms. There’s a huge music catalog, the ability to save a collection offline, curated playlists, and radio stations. Yet its UX feels distinct, more segmented and compartmentalized compared to its streaming peers. That’s a plus for streaming newbies and more casual users. But it comes at the the cost of comprehension and cohesion in the long run.
It’s easiest to cover Apple Music’s UX shortcomings through example. Say you browse through playlists in New on iTunes, and then jump into the For You segment to browse further. At this point, there’s no way to jump back chronologically into your previously accessed playlists. Each segment has a separate state and history. Or you want to find the source (e.g. album, playlist, radio station) of the currently playing track. It’s often awkward if not impossible to do so. Even search adds a binary toggle between My Music and Apple Music to further separate results.
I recently attended the third annual CSSConf here in NYC. The conference scheduled sixteen speakers over two days with varied content and subject matter. Some speakers talked about the gap between design and development. Others touched on coworker relationships and styling for the web’s future, “post CSS”. Most focused on CSS-based web development. Here are a few takeaways that are easy for almost anyone to integrate into their workflow.
The redesigned Bloomberg Business has been controversial ever since its launch. To many designers, Bloomberg’s maximalist layout is tacky and garish. I think critics are missing the larger picture. The home page’s dominance is waning. Bloomberg’s brash, over the top design is an effort to make it relevant again.
User flow on “content first” sites (e.g. blogs, media, Tumblr) has shifted in recent years. Social media, share services, and content aggregators have fragmented web site’s visitor flow. Articles and other permalinks have replaced the home page as a site’s main entry point.
Many companies, most notably Buzzfeed, have thrived off this shift towards social discovery. So most of their attention, optimization and A/B testing focuses on article pages. Meanwhile, other pages that link to these articles (home, section, feed) feel ignored. Most still rely on a busy, reverse chronological listing that feels like a relic of web design from years ago.
Bloomberg, at first glance, follows this “article first” design methodology well. Their articles have the same share friendly article template – big social media buttons, full bleed imagery, provocative headlines – as the competition. Yet Bloomberg dramatically shakes up the design of their home and section pages, which have:
Highly opinionated, brand driven aesthetics. A bold use of color, bordering on (or pushing past?) garishness. Text overlapping imagery. Web 1.0 era gradients. Blocky headlines with large white padding.
Varied story density. Content is in a responsive-friendly grid format. Yet every Bloomberg section mixes up how much is presented, and where.
No linear or chronological order. The layout rarely follows a clear pattern other than a “top story” or two placed at the top. Some pages have low density sections followed by high density sections. Others reverse this layout.
Bloomberg designers realize the battle for engagement has blown beyond the initial article. Now it’s the page after – usually a home page, section page, or feed – that requires creative focus. A unique, memorable second page experience can build a web brand and improve the odds of return traffic.
Bloomberg isn’t alone in heavily revamping and stylizing their home and section pages. The Vox Media properties and Medium have taken similar actions; they’ve carved out an aesthetic niche (Vox leans towards maximalism while Medium thrives on its simplicity) and a fresh articles listing format.
Overall, it’s a welcome trend. With web sites increasingly reliant on sharing and social media for visits, article design is starting to feel a bit stale. Now it’s the pages that bind the articles together that are getting a shakeup, with Bloomberg, Vox and others leading the charge.
Great web projects don’t succeed on good design or development chops alone. Communication and collaboration among both designers and developers is just as important.
I’ve seen firsthand otherwise solid designers and developers botch a project just from miscommunication. And those poor relationships persisted beyond the life of the project. I’ve also seen novice designer-developer teams work in unison and deliver amazing results. They resolved potential pitfalls early, delivered their projects on time, and iterated quickly. Coordination isn’t just for projects either; a well coordinated team is a happier team. There are less misunderstandings and less tension if tasks aren’t going as planned.
The collaboration between design and development teams becomes critical in responsive web design (RWD) projects. There are now many devices to account for. Fixed, “pixel perfect” design is exchanged for fluid ratios and proportions. There are also extra image assets to optimize for different device sizes and resolutions.
In short: with RWD, there are more variables, more deliverables and more obstacles. Here are several techniques to overcome these hurdles in any RWD project.
Focus on “extreme” viewport sizes first
Most designs start from a static perspective. You pick a viewport width and height, then sketch or mockup from there. What do you focus on first with the dev team? What should be the first high-fidelity deliverables to hand off? Which devices get considered early for technical constraints?
I usually recommend to start designing with the smallest and largest common device sizes. When in doubt, base your range on general 2015 web analytics. 320px by 568px, the iPhone 5 in portrait, is a good choice for the small end. Apple’s older flagship is still popular yet small compared to other modern smartphones. For the large end, I like 1600px by 1000px, the size of a large browser on a desktop. Your audience may be different: skewed more towards mobile devices or desktop/laptop users. Check your analytics and change the range as appropriate.
You’re forced to make hard choices when you start with the smallest viewport size. You have to decide on the most important features in your design due to limited space. With the large end viewport, opposite considerations come into play. How much content is too much? Are text columns going too wide, affecting readability in a negative way? Should select elements receive extra white space? And addressing viewport extremes isn’t just about sizing, it’s also for different input methods. The smallest viewports generally use touch, while the largest rely on mouse and keyboard.
Discuss content layout between breakpoints
It’s easy to forget RWD is a fluid platform given the design attention on static wireframes and comps. Most of your audience won’t see the exact view as your static design. Instead these will tend to be a bit larger or smaller. So consider the layout adjustments necessary between different breakpoints and static comps you design. For example, when sizing down, text content may shrink in size. Image assets can drop into a single column.
Avoid making assumptions about what those adjustments will be with your development team. Be proactive: bring up adjustments before your developers are too deep in their work. For complex layout changes, create another wireframe or sketch to illustrate them. Where specificity is less important, a discussion or an email describing transitions can suffice.
Have an image asset strategy early
A common stumbling block between designers and developers is image formats and sizes. Smaller elements and icons might be PNGs, JPGs, icon fonts, or SVGs. There’s no one right answer; it depends on the content and resources available. But it’s important to agree on one format and stick with it. Also, you’ll likely develop patterns for common image sizes as your web project progresses.
Yet for modern RWD, that’s just the starting point. You’ll need at least two assets for raster formats (JPGs). One will be for normal displays and the other for high resolution ones. Advanced responsive image techniques need more assets to optimize for different viewport sizes.
Avoid leaving decisions on responsive image formats to the end of a project. At the bare minimum, have a strategy for display density. Read up on srcset and polyfills like Picturefill to ensure good cross-browser support. If it feels overwhelming, start small. Just altering a few image elements with the srcset attribute is a good first step. See how the process goes and grow from there.
Think atomic, modular design
My RWD workflow is influenced by Brad Frost’s thoughts on Atomic Web Design and Jonathan Snook’s SMACSS. Both frameworks rely on reusable, small components as the basis for strong web architecture.
So for developer handoffs, I like to concentrate on small and reusable components first. Smaller components generally keep the same UX and visuals across different devices. That consistency can be easier to digest for the development team. To boot, small components tend to be more reusable between pages on your design. So if you design an effective solution, it’s that much easier to re-apply it later on.
Imagine you’re designing a signup page with a headline, large graphic, and signup form. Depending on the device, these elements may shift around or change in size. Early on, focus on the smaller details of the signup form with the dev team. How does it look? What kind of validation is appropriate? How may a form component change with touch input versus mouse and keyboard?
Bring in developers for visual and UX feedback
Some designers shield developers from product meetings, usability sessions, and other opportunities for feedback. There’s a kickoff meeting, a handoff meeting, and little else. That’s a mistake. Remember that experienced developers are often an underrated knowledge base. They could have intimate knowledge of the product, especially if they worked on it for an extended period of time.
The skills of front end developers and designers also often overlap. Designers are starting to write their own code. Developers are learning about rapid prototyping, wireframing and aesthetic design. RWD has only exacerbated this trend. A developer can bring strong design insights without a formal “designer” title.
Granted, there’s still value in a separation of roles and responsibilities. Yet small steps toward inclusion can significantly assist the design of the final product. So for your next usability test, bring in a developer to discuss the outcome. Or if you’re on a design brainstorm, consult your developers for a second opinion.
All these techniques need planning and buy-in from others. With so much attention on launching products and hitting deadlines, that can be hard. But designer-developer relations are often underrated, especially for RWD projects. A small investment at the onset can have an exponential payoff for your team.