Jon Yablonski

Tool-Building with AI

Wed, 29 Jan 2025 00:00:00 +0000

Imagine a future where any software tool you need can be generated on the fly, completely free of charge, and custom-tailored to your specific needs and preferences. Whether it’s a tool for submitting your taxes, measuring data, or finding great restaurants near you—how might the world of software look if tools could be generated in a matter of minutes by everyone?

The democratization of software creation has long been part of the vision for how humans and computers would interact. Alan Kay, renowned for his groundbreaking work on object-oriented programming and graphical user interfaces, envisioned a future where users would become creators—not just consumers—of technology.¹ His vision focused on equipping users with powerful yet accessible tools to create their own software and media. Smalltalk exemplified this vision: a programming language that let users create and modify programs within a unified environment. Kay provided pre-written tools and examples, enabling people to build their own creative tools without needing extensive programming expertise.

Kay‘s vision in many ways built upon the ideas of Doug Engelbart, who envisioned a future in which computers and humans would collaborate seamlessly to amplify intellectual capabilities ². Engelbart believed that individuals, using computers with advanced interfaces, could develop their own tools and systems to enhance their collective problem-solving abilities. This vision has also heavily influenced more recent no-code approaches like Notion and Retool, which are actively working to revolutionize the landscape of personal software creation, focusing their efforts on making toolmaking accessible and universal. Their mission centers on empowering individuals from all backgrounds to customize and adapt their software environments to match their precise requirements, whether for personal organization, project management, or collaborative work. This approach represents a significant step toward realizing the long-held vision of democratized software creation.



Notion’s mission is to make tool-making ubiquitous.

While tools like Notion are incredibly powerful, they still restrict what is possible for its users to create. The ability to create custom software solutions still remains somewhat limited to those with technical expertise, modern tools are beginning to bridge this gap in meaningful ways. However, Large Language Models (LLMs) have ushered in a new era of software democratization, fundamentally transforming how individuals interact with and create technology. These sophisticated AI models have dismantled traditional barriers to entry, providing an intuitive interface between human intent and computer functionality. By interpreting natural language instructions and converting them into functional code, LLMs have made the process of creating custom software tools remarkably accessible. This technological breakthrough lowers the barrier for individuals from diverse backgrounds, regardless of their programming expertise, to conceptualize and bring to life their own software solutions whenever the need arises.

The ability to generate, modify, and iterate on custom tools through simple conversation with AI has effectively bridged the long-standing gap between technical capability and creative vision.

Why Build?

Let’s start by addressing a big question: why should anyone go through the hassle of building their own tools? Today’s software landscape presents numerous significant challenges that profoundly impact both the development community and end users alike. The current ecosystem is characterized by various constraints and limitations that affect how software is distributed, monetized, and utilized.

App store monopolies

First off, app store monopolies wield substantial control over software distribution channels through their comprehensive ecosystem management. These platforms implement extensive and often restrictive guidelines that developers must strictly adhere to, while simultaneously extracting significant percentages from developers’ revenues - sometimes as high as 30% of all transactions. This centralized control and revenue extraction model creates substantial barriers to entry for smaller developers, potentially stifling innovation in the software industry. Furthermore, these practices directly influence pricing structures, often forcing developers to increase their prices to compensate for platform fees, ultimately affecting end-users’ access to affordable software solutions.

Subscription-based models

Secondly, the widespread adoption of subscription-based models has fundamentally transformed the software industry, marking a significant shift in how users access and pay for applications. This transition has moved away from traditional ownership models, where users could make a one-time purchase and own software outright, to a system of recurring payments that require ongoing financial commitment. This new paradigm, while providing regular revenue streams for developers, has created a persistent financial burden for users who must now maintain multiple subscriptions to access the tools they need. The shift has particularly impacted individuals and small businesses who find themselves navigating an increasingly complex landscape of subscription tiers, feature limitations, and accumulating monthly expenses that continuously drain their resources over time.

One-size-fits-all approach

Lastly, most software solutions tend to impose rigid, predefined behavior patterns on users instead of adapting to match individual workflows and preferences. These standardized applications often force users to modify their natural working styles to fit within the constraints of the software, effectively shaping their behavior to fit the tool. This one-size-fits-all approach frequently implements inflexible, predetermined methodologies that fail to accommodate the diverse and specific requirements of different users. When software lacks the flexibility to adapt to unique user needs, it can lead to inefficient workarounds, decreased productivity, and ultimately, diminished user satisfaction. The disconnect between how users naturally work and how software expects them to work creates unnecessary friction in what should be a seamless interaction between human and machine.

Exhibit A

At the end of last year, I faced a specific software need related to my workout routine. Since muscle growth can stagnate when repeating the same exercises weekly, I wanted to vary my routine. While my exercises were documented in a notebook, modifying them meant creating entirely new pages. This analog approach lacked the convenience of digital tools—the ability to easily modify, share, and extend the content.

I could have simply found an existing app to solve this problem, but I would have missed a valuable learning opportunity with creating something more custom-tailored to my needs. So I decided to build my own solution while exploring new tools. Claude AI topped my list of technologies to try, as I had been following its rapidly expanding capabilities. After just a few prompts, I had created a working prototype that could generate workouts and randomize exercises within them.

Workout Planner prototype in Claude AI

While the prototype was impressive given how quickly I built it, I soon encountered limitations with Claude. The generation limits hindered my ability to fix emerging bugs, and the time required to regenerate the entire app after each prompt became cumbersome. It became clear that to advance the project further, I needed to move beyond Claude.

I turned to Cursor, an intelligent coding environment that leverages advanced AI models to assist developers in writing, editing, and understanding code. After having Claude generate the necessary files for a React app, I imported them into Cursor, installed the dependencies, and began adding features immediately. Within days, my simple exercise-shuffling prototype evolved into a full-stack, responsive web app—complete with authentication, workout tracking and planning, theme switching, ExerciseDB integration for exercise demonstrations, and AI-powered workout generation based on simple descriptions. All of this was accomplished without writing a single line of code.

Workout Planner web app build with Cursor

My favorite anecdote about building this app was during a plane flight at night when the default like mode was much too bright. In a single prompt, I was able to not only implement a theme switcher and enable dark mode, but do so in a way that remembers your preference and serves up the appropriate theme on subsequent visits. Within a minute, I had managed to fix my problem and continue working on the app during my flight. This functionality alone would have taken considerably more time to implement had I coded it myself.

Interested in hearing more about my process for building with AI? I’ll be posting more about this in the coming weeks, so stay tuned!

I’ve since built even more bespoke tools that address a specific need following this same process. During this time, one thing has become increasingly clear: the barrier for creating sophisticated tools has been dramatically lowered, not to mention the speed it enables. Spinning up a tool to solve a problem or mundane tasks I’m facing has become my default. It’s led me to wonder about what the future of software might look like, how our relationship with software will change, and how the software we’ll use in the future is built.

The future of software is personal

AI-powered tool creation presents an alternative future to the software paradigm we’ve lived with for years. Imagine being able to generate custom software solutions instantly, without worrying about app store restrictions or recurring subscription fees. This democratization of software creation could lead to a world where tools are truly personalized - shaped by our unique workflows and preferences rather than forcing us to adapt to their limitations.

In this future, software becomes more of a conversation than a product. Need a specific tool for your workout routine? Generate it. Want to modify how it works? Simply ask. The barrier between having an idea and creating a solution disappears, enabling everyone to become a tool creator rather than just a tool user.

Manovich, Lev. (2007). Alan Kay’s Universal Media Machine. Northern Lights: Film and Media Studies Yearbook. 5. 39-56. 10.1386/nl.5.1.39_1. ↩︎
Engelbart, D.C. (1962). Augmenting human intellect: a conceptual framework. ↩︎

User Research Myths

Wed, 15 Jan 2025 00:00:00 +0000

A lot of companies struggle to get on board with user research because of some pretty common myths. While they might sound legit at first, digging a little deeper will uncover a gap in understanding how research really works, it’s importance for making informed design decisions or the need to align designs with user expectations. Let’s look at the most common myths about user research and how to avoid pitfalls.

It takes too much time

Let’s talk about a big myth: that user research eats up tons of time and resources. You see this a lot, especially when the higher-ups haven’t really gotten the hang of what research is all about. When deadlines are looming, it’s super tempting for teams to just skip the whole “getting to know your users” part.

However, user research doesn’t have to be this huge, time-consuming project. Take user interviews, for instance. You can totally fit them into whatever schedule you’ve got, and you’d be amazed at how quickly patterns start popping up after chatting with just a handful of people. Plus, you can keep these interviews running in the background while you work on other stuff, so you’re getting all that juicy feedback without putting everything else on hold.

Our PMs already talk with our users

Product Managers chatting with users is great, but it’s not quite the same as proper user research. PMs are usually zeroed in on specific features or putting out fires, which means they might not get the full picture.

Think of it this way: proper user research focuses on asking the right questions without leading people on. It’s optimized for spotting patterns and digging deeper into what users are really saying, not just what’s on the surface. Plus, let’s be honest - PMs often have their own goals and pet features in mind, which can totally color how they see user feedback. User research keeps things neutral and makes sure we’re actually hearing what users need, not just what we think they need.

When you actually dig in and do the research, you often find all these little details you would’ve totally missed just going with your assumptions.

We already know what our users need

You know how it goes - when you’ve been working on something forever, you start thinking you’ve got your users all figured out. “Oh yeah, I totally know what they want and how they use our stuff," you might tell yourself. And before you know it, you’re making all these decisions based on what you think you know.

Going with your gut feelings alone can lead you down the wrong path. Sure, your experience counts for something (and that’s awesome!), but you’ve gotta back it up with some real research to make sure you’re not missing anything important. When you actually dig in and do the research, you often find all these little details you would’ve totally missed just going with your assumptions.

We’ve already done user research

Users are constantly changing how they do things, new tech keeps popping up, and the market’s always shifting around. You can’t just rely on that research you did way back when. It’s like trying to navigate with an old map - sure, it worked great before, but now there might be new roads and shortcuts you’re totally missing out on.

It’s super important to keep checking in with your users regularly. It helps you stay on top of what’s actually happening now, not what was true six months ago. Plus, it’s a great way to catch any problems early on, before they turn into bigger headaches. Think of it like regular check-ups - they help you spot issues while they’re still small and fixable!

It didn’t uncover anything unexpected

You know what’s funny? A lot of teams think user research is only worth it if it blows their minds with shocking discoveries. When nothing super surprising comes up, leadership is like “meh, what’s the point?”

Sometimes getting proof that you’re on the right track is just as awesome! It’s like getting a thumbs up that says “yep, you’ve got this figured out.” Plus, it helps everyone sleep better at night knowing they’re not just shooting in the dark. When research backs up what you already thought, it’s like having a solid argument in your back pocket for when someone questions your decisions.

The cool thing about user research is that it’s super flexible and gives you solid proof that your decisions are on the right track. Instead of treating it like a one-and-done deal or something you can skip, think of it as your secret weapon for avoiding costly mistakes and keeping your products in tune with what users actually want - especially since everything changes so fast these days!

Bottom line? Once teams get past these myths and start making research part of their routine, they make smarter choices and end up with products that really hit the mark.

2025 Reading List

Tue, 07 Jan 2025 00:00:00 +0000

Reading has long been a reliable source of insight and inspiration. In 2025, I’ll be digging deep with some carefully selected books that I intend will fuel my professional growth. Spanning design, technology, strategy, and human behavior, these works will shape my approach to design challenges in our rapidly evolving technological landscape.

I’ll be sharing my learnings and reflections on these books at the end of the year, so stay tuned for updates on this reading journey.

The User Experience Team of One: A Research and Design Survival Guide (2nd Edition)

By Leah Buley & Joe Natoli / Rosenfield Media, 2024

The User Experience Team of One:** A Research and Design Survival Guide

This is an insightful guide to maximizing impact as a UX designer from seasoned pros. Comprehensive and approachable, Joe and Leah have synthesized knowledge and tools with clarity and straightforwardness. I anticipate it’ll be an invaluable resource for both new and experienced designers that I’m excited to dig into.

I’m also thrilled to see there’s a shoutout to my book, Laws of UX: Using Psychology to Design Better Products & Services included. Additionally, the Laws of UX card deck is also highlighted!

Co-Intelligence: Living and Working with AI

By Ethan Mollick / Penguin Random House, 2024

Co-Intelligence: Living and Working with AI

Mollick shows what it means to think and work together with smart machines, and why it’s imperative that we master that skill. He challenges us to utilize AI’s enormous power without losing our identity, to learn from it without being misled, and to harness its gifts to create a better human future. Wide ranging, hugely thought-provoking, optimistic, and lucid, Co-Intelligence reveals the promise and power of this new era.

Clear Thinking: Turning Ordinary Moments into Extraordinary Results

By Shane Parrish / Portfolio, 2023

Clear Thinking: Turning Ordinary Moments into Extraordinary Results

I’ve long been a fan of the Farnam Street blog, the host of The Knowledge Project podcast, so this book caught my attention right away. This book is about recognizing the pivotal moments between stimulus and response – and learning to deploy our full cognitive capacity to them. Through engaging stories and powerful mental models, it shows us how to turn our desired behaviors into our default behaviors.

Mindful Design: A Survival Guide for Responsible Product Designers

By Scott Riley / Apress, 2024

Mindful Design: A Survival Guide for Responsible Product Designers

Design is a responsibility, but not enough designers understand the human mind or the process of thought. This book introduces the areas of brain science that matter to designers, and passionately explains how those areas affect each human’s day-to-day experiences with products and interfaces, providing a battle-tested toolkit to help you make responsible design decisions.

The Six Disciplines of Strategic Thinking: Leading Your Organization into the Future

By Michael D. Watkins / Harper Collins, 2024

The Six Disciplines of Strategic Thinking: Leading Your Organization into the Future

As a designer, I’ve becoming increasingly aware that making great design is not enough to have impact within your organization. To optimize your value and impact, you must also be strategic. This book presents an actionable new framework to help people learn to think strategically—a set of skills more necessary than ever in a world of constant change.

From Counterculture to Cyberculture: Stewart Brand, the Whole Earth Network, and the Rise of Digital Utopianism

By Fred Turner / University of Chicago Press, 2006

From Counterculture to Cyberculture: Stewart Brand, the Whole Earth Network, and the Rise of Digital Utopianism

I love connecting the dots and understanding the history behind my craft. This book, recommended to me by Bob Baxley, promises to do just that. It’s the first book to explore the extraordinary and ironic transformation of computers from bleak tools of the Cold War to collaborative and the driving force behind a digital utopia modeled on the communal ideals of the 1960s counter culture. Turner traces the previously untold story of a highly influential group of San Francisco Bay–area entrepreneurs: Stewart Brand and the Whole Earth network.

Universal Principles of UX: 100 Timeless Strategies to Create Positive Interactions between People and Technology

By Irene Pereyra / Rockport Publishers, 2023

Universal Principles of UX: 100 Timeless Strategies to Create Positive Interactions between People and Technology

I’ve long been a fan of the work from Anton & Irene, so this book was a must have. This book is a philosophical anthology of case studies, situations, problems, and contradictions encountered across more than fifteen years of working on real world client projects that will teach you how to think, rather than tell you what to do.

2024 Year in Review

Thu, 02 Jan 2025 00:00:00 +0000

Projects & Initiatives

2024 marked significant milestones in my professional journey, particularly with Laws of UX. In February, I released the second edition of the book, which quickly became the #1 new release in user experience & website usability on Amazon. The book’s reach expanded globally with translations into Bulgarian, Korean, German, Thai, and Portuguese (in addition to the 10 translations of the first edition).

The 2nd edition of Laws of UX: Using Psychology to Design Better Products & Services (O’Reilly Media, 2024)

The Laws of UX website also experienced substantial growth with fresh content, new articles, and a French translation—making the resource accessible to a wider global audience. Also, I finally added a light mode theme! I’m excited with how the site has continued to grow and evolve, and I plan to build upon this momentum in the coming year.

I also continued growing Humane by Design with a new article on the cost of personalization and what we lose when algorithms make autonomous decisions on our behalf. The digital garden also grew with a few new ideas and the resources were updated on a continual basis.

[Humane by Design](https://humanebydesign.com/)

Another significant focus this year has been a variety of Mixpanel projects, namely those related to Data Governance and the launch of Session Replay. These projects have been incredibly challenging from both a design and collaboration perspective, and I’ve learned and grown as a result. I look forward to continuing to push these projects and grow as designer, as a strategic thinking, and as a teammate.

In recent months, I’ve focused on developing personal tools using generative AI. It’s been exciting to not only explore AI’s capabilities but also to build tools that serve my specific needs. While I remain cautiously skeptical of generative AI as a universal solution, it has unlocked capabilities that would have required significantly more time and effort in the past. Stay tuned for updates on these projects!

Speaking

I’ve been making a concerted effort to invest in my storytelling and presentation skills over the years, and this dedication shone through in the various speaking engagements and workshops I conducted in 2024. The highlight of the year brought me to Budapest to present at the 10-year anniversary of Craft Conference. I’m deeply grateful for the opportunity to share at such an engaging event, for the memories made in the beautiful historic city of Budapest, and for the new friendships forged along the way. Opportunities like this fill me with energy and inspire me to continue building and exploring.

On stage at Craft Conference (Budapest, May 2024)

It was also an honor to share with students at the University of Michigan - School of Information—not once but twice! Engaging with such bright minds and contributing to their journey in shaping the future of design was truly inspiring. It’s also a great reminder of why I love sharing with aspiring designers and always seem to leave feeling energized after those visits.

Guest lecturing at SI 307 at the University of Michigan - School of Information (Ann Arbor, Oct 2024)

Speaking at AAF Memphis held special meaning, as it offered me the chance to return to where my journey began. I was thrilled to visit, share a topic I’m deeply passionate about, and reconnect with college friends while reminiscing about our memories at Memphis College of Art.

It was also an honor to be the inaugural speaker of the Mondo Robot Book Club. I’m always exciting to share and discuss a topic I’m so passionate about with fellow builders, and this particular visit was quite engaging. Other events include Portland Design Month, conducted workshops with MICA students, spoke with students at Code School Barcelona, and presented at several smaller online events.

Mondo Robot Design Series: Book Club - Laws of UX Q&A (May 2024)

Interviews

In 2024, I participated in several engaging interviews that allowed me to explore topics close to my heart. A notable highlight was my interview with Lovers Magazine. I also had a great conversation on Unfolding Innovation, where we discussed UX design principles, psychology’s role in digital products, my professional insights, design ethics, and emerging technologies like AI and spatial computing. I also enjoyed speaking with Andrés Zapata about the 2nd edition of Laws of UX and sharing my perspectives on The Inner Game of Change podcast with Ali Juma.

[Lovers Magazine interview](https://spaces.is/loversmagazine/interviews/jon-yablonski) (May 2024)

Writing

I didn’t write extensively this year, which I attribute to spending much of 2023 focused on the 2nd edition of Laws of UX. I was admittedly a bit burned out on writing. Nevertheless, I published several articles that I thoroughly enjoyed developing. A highlight was Journey Reflection, which explored the key projects, people, and lessons I’ve encountered along my path. Taking time to contemplate these formative experiences proved deeply cathartic.

Journey Reflection was a reflection the key projects, people and learnings that I’ve gathered along my professional journey.

I also expanded Laws of UX with new articles that add depth to the website and support its psychological theories and concepts. My favorite piece, Familiar vs Novel, examines when designers should break from familiarity in favor of novelty. This article stemmed from a frequent question I receive about Jakob’s Law, and I’m glad I finally captured my thoughts on the topic.

Travel

Traveling to new places is one of my favorite things, and 2024 brought several exciting destinations. The year began with a Mixcursion in Las Vegas—Mixpanel’s annual company retreat for team building and celebration. While gambling isn’t my scene, experiencing the city for the first time was memorable. The highlights were Omega Mart by MeowWolf and Valley of Fire state park.

Valley of Fire state park, (Nevada, Mar 2024)

For Spring Break, we ventured to Arizona, horseback riding in Phoenix before exploring Sedona. Watching my daughters discover new places brings me joy—there’s something incredibly fulfilling about exploring the world together. The Grand Canyon was particularly spectacular, serving as an awe-inspiring testament to our planet’s beauty.

Grand Canyon, (Arizona, Mar 2024)

Some visual exploration I did following the Sedona trip, which was inspired by the Sedona’s famous vortexes. These locations are thought to be where the Earth’s energy is amplified and concentrated.

Budapest, however, stood out as my favorite trip of the year. My first visit to Hungary and Central Europe exceeded all expectations. I immersed myself in the excellent Hungarian cuisine, marveled at the grand architecture and monuments, strolled along the Danube River, and explored the unique ruin bars. The city’s rich and complex history, like that of any ancient metropolis, fascinated me.

Budapest, (Hungary, May 2024)

My first trip to Mexico rounded out the summer, as I traveled to Cancún for my cousin’s wedding. It was the perfect blend of family time and tropical paradise. Between the beautiful ceremony, mesmerizing waters, and perfect weather, the trip was magical—and we fortunately departed just before Hurricane Helene arrived.

While I also revisited some familiar places throughout the year, these new adventures stood out. I’m eager to maintain this exploratory momentum into 2025 and add even more destinations to my list.

Personal Development

2024 was in many ways a continuation of some good habits I’ve formed over the years. A continued focus on fitness and health, reading, research and tinkering with side projects or ideas were all weekly if not daily rituals that I’ve normalized.

I maintained my focus on fitness and health with consistent weekly weight training sessions. While I scaled back on running, I added kickboxing to my routine after installing a heavy bag in my home gym. Moving my workouts to mornings has transformed them into an essential part of my day that I genuinely look forward to. A greater emphasis on stretching has helped me stay injury-free. I plan to continue this momentum into 2025, building upon the progress I’ve made over the years.

I also made an effort to read more in 2024. While I didn’t finish as many books as I would have liked, I did cover a lot of ground. My favorite book was Build: An Unorthodox Guide to Making Things Worth Making by Tony Fadell. As a builder, I found this book incredibly fascinating and insightful in the way it blends experiences, history, anecdotes and advice. Other books that found my way on the reading list were Poor Charlie’s Almanack: The Essential Wit and Wisdom of Charles T. Munger, Universal Principles of UX: 100 Timeless Strategies to Create Positive Interactions between People and Technology, and The Six Disciplines of Strategic Thinking: Leading Your Organization into the Future.

Challenges

2024 brought significant challenges. Two of my closest friends lost their mothers this year, following my own mother’s passing the year before. Losing a parent is incredibly difficult and illuminates life’s finite nature, forever changing how you view the world and your time in it.

Other challenges in 2024 involved interpersonal relationships, particularly in achieving alignment and making meaningful impact. Though frustrating at times, I’ve come to see these difficulties as opportunities for growth. From this perspective, I’ve gained valuable insights and remain optimistic about the year ahead.

Looking Forward

Looking ahead to 2025, I’m ready to build on the strong momentum from this past year. My speaking engagements and workshops, professional work, and personal growth have created a solid foundation that positions me well for new opportunities. I’m energized to take on fresh challenges, deepen my expertise, and push the boundaries of what’s possible both personally and professionally.

Journey Reflection

Mon, 12 Aug 2024 00:00:00 +0000

A journey reflection involves looking back and considering the key projects, people, and lessons you’ve encountered in your professional life. It’s a chance to think about the important experiences that have shaped and guided you rather than documenting everything you’ve done.

I believe that in order to truly understand where you’re headed, you must first understand where you’ve been and why you’re where you are in the present. In this way, a journey reflection is a tool for illuminating a path you might not otherwise see. This is my journey reflection.

Building the foundation

Memphis College of Art — 2003-2008

Art school ¹ taught me many things: foundational creative skills, ways of seeing, critical thinking, craft, art and design history, and much more. But perhaps the most important skill I learned was how to learn. The ability to learn new things has been foundational to my career and a skill I’ve used repeatedly. When I graduated in 2008, the world was reeling from the Great Recession, and this skill came in handy upon entering the workforce.

Memphis College of Art, Rust Hall circa 2016

Learning the hard way

ful — 2009

Some lessons must be learned the hard way. My first job out of art school was as an in-house designer at a company specializing in backpacks and apparel. The focus of this role was on printed material: promotional catalogues, hang tags for the backpacks, packaging, etc. It also gave me the opportunity to hone the photography skills I had learned in college as a dual major in graphic design and photography. However, I quickly realized that traditional graphic design was not what I wanted to do with my career. I was lucky to learn this lesson early. I spent many lunch breaks and free time at the nearest bookstore, devouring the latest web design magazines like net ² and Web Designer.

Coming online

First Online Portfolio — 2010

I needed an online portfolio because the physical one I took to interviews felt increasingly outdated. Unfortunately, there weren’t many great no-code options available at the time. So, I started learning to code. I began by printing the source code from websites I liked and studying each line to understand how it worked. I was hooked by the time I launched my first hand-coded online portfolio in 2010. This was the beginning of my fascination with building things for the web—a skill that proved very useful later on. Over the next few years, I pushed myself to learn more and apply my new skills.

Jonyablonski.com circa 2010

Few skills have benefited me in my career as much as learning to be proficient with the basic building blocks of the web. The ability to build what you design or imagine feels like a superpower. While I don’t believe designers must learn this skill, I do believe a basic understanding of underlying principles will produce better designs and improve communication with engineering counterparts.

Under-promise; over-deliver

Boingo Redesign — 2012

A pivotal moment came during a project for the mobile Internet access provider Boingo. I was working at the time within an agency tasked with redesigning their digital presence. One night during an after-hours jam session, I was invited to stick around and pitch in. To my surprise, my concept was selected by the client. When it came time to further develop the concept, I had an idea: I would use the cutting-edge techniques of responsive web design that I had just learned about. The responsive demo was a hit and it launched me headfirst into a challenge that would shape the rest of my career. During this project, I discovered a valuable skill in connecting the world of code and design to build well-crafted experiences. From that point on, I knew where I wanted to focus.

Reponsive demo of the Boingo rebrand circa 2012

A lot of the work my team and I did for Boingo is still visible when connecting to Wi-Fi portals in airports all over the world! The next time you’re at an airport and connect to Wi-Fi, there’s a high likelihood that you’ll get a glimpse of it. One of my favorite aspects of these designs is the playful iconography created by Garrett Wieronski.

A new obsession

Native Eyewear Redesign — 2013

After the success of the Boingo project, I was invited to work on another redesign, this time for the sunglass and apparel brand Native Eyewear. This project was foundational to my growth in several ways. First, it allowed me to design and develop a component library for an external development team. Second, I built an interactive and responsive prototype of the e-commerce interface. The most important lesson, however, was learning the process behind building great user experiences. The drive to build digital experiences that looked great, functioned well, and were tailored to those using them became an obsession from that point on.

Screens from the Native Eyewear 2013 redesign

A fire is started

Web Field Manual — 2014

I was invited to attend my first major design and development conference, An Event Apart ³, in late 2013 in San Francisco. The experience was incredibly enlightening and inspiring, leaving me with a ton of links, tools, and talks — all of which I was eager to share with my colleagues. Then it occurred to me: why collect and share all this great knowledge in a presentation only for it to be referenced a couple of times? I decided to use my learnings from the conference to build a website instead, hoping it would be more useful. This website became the Web Field Manual — my first side project and contribution to the design/development community. To my surprise, it turned out to be valuable for many other folks too and ignited a passion for side projects.

The Web Field Manual is a curated list of resources focused on documenting only the best knowledge for designing experiences and interfaces on the web.

I believe that personal side projects can be a cornerstone of creative growth and discovery. While they might not always result in financial gain, the long-term benefits are often much more valuable. I attribute side projects as one of the biggest factors in my own growth and the catalyst for many opportunities.

A time of focus

Mopar Redesign — 2016

The end of 2014 brought significant changes: a new city, becoming a first-time dad, and a new job. I had just made a big career leap, leaving the marketing agency I’d been at to focus on my growing design and development skills. By 2016 that leap paid off when I joined a team focused on a major redesign for the automotive parts and customer-care brand Mopar. The challenge was to create a seamless digital ecosystem from a multitude of websites that had diverged over time to improve the customer experience and strengthen the relationship between owner, vehicle, and dealer. My small team was tasked with not only consolidating all the features of each website into a single mobile-friendly ecosystem but also unifying the branding into a cohesive visual language. To make things more complex, we needed to develop a flexible theming system that could adapt to each vehicle brand (Jeep, Dodge, Ram, Chrysler, Fiat).

This project both challenged and pushed me. It gave me the opportunity to build my first design system, broaden my knowledge of UX research and how to leverage it, build and iterate on prototypes, design for mobile, and much more. I am immensely grateful to the folks at Vectorform ⁴ that gave me this opportunity, to my colleagues with whom I built lasting friendships during this time, and for the invaluable growth that I experienced as a result.

Mopar design system circa 2016

A time for experimentation

Swiss in CSS — 2016

By 2016, I had gotten into the habit of picking up side projects to expand my skills during the cold, snowy winters in Michigan. My goal was to explore new CSS animation features to bring classic International style posters to life, which I had always admired. The result was Swiss in CSS: a homage to the International Typographic Style and the designers who pioneered this influential design movement. This project was monumental for me, not only in terms of skill and craft but also due to its recognition. Most notably, it was awarded the Site of the Day by FWA, featured in net magazine (RIP), and highlighted in Fast Company’s Design blog.

Swiss in CSS is a homage to the International Typographic Style and the designers that pioneered the ideas behind the influential design movement.

Finding my passion

Laws of UX — 2018

Laws of UX started as a simple resource that I needed but couldn’t find online. Since then, it has expanded into a comprehensive web resource, a poster series, a book now in its second edition, and a card deck. I often hear from people who share how valuable this project has been for them, which means a lot to me. It’s humbling to know that something you’ve created has helped many people worldwide and continues to do so.

I’ve learned many things from this project and continue to learn all the time. Evolving and maintaining the website has been a huge undertaking, teaching me about accessibility, localization, theming, and an ongoing lesson in listening, processing, and iterating based on user feedback. Most importantly, it’s been an opportunity to deepen my knowledge of psychology and user experience design, benefiting my practice as a designer.

Laws of UX is a collection of best practices that designers can consider when building user interfaces.

Finding my voice

Writing & Speaking

Finding your voice can take some time. I’d been publishing articles on my own for a while, but the success of Laws of UX pushed me to challenge myself with even more ambitious goals. Getting articles published on sites such as Smashing Magazine, CSS Tricks, and A List Apart were milestones for me in building confidence in my own ideas. It was around this time that I also challenged myself by taking to the stage and sharing ideas at conferences and events. The thought of speaking on stage was fear-inducing for me, but something I was ready to face head-on. Looking back, I’m glad I did because it’s exposed me to new ideas, people, and opportunities.

On stage at Craft Conference (Budapest, 2024)

I’ve long shared the view that writing is thinking. It takes a lot of synthesis to articulate an idea, process, or method clearly. For that reason, I think writing is a great way to internalize your own ideas and experiences. It’s been one of the biggest contributing factors in my own growth and development.

Taking the initiative

VCS Design System — 2019

I joined the User Experience team at General Motors at a time when I was ready for a new challenge. My first role was to build a design system to support the infotainment systems for all GM vehicle brands starting with the 2021 models. Calling it a daunting challenge is an understatement. Nevertheless, fellow designer Adam Tramposh and I tackled it head-on. We produced a comprehensive system that is still in use today. The technical complexities were one part of the challenge, but getting organizational buy-in and coordinating with software engineering was another. I learned a lot during this time and internalized a key mantra: don’t wait for permission to build what’s needed — take the initiative.

VCS infotainment system

Expanding my thinking

Humane by Design — 2019

Another project I’m very proud of is Humane by Design. I believe people want technology to empower them, amplify their abilities, and make their lives easier. The reality is that many products and services—even those renowned for being well-designed—sometimes use exploitative practices that monopolize people’s time and attention, prioritizing business goals over human goals. This project’s focus has always been to imagine “what if” instead of accepting the current reality. Much like the Laws of UX project, I’ve learned many things from this one and continue to learn all the time. It’s guided my thinking and principles around design and what technology can and should do.

Humane by Design provides guidance for designing humane digital products and services focused around digital well-being.

Developing conviction

Celestiq Interaction Framework — 2020

Every once in a while, an opportunity comes along that you know will push and challenge you in new ways. I knew this right away with the Celestiq Interaction Framework project and dove in headfirst. The goal was to reimagine the infotainment experience for the Cadillac Celestiq — a cutting-edge EV. The system I led the design on was ultimately not put into production, but the learnings from this experience were invaluable. This project was deeply influential to my development, solidifying my appreciation and know-how for user research and testing, crystallizing my career path as a builder versus management, and much more. I owe a massive thanks to Andy Gellatly for the opportunity and guidance on this project because it shaped my thinking and trajectory.

Cadillac Celestiq IVI

Nothing that’s worth it is easy

Laws of UX Book — 2020

“Nothing that’s worth it is easy” was a bit of wisdom shared with me that stuck while I was struggling in art school. I remembered this lesson when I was approached to write a book. Even though writing a book had always been a goal of mine, it didn’t make it any easier. The truth is that writing a book is no small endeavor. It takes incredible dedication, sacrifice, and determination to complete. However, few things in my career have been as meaningful and impactful.

Laws of UX book, 2nd edition

New challenges

Boom Smart Routing — 2021

The COVID pandemic changed the world in many ways. One positive outcome was the new remote opportunities that became available. I joined my first startup during this time to challenge myself and expand my skills in a new industry. The most important thing I learned is that difficult situations can teach you what you really want to do. This experience crystallized my conviction that software design and engineering are what I enjoy the most.

Boom’s Overture supersonic jet

Finding conviction

Mixpanel — 2021

The conviction that software design and engineering should be my focus led me to Mixpanel. While the path to get here has been winding, I’m incredibly fortunate to say that I’m doing what I love and still growing and learning alongside some of the most passionate and talented people I know.

Building community

IXD2 — 2023

The opportunity to organize UX events for AIGA Detroit and help build a community around the discipline I love has been an honor. This effort has culminated in the IXD2, an annual celebration that brings together individuals interested in digital craft, culture, and community. I’m excited to continue this initiative and grow every year.

IXD2 is the the 1st annual Detroit interaction day focused on digital craft, culture & community.

Memphis College of Art (MCA) was a private art college in founded in 1936 in Memphis, Tennessee. It offered Bachelor of Fine Arts, Master of Fine Arts, Master of Arts in Art Education and Master of Arts in Teaching degrees. However, it faced significant financial challenges and closed in the spring of 2020. ↩︎
net (magazine) is unfortunately no longer in publication, with it’s final issue being released in June 2020. ↩︎
An Event Apart was a web design conference focused on UX and front-end development renowned for providing education, inspiration, and practical takeaways. The conference ran for 17 years before concluding its events late 2022. It played a significant role in the evolution of front-end development, particularly during a time when the field was rapidly changing. The conference was organized by notable figures in the web design community, including Jeffrey Zeldman and Eric Meyer, and was highly regarded for its impact on attendees’ professional lives and careers. ↩︎
Vectorform has since been acquired by NTT Data and is now know as Launch by NTT Data. ↩︎

Familiar vs Novel

Wed, 29 May 2024 00:00:00 +0000

Familiarity enables the transfer of experience between similar products or services, allowing us to be productive without first learning how a system works. When we encounter familiar interface patterns and conventions, we intuitively understand them based on previous experience. This rule of thumb is the basis of Jakob’s Law and helps guide design decisions.

This article was originally published on Laws of UX.

However, a common question is whether there is an appropriate time to deviate from this principle and design for novelty instead. Like everything in life, there is a time and place to follow the rules and a time to break them. Design is no different. There are times when it is entirely acceptable and perhaps even advantageous to design for novelty.

The Benefits of Familiarity

Familiarity with digital products and services comes with major advantages. This is logical because the last thing you want is for your users or customers to have to learn something new, risking confusion and frustration simply because they couldn’t accomplish their intended tasks. However, a familiar interface feels more intuitive due to the mental model formed from past experiences.

Let’s take an e-commerce website as an example. Most e-commerce websites follow very similar patterns and conventions, allowing customers to focus on finding and purchasing the items they’re interested in. The friction that results from an unfamiliar interface is removed because it feels and functions similarly, if not identically, to other e-commerce websites they’ve visited in the past.

E-commerce websites follow very similar patterns and conventions.

In other words, we transfer knowledge from past experiences when facing something new that appears similar. If that something new is your product or service and it matches a pre-existing mental model that the user has already developed, the complexity of the interface becomes less of an obstacle. The interface effectively recedes into the background. The net result is an increased likelihood that they’ll be able to complete their intended tasks without friction, resulting is more sales, more signups, or more conversion.

When to Break from Familiarity

There’s a time and place to follow the rules, and a time to break them. Let’s explore when it’s acceptable and perhaps even advantageous to design for novelty instead. The first use case is when differentiation from competition is the ultimate goal. Separating a product or service from the competitors through branding, features, and unique interactions are all ways to set it apart.

Arc enables you to find your perfect setup with split view, themes, and more.

Web browsers have largely shared the same layout, features, and constraints. Arc is challenging the status quo by providing a fresh take on what a browser is and how it works. The browser is differentiated from others because it moves away from the traditional layout, opting for sidebar navigation instead. Additionally, it offers a high level of flexibility and personalization that enables users to tailor their browsing experience.

Utilizing novelty can also be an effective strategy when the goal is to disrupt incumbents with innovative technology. This is commonly seen when a new development threatens an established product or service, and the technology you’re employing has the potential to alter the way people perceive or engage with it.

Perplexity homepage

Perplexity is an AI-chatbot-powered research and conversational search engine that uses natural language predictive text to answer queries. Traditional search has largely been dominated by Google, which provides link listings based on search queries. However, advancements in AI and large language models have sparked new ideas about how we search and find things online. Perplexity utilizes the advanced natural language processing capabilities of large language models to accurately understand the intent and context of user queries. It also condenses relevant information from multiple sources into a concise format, eliminating the need for users to sift through multiple links to find the information they seek.

A final use case for leaning towards novelty over familiarity could be when exploration or surprise is the desired outcome. This might involve leveraging novel interaction patterns that will stand out and make the experience more memorable. Non-conventional techniques such as scroll-based interactions are a way to create immersion and engage users through richer engagement with content.

The Sculpting Harmony website unfolds as users scroll or swipe.

Consider, for instance, Sculpting Harmony, a website that narrates the process of Frank Gehry and his team designing the Walt Disney Concert Hall. This interactive storytelling unfolds as users scroll or swipe, merging architectural exploration, intimate conversations with Frank Gehry, performances by the LA Phil, and rich interactivity into an exhibition. This showcase not only traces the development of the Walt Disney Concert Hall, but also encourages visitors to explore. The interaction model that governs how visitors will use this website supports the goal exploration and creative discovery, and therefore is entirely appropriate. A more conventional interaction model could have been used for the website but it would not have been as engaging or memorable.

User Testing

It’s crucial to bear in mind that, irrespective of the design approach you adopt, it should be firmly rooted in user research and testing. The decision to deviate from familiar design patterns demands a profound understanding of the target audience for whom the design is intended. You must understand their needs, preferences, and behaviors to ensure that the new design produces the desired outcomes.

Implementing unfamiliar design patterns or conventions is a bold move, and while this can potentially yield innovative solutions and unique user experiences, it could also present unfamiliar challenges. Therefore, if these unfamiliar patterns or conventions negatively impact the overall usability or user experience, then they should be thoroughly reconsidered. It’s essential that novelty does not come at the expense of overall usability.

Familiarity in design allows users to transfer their experience between similar products, making them more productive quickly. However, there are times when designing for novelty can be advantageous, such as when differentiation from competition is the goal or when exploration or surprise is the desired outcome. We can leverage elements such as unconventional layouts, interactions, and animations to make an experience feel novel and engage people in a way that makes the experience stand out. Regardless of the design methodology, it must be rooted in thorough user research and rigorous testing to ensure it meets the needs and preferences of the target audience.

Onboarding for Active Users

Tue, 14 May 2024 00:00:00 +0000

Traditional product tours can be a hindrance to active users. Instead, onboarding should be designed with active users in mind, making guidance accessible throughout the product experience.

This article was originally published on Laws of UX.

The Paradox of the Active User is the tendency for users to never read manuals but start using the software immediately. This observation was first defined by Mary Beth Rosson and John Carroll in 1987 as part of their larger work on interaction design, Interfacing Thought: Cognitive Aspects of Human-Computer Interaction.¹ Rosson and Carroll found that new users were not reading the manuals supplied with their computers and instead would just get started using them, even if it meant getting into errors and running into roadblocks.

Fast forward to today and the need for instructional manuals to operate computers is increasingly rare. Operating an internet-connected device has become second nature to many. However, this paradox can still be observed when people encounter a new product or service, and nowhere is this more apparent than during the onboarding process. Traditional product tours can be a hindrance to active users. Instead, onboarding should be designed with active users in mind, making guidance accessible throughout the product experience.

Onboarding Status Quo

Have you experienced an onboarding process that requires clicking through a series of information before you can ever start using the product or service? Odds are that you have and that you read very little or any of that information. Turns out, this is an incredibly common pattern known as a product tour. It’s an onboarding method that makes use of sequential overlays to highlight important elements and demonstrate how they work.

Product tours make use of sequential overlays to highlight important elements and demonstrate how they work

If you think about onboarding from the perspective of active users, not only are product tours a pain but they are preventing users from immediately interacting with your product or service. Users are often motivated to complete their immediate tasks which means they don’t want to spend time upfront reading about how your product or service works or learning about its key features before being able to use it. It’s an example of how technology can force users to conform rather than work with the grain of human behavior.

Onboarding for Active Users

How might we enable active users to immediately start using products and services without having to undergo a lengthy onboarding process while still providing guidance when it’s valuable? To adapt, designers can make guidance accessible throughout the product experience and design it to fit within the context of use. This approach will help active new users no matter what path they choose to take.

One tool we can leverage that makes guidance accessible throughout the product experience is via in-product elements like tooltips. Tooltips provide helpful information to users so they can learn through a process of discovery in a contextually relevant way. They are a lightweight, low-friction, and contextually relevant way to provide helpful information at just the right time and aid in the discoverability of new features or functionality.

Tooltip examples from Uber, Zomato and Spotify

An alternative strategy to seamlessly integrate new users into the system is what’s commonly referred to as progressive onboarding. This method is designed to gradually build the user’s familiarity with the platform, instilling confidence as they navigate through its features. Instead of overwhelming users with information all at once, this approach allows them to explore and learn about the system’s features at a comfortable speed. Users are given the liberty to discover and master additional functionalities as they progress, promoting a user-friendly experience that encourages exploration and learning.

Slack used a bot (Slackbot) to engage users and prompt them to learn about the messaging features in a risk-free way

A classic example of progressive onboarding was demonstrated by Slack. Instead of dropping users into a fully featured app after subjecting them to a few onboarding slides, Slack used a bot (Slackbot) to engage users and prompt them to learn about the messaging features in a risk-free way. To prevent new users from feeling overwhelmed, Slack hid all features except for the messaging input. Once users have learned how to message with Slackbot, they are progressively introduced to additional features. This is an effective way to onboard users because it mimics the way we learn: we build upon each previous step and add to what we already know. By revealing features at just the right time, we can enable our users to adapt to complex workflows and feature sets without feeling overwhelmed.

Another interesting approach to onboarding that aligns with how active users behave is a dedicated ‘get started’ template. This approach guides users to learn the core features of Notion while still allowing them to explore at their own pace.

Screenshot from Notion’s getting started template

Notion helps beginners learn the basics of their product by providing an easy-to-follow checklist to follow. This is an effective way to onboard users because it guides them in a risk-free environment that enables them to actively learn the features and functionalities of the app by using it. Additionally, a getting started template safeguards users from feeling overwhelmed with an endless amount possibilities. It’s an unobtrusive form of guidance that aligns with the behavior of active users which they can continue to revisit whenever they need.

The Paradox of the Active User describes the tendency for users to dive into software use without reading manuals. While we no longer have to worry about whether or not users are reading manuals to operate their computers, this tendency still exists in the form of onboarding. Traditional product tours can be a hindrance to active users. Instead, onboarding should be designed with active users in mind, making guidance accessible throughout the product experience.

We must remember to not build products and services for an idealized, rational user because people don’t always behave rationally in real life. Instead, we can account for this paradox by making guidance accessible throughout the product experience. We can design it to fit within the context of use so that it can help these active new users, no matter what path they choose to take.

Carroll, J.M. and Rosson, M.B. (1987). The paradox of the active user. In J.M. Carroll (Ed.), Interfacing Thought: Cognitive Aspects of Human-Computer Interaction (Cambridge, MA: MIT Press). ↩︎

Tesler’s Law

Mon, 12 Feb 2024 00:00:00 +0000

This article was originally published on Laws of UX and is an excerpt from the 2nd edition of Laws of UX: Using Psychology to Design Better Products & Services.

Tesler’s law, also known as the law of conservation of complexity, states that for any system there is a certain amount of complexity that cannot be reduced.

Takeaways

All processes have a core of complexity that cannot be designed away and therefore must be assumed by either the system or the user.
Ensure as much as possible of the burden is lifted from users by dealing with inherent complexity during design and development.
Take care not to simplify interfaces to the point of abstraction.

Overview

Who should bear the burden of complexity within an application or a process— the user, or the designers and developers? This is a fundamental question when considering the design of user interfaces and, more broadly, how humans interact with technology. A key objective for designers is to reduce complexity for the people who use the products and services we help to build, yet there is some inherent complexity in every process. Inevitably, we reach a point at which complexity cannot be reduced any further but can only be transferred from one place to another. At this point, it finds its way either into the user interface or into the processes and workflows of designers and developers.

Origins

The origins of Tesler’s law can be traced back to the mid-1980s, when Larry Tesler, a computer scientist at Xerox PARC, was helping to develop the language of interaction design—a set of principles, standards, and best practices for defining the structure and behavior of interactive systems that was key to the development of the desktop computer and desktop publishing. Tesler realized that interface consistency would benefit not only users but also developers because standards could be encapsulated in shared software libraries. It was later in his career, while working on the Mac app object-oriented framework at Apple, that Tesler created an intermediate “generic application” that enabled developers to build their own applications by modifying the generic application in an object-oriented way. Tesler defined the law of conservation of complexity as a way to sell the idea to Apple management and independent software vendors with the express purpose of establishing standards in mass-market software, but also, more importantly, to reduce complexity for customers. Tesler reasoned that “if a million users each waste a minute a day dealing with complexity that an engineer could have eliminated in a week by making the software a little more complex, you are penalizing the user to make the engineer’s job easier.”¹

Complexity Bias

In Chapter 6 we talked about cognitive bias, which serves as a mental shortcut that increases our efficiency by enabling us to make quick decisions without the need to thoroughly analyze a situation. In essence, cognitive bias helps us reserve mental energy so we can use it when it matters most, e.g., for complex problem solving, creative thinking, etc. We get an incredible amount of benefit from our cognitive bias, but there are some downsides as well: it often leads to errors in memory, judgment, and decision making.

Complexity bias is our tendency to favor complex and intricate solutions over straightforward ones, often because complexity is associated with intelligence, expertise, or depth of understanding.² Simply put, we often give undue credit to complex concepts or view something that is easy to understand as complex and difficult when we are confused or haven’t taken the time to truly understand it. This fallacy was clearly demonstrated in a 1989 paper by Hilary H. Farris and Russell Revlin that studied how people make hypotheses.³ In one experiment, participants were given three numbers and asked to figure out a rule. They could ask if other number sequences followed the same rule, but the real rule was simple: list three numbers that go up. The participants could have said anything like “1, 2, 3” or “3, 7, 99” and been correct. Most didn’t guess it was that simple, opting instead for more complicated rules.

Our inherent bias toward complexity can be especially problematic when we design because it can lead to more complex solutions. When we opt for more complex solutions, we sidestep the need to understand the underlying problem. The more complexity and assumptions a solution has, the greater the chance of failure. When we find ourselves favoring a more complex solution, it’s a good sign that we don’t have enough information or that we need to better understand the underlying problem. In these instances, we can avoid making unfounded assumptions and/or overly complex solutions by spending more time with the problem and deepening our understanding through observation and experience.

Examples

One common way to illustrate Tesler’s law is through the humble email. When you write an email, there are two required pieces of information: who the message is from (you), and to whom it should be sent. The email cannot be sent if either of these is missing, and therefore it’s a necessary complexity. To reduce this complexity, a modern email client will do two things: pre-populate the sender (it can do this because it is aware of your email address), and provide suggestions for the recipient as you begin to type their address, based on prior emails and/or your contacts (Figure 9-1). The complexity isn’t entirely gone; it’s just abstracted away to reduce the effort required of the user. In other words, the experience of writing an email is made a little simpler by moving the complexity of filling in the sender’s and, if possible, the recipient’s address to the email client, which was designed and developed by a team that assumed that burden of complexity when building it.

Figure 9-1. Modern email clients reduce complexity by populating the 'from' line and suggesting the 'to' line based on prior emails (source: Gmail, 2023)

Taking that a step further, Gmail now leverages artificial intelligence (AI) within your emails through a feature called Smart Compose (Figure 9-2). This intelligent feature can scan what you’ve typed and use that content to suggest words and phrases to finish your sentences, thus saving you additional typing and time. It should be noted that Smart Compose is not the first time-saving feature introduced to Gmail by way of AI—there’s also Smart Reply, which scans an email for context and suggests several relevant quick-reply options.

Figure 9-2. Example of Gmail’s Smart Compose feature (source: Gmail, 2023)

Another place that Tesler’s law can commonly be observed is in the ubiquitous checkout process found on online shopping sites. Purchasing items online requires customers to provide lots of repetitive information, including billing and shipping details. To simplify this process for customers, it is common to see online stores enable users to have their shipping address inherit the information from their billing address (Figure 9-3). This option simplifies the checkout process for customers in many cases because it prevents them from having to enter duplicate information for shipping. The resulting experience for customers has been effectively simplified, while the complexity required to enable the feature has shifted to the designers and developers responsible for implementing it up front. Simplifying the checkout process even further are services such as Apple Pay (Figure 9-4), which makes paying for items both online and in person even easier for customers. Once they’ve set up an account, people using Apple Pay or similar payment services can purchase items simply by selecting the option during checkout and verifying the details of their purchase—no need to enter any additional information. The customer experience thus becomes significantly less complex, with the complexity again shifted to the designers and developers responsible for the service.

Figure 9-3. The ability to inherit a shipping address from billing details within an ecommerce checkout simplifies the process and removes the need to type redundant information

Figure 9-4. Apple Pay makes the checkout process as easy as selecting the payment option and verifying your purchase (source: Apple, 2023)

Retail is an area in which you can find many innovative ways to abstract complexity away from users. Take, for example, Amazon’s Go stores (Figure 9-5), which provide a checkout-free shopping experience. First appearing as an experiment in downtown Seattle, they are now popping up in major metropolitan areas all over the United States. With the Amazon Go app installed on their smartphone, a customer can simply check in with the app when they enter the store, grab what they need, and walk out, without ever needing to wait in line, scan their items, or even pay in the store. A little later, the customer receives a receipt, and their Amazon account is charged.

Figure 9-5. The first Amazon Go store in Seattle (source: Wikipedia, 2019; photographer, Brianc333a)

The dizzying array of technology involved in a checkout-free shopping experience like that found in Amazon Go stores is nothing short of astounding. Advanced technology like machine learning, computer vision, and AI must be deeply integrated to allow for people to simply walk into the store, grab the items they wish to purchase, and then walk out. While the friction of shopping is drastically reduced for customers, the complexity that comes along with it must be absorbed by the designers and developers responsible for ensuring it all works.

Advancements in artificial intelligence (AI) are introducing a whole new interaction paradigm in computing history in which users can tell the computer what outcome they want via natural language. This intent-based paradigm sits in stark contrast to the command-based paradigm we’ve lived with for the last couple of decades, which requires commands via user actions within a graphical user interface (GUI), resulting in feedback from the system. With intent-based interaction, the complexity of the system is abstracted away from the user, enabling them to simply describe the outcome they’d like to see. Take, for example, Spark, from product analytics company Mixpanel, which enables users to conduct in-depth analyses of data by simply asking questions in natural language (Figure 9-6).

Figure 9-6. Mixpanel’s natural language Spark feature (source: Mixpanel, 2023)

Intent-based interaction via natural language lowers the barrier of knowledge required to interact with software, which is particularly effective with complex products with sophisticated feature sets. This interaction paradigm democratizes access to software and empowers users who know what they want to do but don’t know how to do it to simply describe the outcome they’d like. The barrier for entry required of users to reach “power user” status fades away while giving them access to the same powerful features.

Paradox of the Active User

When it comes to designing software, there’s a very important consideration to remember: users never read software manuals but instead start using the software immediately. This happens because users are often motivated to complete their immediate tasks, and therefore they don’t want to spend time up front reading documentation. It is, of course, a paradox, because users will save time in the long term if they first take time to learn and optimize around the system.

This paradox was first introduced by Mary Beth Rosson and John Carroll in 1987 to explain a common observation in several user studies done at the IBM User Interface Institute.⁴ They found that new users were not reading the manuals supplied with computers and instead would just get started using them, even if it meant getting into errors and running into roadblocks.

The lesson here is that we must remember to not build products and services for an idealized, rational user, because people don’t always behave rationally in real life. Instead, we can account for this paradox by making guidance accessible throughout the product experience. We can design it to fit within the context of use so that it can help these active new users, no matter what path they choose to take (e.g., tooltips with helpful information).

Managing Complexity with Progressive Disclosure

Progressive disclosure is an interaction design technique that displays only important actions or content by default, while making additional features or content easily accessible. The result is a more streamlined interface that helps to keep the user’s attention focused by reducing clutter, confusion, and cognitive load. Anytime we use a dropdown, accordion, or toggle that reveals content that is hidden by default, we are utilizing progressive disclosure. This strategy is incredibly useful for simplifying designs because it enables us to defer less important actions, advanced features, or additional content to a secondary screen (like a dropdown, accordion, or content toggle).

A great example of progressive disclosure can be found on Stripe’s website (Figure 9-7): when you hover the mouse over any item in the primary navigation, a menu will appear that reveals the various links in that category. Stripe has created a simple interface in which users can quickly scan and find relevant information without needing to dig through a mountain of content in the process.

Figure 9-7. Progressive disclosure menu on Stripe.com (source: Stripe, 2023)

Conclusion

Tesler’s law is important for designers to be aware of because it relates to a fundamental challenge we face throughout our work: how we manage complexity. We must first acknowledge that with any process, there will be a necessary amount of complexity that cannot be removed, no matter how simplified the process becomes as a result of the design process. Everything from a humble email to a highly sophisticated checkout process will have inherent complexity that must be managed. As designers, we have a responsibility to remove inherent complexity from our interfaces, or else we ship that complexity to our users. This can result in confusion, frustration, and a bad user experience. Where possible, designers and developers should handle complexity.

A designer’s guide to using psychology to design better digital products and services.

Learn More

Dan Saffer, Designing for Interaction: Creating Smart Applications and Clever Devices (Berkeley, CA: Peachpit Press, 2006), 56. ↩︎
Shane Parrish, “Complexity Bias: Why We Prefer Complicated to Simple,” Farnam Street, January 8, 2018, https://oreil.ly/i9di1. ↩︎
Hilary H. Farris and Russell Revlin, “Sensible Reasoning in Two Tasks: Rule Discovery and Hypothesis Evaluation,” Memory & Cognition 17, no. 2 (1989): 221–32, https://doi.org/10.3758/BF03197071. ↩︎
John M. Carroll and Mary Beth Rosson, “Paradox of the Active User,” in Interfacing Thought: Cognitive Aspects of Human–Computer Interaction, ed. John M. Carroll (Cambridge, MA: MIT Press, 1987). ↩︎

Laws of UX Book, 2nd Edition

Mon, 05 Feb 2024 00:00:00 +0000

A new edition that includes an even deeper connection to the underlying psychological concepts that govern the principles explored in the book, along with accompanying UX methods and techniques. Examples have been updated to ensure the deconstructed apps and experiences remain familiar and relevant.

The 2nd edition of Laws of UX is now the #1 new release in user experience & website usability on Amazon.

An understanding of psychology-specifically the psychology behind how users behave and interact with digital interfaces-is perhaps the single most valuable non-design skill a designer can have. The most elegant design can fail if it forces users to conform to the design instead of working within the “blueprint” of how humans perceive and process the world around them. This practical guide explains how you can apply key principles of psychology to build products and experiences that are more human-centered and intuitive. It deconstructs familiar apps and experiences to provide clear examples of how UX designers can build interfaces that adapt to how users perceive and process digital interfaces.

What’s new

The craft of design has a dynamic nature that keeps evolving along with technology. With every new technological advancement, new constraints and possibilities are introduced. Since the first edition of this book, LLMs (Large Language Models) have undergone significant advancements, AI-powered image generation tools have emerged, spatial computing has entered the mainstream, and smartphones have become even more powerful. However, the principles and concepts covered in this book remain timeless, and they provide a solid foundation for every designer, regardless of their level of expertise. To enhance the reader’s experience, the second edition includes additional information linking these principles and concepts to psychology concepts, techniques, and key considerations. This edition also features updated examples throughout, making it a practical guide for designers who want to stay up-to-date with the latest trends and best practices in the field of design.

Paradox of Choice
Complexity Bias
Flow

The Human Factor
Accessibility
Paradox of the Active User
Personalization

Contextual Inquiry
User Interviews
Eye-tracking

What you’ll learn

How aesthetically pleasing design creates positive responses
The principles of psychology most useful for designers
How these psychology principles relate to UX heuristics
Predictive models including Fitts’s law, Jakob’s law, and Hick’s law
Ethical implications of using psychology in design
A practical framework for applying principles of psychology in your design process

Gallery

2nd Edition Reviews

The Laws of UX serves as an excellent resource for both newcomers and professionals, encouraging them to delve into the deeper why behind design choices instead of merely imitating existing patterns.

Chris Desjardins, CEO, Tungsten

This is the book I didn’t know I needed at the start of my career and the one I insist on for my students and staff.

Andrés Currey Zapata, D.Sc.

Jon has broken down common psychology principles in a way that makes it easier to apply in everyday designs across all industries.

James Rampton, Lecturer, University of Michigan

Review the book online with this 30-day free membership to the O’Reilly Learning Platform.

Acesss now

Where you can find it

Amazon

Paperback, Kindle
Apple Books

EPUB
Target

Paperback
O’Reilly Learning

eBook
Bookshop

Paperback
Alibris

Paperback
AbeBooks

Paperback

Translations

Portuguese

Novatec
Bulgarian

Asenevtsi Publishing
Korean

Onlybook.co
German

dpunkt

Interviews

A discussion with Andrés Zapata, D.Sc. that dives into the details around the second edition of my book.

Read Now

The Cost of Personalization

Tue, 23 Jan 2024 00:00:00 +0000

This article was originally published on Humane by Design.

Choice is seen as a tax on people’s time and attention. We make upward of 35,000 decisions each day, requiring mental energy that often leaves us feeling drained.¹ AI-powered personalization promises a solution to decision fatigue that’s custom tailored to our preferences. However, personalization comes with trade-offs: it’s also used to shape, influence and guide our everyday choices and actions. When algorithms make autonomous decisions on our behalf, the visible options we have are hidden from us and we lose personal agency.

The Rise of Personalization

There was a time when companies had limited access to the personal data of potential customers. Even with the advent of the internet, there was still some separation between customers and companies due to limited access to personal computers. However, this changed once smartphones and constant online connectivity allowed for the collection of vast amounts of data through our online activities. The resulting influx of data enabled companies to target ads and drive their business metrics. For instance, if you search for the best running shoes or visit an online shoe store, you may start seeing shoe ads in the sidebar of every website you visit thereafter.

It wasn’t long before the results you’d see when using a search engine like Google was also determined by your demographics, location, interests, and search history. The intention was to serve up the best possible results and content that satisfies searchers’ needs by using personalized information about their online presence. For a time, Google search results were identifiable and visually distinct. This distinction has since eroded and paid results are now harder to distinguish. Regardless, it requires users to read through and spend mental energy to make a choice about which link aligns with their interests.

Google takes into account additional data the search engine collects about a user during the time of the search

New generative AI capabilities promise to take the work out of searching by summarizing an answer to questions via an AI-powered snapshot of key information to consider, with links to dig deeper. Microsoft now also embeds generative AI via OpenAI’s ChatGPT-4 into it’s search engine, Bing. Up-and-coming challengers promise an ”AI-powered Swiss Army Knife for information discovery and curiosity” that eliminates the burden of choice almost entirely. The underlying premise in these evolutions of search is that people don’t want more choices, they want more confidence in the choices presented.

Perplexity, an AI-powered Swiss Army Knife for information discovery and curiosity.

The reach of personalization within our digital lives now extends far beyond simple search results or ads. It also comes in the form of content tailored to our specific interests, and no platforms do this more effectively than social media. Social platforms employ machine learning algorithms to personalize users’ experiences by providing predictive recommendations. They collect data and use the results to enhance their algorithms, creating a feedback loop of random reinforcement. Time spent interacting with content within the platform increases algorithmic quality, resulting in more time spent on the platform, more data collected, and more ads viewed.

TikTok’s personalized content recommendations powered by machine learning algorithms.

Social media platforms aren’t the only ones making use of algorithms to personalize content for their users. According to Nielsen’s June 2023 Streaming Content Consumer Survey, customers spend an average of 10.5 minutes searching for something to watch. To make things worse, 20% say they don’t know what to watch before they start looking and then decide to do something else instead when they can’t find something to watch. To counteract the rise of overwhelming choice, streaming services have started using personalization to recommend content that adapts to each user’s interests and can help expand their interests over time. Their algorithms are fine-tuned enough to individual viewer interests that they can find a percentage match for recommendations based on what you’ve watched in the past, estimating the likelihood that you’ll enjoy a particular film or series. It’s working too — Netflix logged over 92 billion hours watched in just the first half of 2023.

Netflix recommends content that adapts to each user’s interests and can help expand their interests over time

Personalization is now considered an essential business strategy that’s made it’s way into almost every app and service we use. We have even come to expect personalized interactions and get frustrated when this doesn’t happen. We’re willing to sacrifice for the convenience, but at what cost?

The Cost of Personalization

The convenience that personalization promises also comes with trade-offs at the expense of users. The “personalization paradox” refers to the clash between personalized experiences that save us time and concern about the personal data they require. People often want the convenience of personalization without sacrificing privacy, but striking the right balance can be challenging for companies. The vast amounts of personal data that is required for personalization has historically been governed with inconsistent regulation around what can be collected and how it can be used. Tension between the convenience of personalized experiences in contrast to concern for privacy and data security has led to ongoing debates about privacy, user consent, ethical data usage, and the need for regulations in the digital space. Thankfully, personal data that was once freely harvested as a resource and considered company property is now being treated as an asset owned by individuals and entrusted to companies. Consumer mistrust, government action and market competition have contributed to driving change around personal data all around the world.²

But privacy isn’t the only trade-off we make for the convenience of personalization. Platforms are now utilizing their interfaces to capture data from user interaction in order to personalize content recommendations engineered to keep users on the platform longer. TikTok’s meteoric success has been largely attributed to it’s ability to tap into the reward system of the brain through an endless stream of short videos selected specifically for each user with the net effect of keeping them in a trance-like state on the platform.

Far from enhancing our ability to make the best decisions for ourselves, potent and addictive software can erode our free will by trapping us in loops of instant gratification. In the worst cases, it can feel like companies use our digital profiles as something akin to voodoo dolls, enticing us to buy, click, like, or consume content without ever knowing that they are pulling on our behavioral levers to influence us.

Eva McCarthy, The Personalization Paradox: Balancing Convenience and Privacy

Unfortunately, this degree of personalization can lure users deep into an addictive rabbit hole of increasingly extreme content and expose them to information and opinions that conform to and reinforce their pre-existing beliefs and biases (commonly referred to as a filter bubble).³ Research also suggests that prolonged use of TikTok can lead to a significant decrease in attention span, increased anxiety, depression and stress,⁴ and difficulty participating in activities that don’t offer instant gratification — a phenomenon known as ‘TikTok brain’. To make matters even worse, these side effects can surface after just 20 minutes of use and exacerbate existing mental health concerns by romanticizing, normalizing or encouraging suicide.⁵

However, the most alarming trade-off we make for personalization is the erosion of free will and personal autonomy that results from loops of instant gratification. Platforms compete in capturing our attention and exploiting our personal data for their own ends by luring us into infinite feeds optimized for maximum ‘stickiness’. The more time we spend interacting with content on the platform, the higher the algorithmic quality becomes, resulting in content that is more targeted at individual interests. It’s a feedback loop of random reinforcement designed to keep us captive, not provide value or meaningful connection with others.

These platforms have the potential to shape our behavior with subtle and subliminal cues, rewards, and punishments that nudge us toward their most profitable outcomes. As Shoshana Zuboff writes in The Age of Surveillance Capitalism, “Today, surveillance capitalism offers a new template for our future: the machine hive in which our freedom is forfeit to perfect knowledge administered for others’ profit”. Zuboff cautions that this kind of surveillance weakens democracy because, without freedom to act and think independently, we lack the ability to make moral judgments and think critically, which are essential for a democratic society. Democracy is then furthered weakened by the an unprecedented gathering of information and the influence that comes with it.

Empowerment > Personalization

Technology should augment human intellect and enhance our abilities. When platforms prioritize their business goals and keep people captive, our agency is undermined by the convenience of a device within arms reach at any given moment that promises personalized content powered by algorithms people don’t control. Instead, we must ask ourselves: how might we design technology in a way that empowers people? Let’s explore a few alternative possibilities that counteract the trade-offs we make for personalization.

The next phase in user experience will be to change our founding metaphors so that we can express our higher needs, not just our immediate preferences.

Cliff Kuang, User Friendly: How the Hidden Rules of Design Are Changing the Way We Live, Work, and Play

An early step towards empowerment has been simply bringing awareness to people around their digital activities. Device manufacturers have opted to promote usage awareness to encourage healthier digital habits with feature such as Apple’s Screen Time and Google’s Digital Wellbeing initiative. These features can help people better understand their tech use and provides tools to pause distracting apps, set daily limits, customize notifications, etc. But is usage awareness enough?

Apple’s Screen Time enables access real-time reports showing how much time you spend on your device and provides tools to set limits for what you want to manage

We can also provide the necessary tools and authority to effectively oversee and regulate the algorithms that significantly influence people’s daily experiences. This allows people to actively participate in shaping and customizing their own digital experiences, ensuring a more personalized and tailored online environment that aligns with their preferences, values and goals. People must be empowered to co-create with the algorithms, requiring a balance to be struck between trust and efficiency. We can build a stronger relationship between humans and machines by placing humans in the AI-decision loop and empowering them with the ability to steer the algorithms that shape their experiences. For example, what if platforms enabled users to fine-tune the algorithm that feeds their experience?

Algorithm fine-tuning proof-of-concept

Lastly, we can change our relationship with devices altogether. What if technology pushed us more towards low interface and utility over consumption? If we could reduce screen time, we could reduce the likelihood of being seduced by the lure of infinite feeds. One exciting outcome of the increasing capability of AI is the potential to significantly reduce screen time and reliance on apps in many cases. We’re beginning to see personalized operating systems that provide a natural language interface and an emphasis on privacy and data control. These systems are early and have a way to go before they can replace smartphones, but it’s a promising glimpse at a future where we might not have to rely on screens.

Rabbit R1, a personalized operating system through a natural language interface

Computers have become integral to every aspect of our lives. They have become small enough to wear or carry in our pockets and adorn every possible surface imaginable. They ensure we have content tailored to our interests within reach at any given moment thanks to machine learning algorithms that monitor and adapt to every interaction. However, they have also ushered in an era where time and attention are increasingly scarce resources. In addition to enhancing our abilities, technology has become a vehicle for extracting our attention, monetizing our personal information, and exploiting our psychological vulnerabilities. While personalization offers convenience and tailored experiences, it is crucial to consider the tradeoffs. Privacy isn’t the only trade-off we make for personalization: it’s also used to shape, influence and guide our everyday choices and actions. We must design technology for empowerment and create technology that respects privacy, fosters well-being, and aligns with users’ higher needs and values.

Marples, M. (2022). Decision fatigue drains you of your energy to make thoughtful choices. Here’s how to get it back. CNN Health. https://www.cnn.com/2022/04/21/health/decision-fatigue-solutions-wellness/ ↩︎
Rahnama, H., & Pentland, A. (2022).The New Rules of Data Privacy. Harvard Business Review. https://hbr.org/2022/02/the-new-rules-of-data-privacy ↩︎
Figà Talamanca, G., & Arfini, S. (2022). Through the Newsfeed Glass: Rethinking Filter Bubbles and Echo Chambers. Philosophy & technology, 35(1), 20. https://doi.org/10.1007/s13347-021-00494-z ↩︎
Sha, P., & Dong, X. (2021). Research on Adolescents Regarding the Indirect Effect of Depression, Anxiety, and Stress between TikTok Use Disorder and Memory Loss. International journal of environmental research and public health, 18(16), 8820. https://doi.org/10.3390/ijerph18168820 ↩︎
(2023). Driven Into the Darkness: How TikTok’s ‘For You’ Feed Encourages Self-Harm and Suicidal Ideation. Amnesty International. https://www.amnesty.org/en/documents/POL40/7350/2023/en/ ↩︎

Good Design is Intentional

Mon, 09 Jan 2023 00:00:00 +0000

This article was originally published on Humane by Design.

It’s time we expand what it means to create more meaningful relationships between people and technology by considering the intentionality of the products we build.

There’s a legend about the oak beams that span the dining hall ceiling of New College in Oxford, England. As the story goes, it was discovered in 1859 that the expansive beams would need replacing due to a beetle infestation. The college agonized over where they’d find the oak large enough to replace the beams until a junior fellow suggested that there might be some worthy oaks on the college property scattered across the country.

The dining call of New College

The college Forrester that maintained the land was summoned and upon inquiry shared that a grove of oaks had been planted to replace the dining hall beams in 1379, the year the college was founded. The plan had been passed down for 500 years between the college foresters, which anticipated the eventual beetle infestation and forbade cutting the oaks down until needed for this very purpose. The Forrester replied by saying, “Well sirs, we was wonderin’ when you’d be askin’”.

Regardless of how factual the legend of the New College oak beams is¹, it conveys something deeper, something intentional. The eventual degradation of the oak beams towering above the dining hall was anticipated at its inception. The land was cleared and an oak grove was planted for the specific purpose of replacing these beams one day in the distant future. Specific people were designated to maintain the grove, who passed down instructions to protect it year after year until the day finally came to cut them down so the oak grove could finally fulfill its purpose.

Think about this story in the context of the digital products that are commonplace today. We have apps to cater to our needs in every variety: ordering a ride, ordering a meal, or streaming an entire season of our favorite show is a few taps away. Goods of any kind can be at our doorstep within 24 hours. We don’t even need to go to the grocery anymore – there’s a service and app for that as well. These products provide convenience at a cost we are willing to accept, but what about their intentionality? Intention requires the foresight to think beyond short-term gain to anticipate long-term consequences. Are any of the products that we use today to make our lives more convenient planting their metaphorical oak grove in anticipation for when things fail or cause inadvertent harm?

Unintentional design

My questioning of the intentionality behind the products we use and take for granted began during rush-hour traffic on a hot summer afternoon as I observed hordes of traffic on my quiet neighborhood street. I later learned that the reason for this was because of Waze, the popular way-finding app well known for its real-time driving directions based on live traffic updates. To save its users a few minutes of commute time, the app was routing them through my neighborhood one after the other. In the process, this converted my street into a congested racetrack which was no longer safe for the children who played there and the pedestrians who walked them. The worst part: there was nothing we could do to stop it.

I remember thinking, “how could Waze be so blatantly dismissive and negligent of my neighborhood?”. It turns out I’m not the only one that feels this way: this app specifically has been cited as the cause for neighborhood streets to become dangerous and congested cut-throughs so users can save some time while ignoring the societal cost it inflicts. Residents are left powerless to stop the algorithm that’s routing impatient commuters through their streets². This experience left me wondering how products can intentionally impact people and how little attention we pay to those people during the design process.

A traffic snarl on a narrow L.A. street | Photo by James Marshall

Unfortunately, there are many more examples that demonstrate how the products we use can be incredibly negligent, even when they begin with good intentions. Take for example Facebook’s like button, which began as a friendly way to express positivity and soon ushered in a new feedback model that’s now mimicked on every social media platform in some variation. What no one anticipated was how this simple mechanic would mutate into a built-in filter bubble that amplifies the universal tendency towards tribalism³ and exploits our desire for belonging and social affirmation through tiny dopamine boosts.

The famous Facebook thumbs-up sign once visible at their Menlo Park HQ

Failure to anticipate unintended consequences isn’t isolated to social media. Airbnb has contributed to housing shortages and rent increases by creating a reduced supply as properties shift from serving residents to serving Airbnb users, which hurts residents by raising housing costs⁴. Landlords realize they can fetch more on the vacation rental market, resulting in them converting their properties from long-term to short-term rentals. This has shrunk the rental market and therefore pushed prices higher for those living in those areas.

Then there are the electric scooter products like Lyft, Bird, and Lime. These products offer an affordable alternative to ride-sharing or car traffic to make short trips in congested cities. But this convenience it provides for its customers has also led to vandalism, cluttering, and reckless riding⁵. The result has been eyesores for cities, obstacles for pedestrians, and a wide range of legislation created on an ad hoc basis.

Failure to anticipate the long-term consequences of design decisions in favor of short-term gain often leads to negligent and sometimes harmful outcomes.

There can also be very real privacy and safety concerns when long-term consequences aren’t adequately considered. Take for example the growing area of personal surveillance products which enable the ability to track, monitor, and quantify activity via video and sound recording, often coupled with facial recognition⁶. Consumers that use these products commonly believe they have nothing to fear or hide and so the value they receive is worth the privacy tradeoff. In reality, these products can and have been leveraged against them and others by their employers, the government, their neighbors, stalkers, and domestic abusers.

Apple AirTags

Even companies that typically emphasize privacy and security can fall into the trap of not thinking through the consequences of the products they’ve designed. Apple’s AirTags are a perfect solution for tracking items of value but their incredible accuracy also makes them an effective stalking tool⁷. While the company has announced new anti-stalking features to help address these concerns, the item tracker market is filled with competitors, most of which lack the anti-abuse safeguards that AirTags have.

Failure to anticipate the long-term consequences of design decisions in favor of short-term gain often leads to negligent and sometimes harmful outcomes. When there is no metaphorical oak grove that anticipates when things go awry, there’s no way to adapt or protect those being negatively affected.

Why intention matters

Scenarios, where everything is perfectly aligned for a feature or product to work exactly as intended, are the path of least resistance. The inconvenient complexities of what might go wrong are pushed to the side or ignored altogether. Our focus becomes the MVP (minimum viable product) while handling edge cases becomes secondary. However, these edge cases seldom get addressed, and more often than not, the MVP becomes the final version. Long-term consequences are ignored over short-term gain, and this is precisely when features and products are set up to negatively impact people.

Intentionality matters because when it’s ignored, the design becomes irrelevant.

This begs the question: if a product is negatively impacting people, is it a good product? It boils the problem down to the fundamental question of what ‘good’ design means. I’d argue that good design is that which is intentional and therefore considers long-term consequences over short-term gain. Unfortunately, the drive for speed and innovation more often leads to us optimizing for the ‘happy path’ while ignoring unintended outcomes. Long-term consequences are not entirely included in the common criteria we consider for good design. As a result of our narrow focus on short-term gain, we commonly don’t think to even consider the lasting impact of our design decisions.

When we reexamine the criteria for good design in the context of intentionality, it’s clear this is a missing piece to the dialog around what good design means. Intentionality matters because when it’s ignored, the design becomes irrelevant. We must expand our criteria for what good design is and acknowledge that good design is that which is intentional and therefore considers its long-term impact on both direct and indirect users.

Designing with intentionality

The teams of designers, product managers, and engineers behind the companies I mentioned earlier didn’t set out to create products that negatively affect people; instead, they failed to consider the long-term consequences of their products. Fortunately, there are ways that designers can identify the consequences of our decisions.

Second-order thinking

An effective method for identifying unintentional impact is through second-order thinking. We can take into account how our design will affect indirect users by considering the consequences that will inform our design decisions. Suppose first-order thinking focuses on solving the immediate problem without considering the consequences. In that case, second-order thinking enables us to think through problems in the second, third, or nth order. We activate second-order thinking by asking ourselves “and then what” in a series.

Using Waze as an example, let’s explore how second-order thinking could have helped identify the impact of their product on indirect users. We’ll use the ‘smart routing’ feature of the app as the focus. As you can see, the consequences of the intelligent routing feature for direct users are fairly straightforward. As a result of this feature, these users receive the fastest route, thus avoiding traffic and eventually getting to their destination faster. This scenario is what we’d consider a “happy path”.

Now let’s switch over to our indirect users. The added drivers in their neighborhood are, 1) anxious due to the traffic they seek to avoid, and 2) most likely followed by other drivers also using Waze. The result is speeding drivers and too many cars on the street for it to be safe for the children who live in those neighborhoods. While indirect users aren’t actively engaging with the product, they are still being affected.

Futures Wheel

A futures wheel is an exercise created by Jerome C Glenn⁸ that enables us to organize thinking and questioning about future development or trend. It’s a structured brainstorm that starts with a root term to evaluate and then events or consequences following directly from that development are positioned around it. Finally, the indirect consequences of the direct consequences are positioned around the first-level consequences. The purpose of this exercise is to understand the possible both direct and indirect impacts and to collect them in a structured format.

Pre-mortem

It’s pretty common to run an analysis of a project once the project is over, most often to identify the source of friction or failure that occurred during the project. These sessions, referred to as postmortems or retrospectives, are helpful for teams that wish to improve process and collaboration moving forward but do nothing to identify project risks or consequences at the beginning.

A premortem is the hypothetical opposite of a postmortem in which your team imagines that the project has already failed. It’s a method based on the concept of prospective hindsight: reflecting on a potential future event as if it had already happened. They enable us to visualize the risk or long-term consequences happening in advance and then work backwards to understand how they might be prevented. The final step is to revise an existing project plan with the potential future risks and potential future solutions to those risks.

It’s time we expand what it means to create more meaningful relationships between people and technology by considering the intentionality of the products we build. We can take into account how our design will affect them through methods such as second-order thinking, futures wheel, and post-mortems to identify the consequences to make better product decisions. I believe that in the process of expanding our criteria for what good design is and acknowledging that good design also considers those not directly using the products we build, we’ll create more meaningful relationships between people and technology overall.

Siddique, H. (2013). David Cameron’s tale of Oxford college’s trees is a myth, says an academic. The Guardian. https://www.theguardian.com/politics/blog/2013/oct/02/david-cameron-oxford-college-trees-myth ↩︎
Littman, J. (2019). Waze Hijacked L.A. in the Name of Convenience. Can Anyone Put the Genie Back in the Bottle? Los Angeles Magazine. https://www.lamag.com/citythinkblog/waze-los-angeles-neighborhoods/ ↩︎
Taub, Amanda, and Fisher, Max (2018). Where Countries Are Tinderboxes and Facebook Is a Match. The New York Times. https://www.nytimes.com/2018/04/21/world/asia/facebook-sri-lanka-riots.html ↩︎
Hempel, J. (2018). Airbnb Can’t Win New York—But It Can’t Quit Either. Wired. https://www.wired.com/story/airbnb-cant-win-new-yorkbut-it-cant-quit-either ↩︎
Gössling, S. (2020). E-scooters – cities should embrace them. The Conversation. https://theconversation.com/e-scooters-cities-should-embrace-them-131087 ↩︎
Gilliard, C. (2022). The Rise of ‘Luxury Surveillance’. The Atlantic. https://www.theatlantic.com/technology/archive/2022/10/amazon-tracking-devices-surveillance-state/671772/ ↩︎
Chen, Monica and Song, Victoria (2022). Airbags are dangerous — here’s how Apple could fix them. The Verge. https://www.theverge.com/2022/3/1/22947917/airtags-privacy-security-stalking-solutions ↩︎
Glenn, Jerome. (2021). THE FUTURES WHEEL. Research Gate. https://www.researchgate.net/publication/349335014_THE_FUTURES_WHEEL ↩︎

Translating Laws of UX

Thu, 07 Jul 2022 00:00:00 +0000

I’ve been working on an Arabic version of Laws of UX in partnership with my friends at The Valve Studio. It’s been an opportunity for me to learn more about internationalization and paves the way for future translations of the website. In this article, I document the design decisions that were made and the technical details that I encountered in the process.

Overview

Let’s begin by outlining the underlying technology in use in the Laws of UX. The website is powered by Hugo and it takes advantage of the built-in asset pipeline called Hugo Pipes. Hosting is handled with Netlify, which connects to a Github repo and deploys when updates are pushed.

I’ve experimented with a few static site generators but Hugo has remained my go-to for a few reasons. Firstly, it’s blazing fast. It clocks in at around <1ms per page, so the average site builds in less than a second. This means no more waiting for your pages to build each time you save. Secondly, it comes with an asset pipeline baked right in. When it comes to simplicity, there’s something nice about not needing to configure a build process for each project that leans heavily on a build tool like Grunt or Gulp. It also comes with the ability to spin up a local server and live-reload that server when changes are detected. This is typically something I’d have to set up with a task runner, but in Hugo, it comes baked in.

If you’re interested in learning more about how I use Hugo’s built-in asset pipeline to do things like transform templates to HTML, process PostCSS to CSS, or generate responsive images, check out this article where I detail my Hugo workflow.

Lastly, Hugo natively supports the creation of websites with multiple languages side-by-side. It is this feature that we’ll talk about at length in this article.

Config

The first step is configuring the website to support multiple languages. Hugo enables you to define each language that you intend to support via the global config file (config.toml). The first thing you’ll need to do here is set the default language, followed by settings for each language. There are plenty of useful settings you can define but the most common are the language name, base URL, weight (how Hugo prioritizes languages), and the description that will show as the <meta name="description" content="..."> of the site. You can learn more about Hugo’s multilingual language configuration here.

# Default language
defaultContentLanguage = 'en'
# Mutli-lang Settings
[languages]
[languages.en]
languageName = "English"
baseURL = "/en/"
weight = 1
[languages.ar]
languageName = "Arabic"
baseURL = "/ar/"
languagedirection = 'rtl'
weight = 2
description = "قوانين تجربة المستخدم، هي عبارة عن مجموعة من أفضل الممارسات التي يمكن للمصممين أخذها بعين الاعتبار عند إنشاء واجهة مستخدم."

Directory Structure

Next up is deciding how you will structure your files to support multiple languages. There are two ways to manage your content translations via Multilingual Mode: translation by filename or translation by content directory. Both methods ensure each page is assigned a language and is linked to its counterpart translations. For the Arabic version of Laws of UX, I took the translation by filename approach so that translated versions of each page could live in the same folder side-by-side, making managing and updating individual files easy.

Laws of UX content directory with language-specific files

HTML attributes

The HTML attributes necessary for enabling translations are pretty minimal. I first set the lang property on the HTML element for the current language. Secondly, it’s necessary to indicate what writing mode of the website via the dir attribute. In the case of Arabic, the value of this attribute is rtl, which means ‘right to left’.

<html
lang="{{ .Language.Lang }}"
dir="{{ .Language.LanguageDirection | default `ltr` }}">

By default, the direction of text will be left-to-right (ltr) and dynamically insert the language direction (.LanguageDirection) if available based on the setting in the site’s configuration file.

Content

I had the fortune to work with the wonderful team at The Valve Studio to translate all text content from the website into Arabic. English text strings were documented side-by-side with their Arabic equivalent in Google Sheets and separated by page or general (e.g. navigation labels, copyright info, etc).

Translations

The next step was to implement the translated content. Content that is specific to a single page can easily be implemented via a language-specific variation of that page (e.g. index.ar.html and index.en.html). On build, Hugo will render any page that has a language abbreviation in a separate language-specific directory. This results in the Arabic version of the page residing at /ar/[name-of-page] while the English version is at /en/[name-of-page].

Translation document for Laws of UX

Global strings take advantage of the i18n (an abbreviation of Internationalization) configuration files. This enables specific strings to be represented as tags which are then transformed into their translated value if the language-specific configuration file exists. As long as the language file exists in the i18n directory (represented by the language abbreviation) with the proper ID, the tag gets replaced with the value of that ID when Hugo builds the page.

i18n translation configuration files

Fonts

Fonts play a critical role in the readability of any content and this is especially true for multilingual websites. I’ve always used IBM Plex as the primary font family for Laws of UX because it’s well crafted, it’s a great fit for the art direction of the website, and it features a diversity of styles and weights. Fortunately, this type of family also supports a multitude of other languages, including Arabic. This means that the specific glyphs needed to properly render Arabic text are baked right into the fonts, ensuring there are never any weird or missing characters when displaying Arabic text with a font meant for languages such as English.

To load the necessary fonts for each supported language, I first load both English and Arabic versions of fonts that I need using the standard @font-face declaration. Next, I store references to the appropriate fonts for each language in CSS variables that get used throughout the codebase. This ensures that only the necessary fonts are loaded, depending on which version of the website is being viewed.

:root:lang(en) {
--base-font-family: 'IBM Plex Sans', Arial, Sans-Serif;
--secondary-font-family: 'IBM Plex Mono', monospace;
}
:root:lang(ar) {
--base-font-family: 'IBM Plex Sans Arabic', Arial, Sans-Serif;
--secondary-font-family: 'IBM Plex Mono', monospace;
}
html {
font-family: var(--base-font-family);
}

Logical Properties

CSS logical properties were used to avoid writing duplicative CSS to make adjustments for elements when switching from a left-to-right to a right-to-left layout. Everywhere margin, padding or position properties were being used to provide spacing, separate elements from one another or position them got refactored to be direction-agnostic.

CSS logical properties being used for banner graphic margin/padding

Take for example the banner graphics for each page. These graphics originally were styled using margin and padding that was specific to ltr languages (margin-left, margin-right, padding-left, padding-right). Leveraging the power of logical properties enabled the website to adapt to whichever direction the text needed to flow simply by defining styles in a way that adapts to the selected language (margin-block, margin-inline, padding-block, padding-inline). This approach not only results in less CSS but paves the way for future translations with no CSS adjustments needed.

Language Selector

Users can manually change the language via a language selector, which is located in the header. The language selector is comprised of a toggle button and a list of available languages which link to the respective directory for the translated content.

Laws of UX language switcher

Structure

The first step is to construct the language selector structure, which consists of a <button> element to toggle an adjacent <ul> that contains a link to the homepage for each translation. These elements are wrapped in a <nav> element that provides some additional semantic information about what the component does.

<div class="lang-switcher" id="language">
<!-- Toggle -->
<button class="lang-switcher__toggle button button--toggle button--min" aria-expanded="false" aria-controls="lang-list" data-toggle>
<!-- Translation icon -->
<span class="button__icon button__icon--left">
{{ partial "components/icon" (dict "name" "language") }}
</span>
<!-- Label -->
<span class="lang-switcher__toggle-label" aria-label="Select language">{{ .Language.LanguageName }}</span>
<!-- Arrow -->
<span class="button__icon button__icon--right button__icon--default" aria-hidden="true">
{{ partial "components/icon" (dict "name" "arrow-drop-down" "size" "16") }}
</span>
<span class="button__icon button__icon--right button__icon--active" aria-hidden="true">
{{ partial "components/icon" (dict "name" "arrow-drop-up" "size" "16") }}
</span>
</button>
<!-- List -->
<ul class="lang-switcher__list" id="lang-list">
{{ range $.Site.Home.AllTranslations }}
<li class="lang-switcher__list-item" tabindex="-1" {{ if eq $.Language.LanguageName .Language.LanguageName }}aria-checked="true"{{ end }}>
<a href="{{ .Permalink }}" class="{{ if eq $.Language.LanguageName .Language.LanguageName }}active{{ end }}"
aria-label="{{ i18n .Language.LanguageName }}">
{{ .Language.LanguageName }}
</a>
</li>
{{ end }}
</ul>
</div>

There are some accessibility considerations here:

The toggle is a <button> component that includes ARIA attributes to provide accessibility information: whether the list is expanded (aria-expanded) and the content it controls (aria-controls).
The label for the toggle button is provided an aria-label to indicate what the list is.
The list is provided an id that associates it with the toggle button.
The list has hidden attribute to hide it by default.
An ARIA attribute is set on the currently active language to indicate to screen readers (aria-checked="true").
Insert translated strings for languages via i18n tags to ensure they read correctly for users.

Styling

Next up is to apply the appropriate styling to the language selector. The gist here is to use the <button> element to toggle the visibility of the language list, which gets displayed as a dropdown. The button I’m using to toggle the visibility of the language menu gets reusable styling that’s applied to other button components throughout the website (.button .button--toggle). This ensures more modularity, reduces code repetition, and increases maintainability.

We ensure the language list width is sized according to the longest language name via width: min-content. Additionally, the visibility of the language list is toggled via the class .is-active, which is applied to the list element via Javascript once the toggle button is clicked/tapped.

The following is the CSS required to make this work with unrelated styling omitted:

/**
 * Parent
 */
.lang-switcher {
position: relative;
transition: opacity var(--base-duration) var(--base-timing);
}
/**
 * Elements
 */
.no-js .lang-switcher__toggle {
display: none;
}
.lang-switcher__list {
position: absolute;
top: 0;
inset-inline-end: 0;
width: min-content;
list-style: none;
}
.js .lang-switcher__list {
display: none;
top: 100%;
}
/**
 * States
 */
.is-transitioning .lang-switcher {
opacity: 0;
}
.lang-switcher__list.is-active {
display: block;
}

Interaction

The last part of the language selector listening for click/tap events on the toggle element. Once this is detected, the aria-expanded attribute is updated on the toggle element and the corresponding language list is revealed or hidden via the hidden attribute. Additionally, an active class is applied to the nextElementSibling to the toggle button, which is the language list.

const activeClass = 'is-active';
const toggleContent = (e) => {
let expanded = e.target.getAttribute('aria-expanded') === 'true' || false;
e.target.setAttribute('aria-expanded', !expanded);
let content = e.target.nextElementSibling;
content.classList.toggle(activeClass);
}
document.addEventListener('click', function() {
if (e.target.matches('[data-toggle]')) {
toggleContent(e);
}
}, false);

Redirects

Hugo creates a separate directory for each language, which lives at the root of the files generated on build. I can define how I want the server to handle redirects within the netlify.toml file, which automatically gets moved to the root directory. Netlify will then use this config file to write redirects and ensure visitors get routed to the correct directory based on the language preference they’ve set in their browser. In the case there is no set preferred language, the server will default to English.

# Redirect users with Arabic language preference
[[redirects]]
from = "/*"
to = "/ar/:splat"
status = 301
force = false
conditions = {Language = ["ar"]}
# Redirect users with English language preference
[[redirects]]
from = "/*"
to = "/en/:splat"
status = 301
force = false
conditions = {Language = ["en"]}
# Redirect users with no language preference (default)
[[redirects]]
from = "/*"
to = "/en/:splat"
status = 301
force = false

Netlify’s redirect rules accept several options to customize how the paths are matched and redirected. In addition to language preference, you can redirect users based on their location (country), role, or cookie presence. You can read more about Netlify’s redirect options here.

Conclusion

Building the Arabic version of Laws of UX was quite a fun learning opportunity for me. I’m incredibly grateful to have the team at The Valve Studio collaborate with on this project and make the website available to even more people around the world! I’m looking forward to building upon the foundations established with this project to include even more translations in the future.

See Laws of UX Arabic

References

Demystifying Internationalization with Hugo (Hugo Conf) ↗

A walk through of the technical details behind the new Arabic edition of Laws of UX which explores Hugo’s Multilingual Mode, how to translate content based on i18n configuration, and using CSS logical properties to control layout.

Crafting Component Libraries: The Elements

Wed, 19 Jan 2022 00:00:00 +0000

Component libraries enable interfaces to be defined through individual building blocks that can be composed together to form a greater whole. The net result is an adaptable visual language that unlocks greater consistency, efficiency, and scalability. In this article, I’ll step through my process for crafting the foundational elements that make up a component library based on design fundamentals that can grow and evolve to fit the needs of any interface.

To demonstrate my process, we’ll go through the workflow I followed when creating a component library for the project Biased by Design. While this project is relatively small, the process I’ll cover can be followed to build component libraries for projects of any size. I’ve used Figma to create the component library that we’ll cover in this article and I’ll build upon some basic concepts. If you’re not already familiar with Figma, I recommend this playlist for a quick tour of the key concepts and features.

Screenshot of the homepage for [Biased by Design](https://biasedbydesign.com/)

Typography & Scale

Let’s begin by establishing the two backbone elements of any component library: typography and modular scale. Written language plays a foundational role in design — it’s what makes up the majority of the content we consume and is a vital mechanism for communication. For this reason, beginning with type makes a lot of sense when starting any component library. A modular scale is also a critical part of the library because it informs the size and spatial relationships between all elements in the library.

Typography

I begin every component library with type since the values derived from this foundation element directly affect many other items in the library. The typeface and sizing we choose for the body text is the lowest common denominator — it’s the base element that all others have in common by default. Therefore, it’s important to begin designing our library with this in mind.

The first step is to choose a suitable typeface (preferable one with several weights) and apply it to a block of text. The default font size on the web is 16px (1em), and that’s usually a great baseline to start with for body text. Next up is determining the default line-height, which will vary based on the typeface you’ve chosen for the body text. You can experiment with different line-heights until you find a value that provides enough breathing room between lines of text without losing the continuity between rows.

The remaining items in your typography scale will originate from this base size plus a scale multiplier, which we’ll define next.

Screenshot of base font component in Figma

Scale

Once I select the body text, it’s time to define a modular scale. The scale we use will be the logic behind the values throughout the library, so it’s helpful to establish this early on. We start by multiplying the value of the base font text by a scale ratio (1.333, 1.25, 1.5) to get the next value up and repeat this process to get additional values. For example: if my base font size is 16px and the scale ratio is 1.5, I multiply 16 × 1.5 to get 24px. I could then multiply 24 × 1.5 to get 36px and so on. You can also get smaller values that are lower than your base (16px) by dividing the base font-size by scale unit (e.g. 16px ÷ 1.5 = 10.667px). I continue this process until there are 8-10 sizes from the scale (including the base value).

No need to do all the math here manually — there’s a handy tool to quickly test and determine modular scale values called Modular Scale.

Screenshot of modular scale from www.modularscale.com

The scale you choose will determine how many units you have available, e.g. the higher the scale, the greater the difference between values. This will affect how much flexibility you have, so keep this in mind when determining what scale you use.

Once we’ve established a modular scale, let’s go back and define the remaining items in our typography scale. Don’t forget to also set a line-height value for these headings, which will vary depending on the typeface. I’ll go with 1.3x the font size (rounded to nearest whole pixel) for headings. Once I’ve established the remaining items in the type scale, it’s time to save these values for reuse later on by saving them as text styles.

Screenshot of the initial type scale in Figma.

Keep in mind that we’re just defining some foundational type styles. These styles will and should evolve as you begin working through your designs.

Grid System

Continuing with defining the foundational elements of the library, it’s time to establish a grid system. Grid systems are invaluable for not only establishing rhythm and alignment in a design, but they are great for ensuring there’s consistency. To define your grid system, create a new frame set to a large size, e.g. 1920×1080px. Next, use the grid settings to create a grid that’s 12 columns with a gutter value that comes from the modular scale (16, 24, etc).

Screenshot of the grid system in Figma.

A 12 column grid system provides lots of flexibility in how you lay components out later on because 12 is evenly divisible by 2, 3, 4, and 6, but you can experiment with other columns counts as well. The column count you choose will depend on the intricacy and scale of the design, with additional columns providing more layout control and flexibility. Once the grid system is established, it’s a good practice to save it as a grid style for reuse throughout the designs.

Colors

Colors are another foundational design element that will be defined early on. I like to start by defining the 1-4 primary colors, followed by the tints and shades of each color (if necessary). Tints and shades are useful for the more subtle color adjustments while staying consistent with the base color value. My favorite color format for this purpose is HSL because tints and shades can be easily defined by simply adjusting the ‘L’ or lightness value of the base color. Using this method, I will create the tint and shade variations of each primary color and include adjustment value differences in the naming of the color upon saving it in my design tools.

I tend to keep my color systems on the lean side, i.e. only define the colors (plus tints and/or shades) that I’ll need. This not only keeps things light and easy to manage but also helps to ensure more color consistency throughout the design.

Once the colors are defined, it’s time to save those as reusable styles so they can be referenced throughout the component library. The first step in saving the colors is to name each color appropriately (appending the difference in the HSL ‘lightness’ value to the end of the base color name). Once this is done, I follow the same steps for saving the colors as styles as I did with the text. Lastly, I double-check that the colors and their names are accurate via the Color Styles panel on the right-hand side of my Figma window.

Biased by Design colors

Color Contrast

It’s never too early to check your colors for proper color contrast, specifically in regards to text. Sufficient color contrast not only makes an interface more accessible but improves readability for all users. It’s good to begin checking color contrast as soon as you have your typography and colors defined, and there are plenty of great tools to help with this. The tool I like to use is called Stark, which provides a suite of integrated accessibility tools and can easily be installed as a Figma plugin. You can quickly check the color contrast of a text and background layer by first selecting them and then running the ‘Color Contrast’ test. The goal is to make sure the contrast between the text and background is greater than or equal to 4.5:1 for body text and 3:1 for large text.

Screenshot of the color contrast check from Stark

Iconography and Media

The last foundational design elements to define are iconography and images. Iconography usually plays a foundational role in any component library. Many if not most components will incorporate icons, and therefore establishing a flexible system for them is critical to the library. Related to iconography are media items like images and videos, which provide rich content and interaction for users but also play a foundational role in any design language. Therefore, we must define them with flexibility in mind.

Icons

I like to start by defining what icon sizes will be supported, defining them in t-shirt sizing (small, medium, large). Defining sizing according to t-shirt sizing limits the number of items by default, but this is usually exactly what you want: a defined set of values that work well in the context of the system overall, not every option imaginable with naming that has no relevance to the actual design (e.g. ‘size-1’, ‘size-2’, ‘size-3’, etc.).

Much like we did with the body text, it’s helpful to start with the lowest common denominator when defining icon sizing. Once again returning to our modular scale, select a unit from the scale that works well for icon size in combination with the body text. This will require some experimentation, so having a separate page that works like a sketch pad to experiment while you create your library is helpful. Once you’ve landed on a suitable base icon size, the next step is to create the additional sizes. This is a great use case for the variants feature in Figma, which allows you to group and organize similar components into a single container.

Biased by Design iconography components

Media

Media items like images and videos are next up. The grid system we established earlier will be our guide as we define the various image sizes needed. Once again using the t-shirt sizing constraint, I will typically create a base, small, medium, and large image variation based on the widths that are derived from the grids, and the heights being dictated by a consistent aspect ratio (e.g. 16:9 of 1920 is 1080, etc.). I also make sure to create a ‘full-bleed’ image variation for circumstances where I want the image to take up the full width of the design, as well as smaller ‘thumbnail’ variations that might not be the same aspect ratio as content images.

Biased by Design image components

We’ve gone through a step-by-step breakdown of my process for building UI component libraries based on design fundamentals that can grow and evolve to fit the needs of any interface. These foundational elements that were established will form the foundation for the components and patterns that come in the future. Next up, we’ll dive into how to define those reusable components using these foundational design elements. Stay tuned!

Cognitive Bias and the Design Process, Part 2

Thu, 09 Dec 2021 00:00:00 +0000

At any given moment we’re faced with countless bits of information to process so that we can form judgments, make decisions, and get through the day. We’ve developed mental shortcuts to avoid becoming overwhelmed but these shortcuts have a downside: they often lead to fallacious reasoning and unintended results. Designers are just as vulnerable to the blindspots and fallacies that come with cognitive bias as the people who use the products and services we design. It’s impossible to entirely eliminate bias, but we can seek to understand them and identify how they might impact our design decisions.

In this article, I continue my exploration of the most common cognitive biases that designers must deal with during the design process. It’s by no means a comprehensive list, rather a dive into the ones that I’ve experienced regularly in my work. If you haven’t read the first part of this series, you can check it out here. Let’s get started!

You are not the User

A 1976 study¹ conducted at Stanford University presented participants with hypothetical situations and asked them to determine what percentage of people would make one of two choices. For example, one situation asked participants to determine what percentage of their peers would vote for a referendum that allocated large sums of money towards a revived space program with the goal of manned and unmanned exploration of the moon and planets nearest Earth. Some additional context was given, explaining that supporters would argue that this would provide jobs, spur technology, and promote national pride and unity. In contrast, opponents argue that a space program will increase taxes or else drain money from important domestic priorities while not achieving the goals of the program.

Once the participants provided their estimate, they were asked to disclose what they would do given the situation and fill out two questionnaires about the personality traits of those who would make each of the two choices. Researchers concluded that the participants not only expected that most of their peers would make the same choices they did but assumed those that opted for the choice had extreme personality traits.

People often overestimate the degree to which other people will agree, think, and behave the way they do.

The study highlights our tendency to assume that our personal qualities, characteristics, beliefs, and actions are relatively widespread while alternate points of view are rare, deviant, and more extreme. This bias, known in psychology as the false-consensus effect, can skew our thinking and negatively influence design decisions.

How it occurs

As the study described above indicates, people often overestimate the degree to which other people will agree, think, and behave the way they do. This applies to designers, developers, and UX researchers who are tasked with creating digital interfaces as well: we infer generalizations when we assume that others will perceive and understand the interface in the same way we do. The false-consensus effect can be found in the design process when there’s a lack of data on how the actual users respond to your designs.

Identify your assumptions

The first step is to identify the assumptions you or your team are making about the intended users. Whether it’s assumptions related to their needs, pain points, or how they accomplish tasks, we must begin by acknowledging the things we are assuming. Once assumptions have been identified, they should be prioritized by the amount of risk they carry and investigated via tests.

Test with real users

The next step is to conduct user interviews and usability tests with the intended audience. User interviews are critical in understanding the decision-making process, needs and frustrations, opportunities, and how steps are taken to complete tasks. Usability tests are also quite effective for understanding how actual users respond to your designs by watching them use these designs and challenging your assumptions.

Availability bias

A mental shortcut that relies on immediate examples that come to a given person’s mind when evaluating a specific topic, concept, method, or decision.

Negativity bias

The notion is that even when of equal intensity, things of a more negative nature (e.g. unpleasant thoughts, emotions, or social interactions; harmful/traumatic events) have a greater effect on one’s psychological state and processes than neutral or positive things.

Loss aversion

The tendency to prefer avoiding losses to acquiring equivalent gains.

Reason over recall

A study² conducted by Amos Tversky and Daniel Kahneman in 1982 asked a sample of 245 University of British Columbia undergraduates to evaluate the probability of several catastrophic events in 1983. The events were presented in two versions: one that included only the basic outcome and another that included a more detailed scenario leading to the same outcome. For example, half of the participants evaluated the probability of a massive flood somewhere in North America in which more than 1000 people drown. The other half evaluated the probability of an earthquake in California, causing a flood in which more than 1000 people drown. A 9-point scale was used for the estimations: less than .01%, .1%, .5%, 1%, 2%, 5%, 10%, 25%, and 50% or more.

What Tversky and Kahneman found was that the estimates of the conjunction (earthquake and flood) were significantly higher than the estimates of just the flood (p < .01, by a Mann-Whitney test). Even though the chance of a flood in California is smaller than that of a flood for all of North America, participants estimated that the chance of the flood provoked by an earthquake in California is higher. The researchers concluded that since an earthquake causing a flood in California is more specific and easier to imagine (versus a flood in an ambiguous area like all of North America), people are more likely to believe its probability. The same pattern was observed in other problems.

When we make decisions based on what’s easy to recall, we fall into the trap of letting limited information guide us rather than reasoning through the situation.

The study highlights our tendency to believe that the easier that something is to recall, the more frequent it must happen. This tendency, known as the availability heuristic, is a common bias we fall into as a way for our brains to make conclusions with little mental effort or strain based on evidence that is instantly available into our mind. It can also heavily influence our decision-making abilities and prevent us from seeing the bigger picture.

How it occurs

Mental shortcuts such as the availability heuristic most commonly occur when we need to make quick decisions and therefore rely on information that is easily recalled. This falls within the category of System 1 thinking, or the mental events that occur automatically and require little or no effort. When we let this bias drive our design decisions, it can easily lead to setting goals based on what’s easy to measure (versus what’s valuable to measure) or blindly mimicking competitors as a result of ‘competitor research’.

Invoke System 2 thinking

When we make decisions based on what’s easy to recall, we fall into the trap of letting limited information guide us rather than reasoning through the situation. One effective approach to avoiding the pitfalls of this bias is to intentionally invoke System 2 thinking, which requires deliberate processing and contemplation. The enhanced monitoring of System 2 thinking works to override the impulses of System 1 and give us the room to slow down, identify our biases, and more carefully consider the impact of our decisions.

Valuable metrics only

Relying on data that quickly comes to mind can easily impact how success is defined within a product or service. When project goals are set based on what’s easy to measure versus what’s valuable, the measure becomes a target and we will game the system to hit that target (i.e. clicks, DAU, MAU). This ultimately leads to losing track of the needs and goals of the people who use the product or service. The alternative is taking time to understand what the needs and goals of people actually are and then defining the appropriate metrics that correspond to them.

Survivorship bias

The logical error of concentrating on the people or things that made it past some selection process and overlooking those that did not, typically because of their lack of visibility.

Confirmation bias

The tendency to search for, interpret, favor, and recall information in a way that confirms or supports one’s prior beliefs or values.

A study³ published in 2006 by Emily Pronin and Matthew Kugler explored how people make judgments about themselves and others. The study began with the researchers explaining cognitive bias to the participants. Next, they were asked how might cognitive bias might affect their judgment concerning the other participants. What the researchers found was that test participant rated themselves as less susceptible to bias than others in the experiment. When they were asked to explain the judgment of others, they did so openly. In contrast, when they were asked to explain their own judgments, they looked inward and searched their thoughts and feelings for biased motives. The fact that biases operate unconsciously means that this introspection was not informative, but people mistakenly interpret them as evidence that they are immune to bias.

The implicit biases that govern our decision-making and judgments are always present.

We believe that we are rational, that our actions and judgments are accurate, and they are not influenced by unconscious bias. However, the study described highlights the tendency for people to not see their own biases and see themselves as less susceptible to bias than others. In psychology, this is known as a bias blind spot, and its potential to undermine the decision-making process has a profound impact on design teams.

How it occurs

The implicit biases that govern our decision-making and judgments are always present. They are part of our design as humans, enabling us to efficiently process information and get through the day without getting overwhelmed. They are useful mental shortcuts that can become a problem when we’re unaware of them and we base our decisions and judgments on the assumptions and perspectives we believe to be true.

Acknowledge your bias

The moment we acknowledge that we are operating under unconscious bias, we are then empowered to change it. We must first seek to understand the biases that affect our judgment and decision-making ability. Once we recognize the fact that our own biases can influence us, we can begin the process of identifying them and determine the best approach for overcoming them.

Seek Perspective

Feedback helps to identify our unconscious bias and how it’s affecting our judgment and decision-making ability. Our work becomes more inclusive once we embrace a plurality of perspectives. We must seek a variety of perspectives to broaden how we think of our work and the value it provides people.

Cultivate diversity

Diverse teams bring diversity in life experience and increase a team’s ability to counter the unconscious bias present in homogeneous groups. We must cultivate diversity within our teams to bring a diversity of thinking to our work.

Egocentric bias

The tendency to rely too heavily on one’s perspective and/or have a higher opinion of oneself than reality.

False-consensus effect

The tendency to assume that our personal qualities, characteristics, beliefs, and actions are relatively widespread through the general population.

These biases enable us to efficiently process information and get through the day without getting overwhelmed, but can also become problematic when we’re unaware of them and we base our decisions and judgments on the assumptions and perspectives we believe to be true. Once we acknowledge that we are not the user, we break from the self-referential thinking that can limit our ability to design truly effective solutions. We can use reason over recall to avoid setting goals based on what’s easy to measure or blindly mimicking competitors as a result of ‘competitor research’. Finally, we must accept that we are susceptible to implicit biases that govern our decision-making and judgments.

L. Ross, D. Greene, P. House. 1977. The “False Consensus Effect: An Egocentric Bias in Social Perception and Attribution Processes”. Journal Of Experimental Social Psychology. ↩︎
Tversky, A., & Kahneman, D. (1983). “Extensional versus intuitive reasoning: The conjunction fallacy in probability judgment”. Psychological Review, 90(4), 293–315. ↩︎
Pronin, E., Kugler, M. (2007). “Valuing thoughts, ignoring behavior: The introspection illusion as a source of the bias blind spot”. Journal of Experimental Social Psychology. Elsevier. 43 (4): 565–578. doi:10.1016/j.jesp.2006.05.011. ↩︎

Cognitive Bias and the Design Process, Part 1

Tue, 01 Jun 2021 00:00:00 +0000

Designers are just as vulnerable to the blindspots and fallacies that come with cognitive bias as the people who use the products and services we design. Bias can creep into the design process when we aren’t diligent enough to identify and mitigate it upfront. A big part of avoiding this is by cultivating awareness of when and how they can be introduced into the design process and influence design decisions.

This article explores a few cognitive biases I’ve experienced first-hand as well as strategies for mitigating their influence. These biases are by no means the only ones that I think designers should be aware of – there are many, many others as well. That being said, I think these are the most common ones that designers must deal with during the design process. They are also the ones that have the potential to influence design decisions the most, which ultimately impact the products and services we help to build.

Consider What You Don’t See

During World War II, the Statistical Research Group at Columbia University was asked by the U.S. military to examine the damage done to bombers that had returned from missions. Their objective was to determine where armor could be added to the bombers to increase the protection from the flak and bullets. Planes that returned were carefully examined and damage was compared across all the planes. The consensus was that additional armor should be added to the areas of the planes that show the most common patterns of damage: the wings, tailfin, and middle of the planes.

Luckily, a statistician on the project by the name of Abraham Wald countered this conclusion by pointing out that the planes being examined were only those that survived, therefore calculations were missing a critical set of data (the planes that didn’t make it back). As a result, Wald recommended that armor get added to the areas that showed the least damage to reinforce the most vulnerable parts of the planes.¹

The case study of World War II bombers highlights our tendency to concentrate on the people or things that made it past a selection process and overlook those that do not, typically because of their lack of visibility. This can lead to false conclusions in several different ways. This tendency is known as survivorship bias and it can show up during a critical part of the design process.

How it occurs

Research is a critical part of the design process because it forms the backbone of understanding in regards to end-users and how the product or service we’re designing will fit into their lives. The data we receive during this time is fundamental to the success of a project — as it helps to guide subsequent design decisions. One critical way that survivorship bias can creep into the design process is through the participants we choose (or leave out) of design research. A lack of participant diversity will inevitably lead to a lack of data diversity. If you’re only considering one perspective, it will reduce the reliability of the data.

Design feedback is another crucial part of the design process and also one that survivorship bias can take hold. The best design is that which considers a diversity of perspectives, specifically in regards to the people who will be using it. For example, focusing too much on only the positive feedback from our peers is likely to result in solutions that aren’t resilient enough. If the team with which we are receiving feedback lacks diversity, so will too the input we receive during the design process.

Factoring in failure

While survivorship bias is common within the design process, there are ways to counter it as well. When we focus too much on success stories, positive metrics, or ‘happy paths’ in our designs, we lose sight of how the design responds when things fail. Consideration of only positive feedback is likely to lead to a very one-sided design approach. It’s best to factor in failure, consider where things can go wrong, centralize the edge cases in the design process, and seek out diverse perspectives during design reviews. In other words, we can make our designs more resilient by considering the unhappy path just as thoroughly as the happy one. In the process of designing for the less ideal scenarios, we address the fundamental features needed for everyone.

Recognize the limits of quantitative data

We must remember quantitative data is only relevant to the actions currently available and therefore has the potential to limit our thinking. As Erika Hall points out in Just Enough Research, “By asking why we can see the opportunity for something better beyond the bounds of the current best”.² We should consider what the quantitative data isn’t telling us to make more informed design decisions.

Sampling Bias

A bias in which a sample is collected in such a way that some members of the intended population have a lower or higher sampling probability than others.

Availability heuristic

A mental shortcut that relies on immediate examples that come to a given person’s mind when evaluating a specific topic, concept, method, or decision.

Don’t build solutions in search of a problem

People who hold strong opinions on complex social issues are likely to examine relevant empirical evidence in a biased manner. As a result, they will accept confirming evidence at face value while critically examining evidence that disconfirms their opinions. This was the conclusion of a study conducted in 1979 at Stanford University concerning capital punishment.³ In the study, each participant read a comparison of U.S. states with and without the death penalty, and then a comparison of murder rates in a state before and after the introduction of the death penalty. The participants were asked whether their opinions had changed. Next, they read a more detailed account of each comparison’s procedure and had to rate whether the research was well-conducted and convincing. Participants were told that one comparison supported the deterrent effect and the other comparison undermined it, while for other participants the conclusions were swapped. In fact, both comparisons were fictional.

The participants, whether supporters or opponents of capital punishment, reported shifting their attitudes slightly in the direction of the first comparison they read. After reading the more detailed descriptions of the two comparisons, almost all returned to their original belief regardless of the evidence provided, pointing to details that supported their viewpoint and disregarding anything contrary. The results illustrated that people set higher standards of evidence for hypotheses that go against their current expectations.

We tend to search for, interpret, favor, and recall information in a way that confirms or supports our prior beliefs or values. This tendency is known as confirmation bias, and when we aren’t careful it can also show up during the design process as well.

How it occurs

Generally speaking, we can be susceptible to confirmation bias whenever we seek information. One place we can anticipate it showing up throughout the design process is during user testing. For example, focusing on test findings that validate the desired outcome. Another way confirmation bias can find its way into the design process is through design feedback. Similar to survivorship bias, the best design is that which considers a diversity of perspectives, specifically in regards to the people who will be using it. This is also an important consideration with confirmation bias, where we can block out or become more critical when receiving feedback that doesn’t validate or support the design direction we’d prefer.

Multi-faceted user research

You’ve probably heard the saying “pay attention to what users do, not what they say”. User actions and feedback is seldomly aligned, and this can introduce inaccurate data in the design process if we rely too much on user feedback alone. Feedback is great for understanding user thinking, but not great for understanding their actions. One way to combat the confirmation bias is a multi-faceted approach to user research. Using a combination of user interviews, usability testing, and quantitative analysis to understand peoples’ actions will help to avoid the bias that comes with overly relying on any single method.

Red Team, Blue Team

Another effective approach to combating confirmation bias is to designate a separate team (the red team) to pick apart a design and find the flaws. In his book Designing for Cognitive Bias, David Dylan Thomas points out the effectiveness of an exercise called ‘Red Team, Blue Team’ in which the red team seeks to uncover “very little unseen flaw, every overlooked potential for harm, every more elegant solution that the blue team missed because they were so in love with their initial idea” ⁴. This can be both an efficient way to quickly discover the bias embedded into the design output of the team and avoid the pitfalls of falling in love with the wrong idea.

Watch for overly optimistic interpretation of data

A critical eye is necessary during design research. We must be diligent not to interpret data the wrong way, especially if the interpretation favors the desired outcome. When we watch for an overly optimistic interpretation of research findings or design feedback, we can avoid confirming a preexisting bias towards a specific option or approach.

False consensus effect

A pervasive cognitive bias that causes people to see their own behavioral choices and judgments as relatively common and appropriate to existing circumstances.

Observer-expectancy effect

A form of reactivity in which a researcher’s cognitive bias causes them to subconsciously influence the participants of an experiment.

Semmelweis reflex

A metaphor for the reflex-like tendency to reject new evidence or new knowledge because it contradicts established norms, beliefs, or paradigms.

Become aware of your decision frame

In 1981, Amos Tversky and Daniel Kahneman explored how different phrasing affected participants’ responses to a choice in a hypothetical life and death situation.⁵ In the study, participants were asked to choose between two treatments for 600 people affected by a deadly disease. Treatment A was predicted to result in 400 deaths, whereas treatment B had a 33% chance that no one would die but a 66% chance that everyone would die. This choice was then presented to participants either with positive framing, i.e. how many people would live or with negative framing, i.e. how many people would die. Treatment A was chosen by 72% of participants when it was presented with positive framing (“saves 200 lives”) dropping to 22% when the same choice was presented with negative framing (“400 people will die”).

The choice of the participants in this study highlights our tendency to make decisions based on whether the options are presented with positive or negative connotations; e.g. as a loss or as a gain. In psychology, this is known as the framing effect and it affects all aspects of the design process, from interpreting research findings to selecting design alternatives.

How it occurs

Framing tends to happen in two ways during design research. Firstly, the phrasing of questions during user interviews or usability tests can have a significant impact on the response of participants. Secondly, how we choose to present research findings. Another potential entry point for framing during the design process is when receiving design feedback. Overly specific feedback can frame up the problem in a way that limits the design solution, or influences it in a way that leads to overlooking other important considerations.

Think through the context

Solutioning when we should be still gathering information can be a constant challenge for team members, especially for designers. While it may be tempting to jump into solutions right away, taking a little more time to think through context will significantly impact how we interpret the data. It’s only once we spend ample time with the gathered data that we can begin to synthesize useful insights from it and identify patterns that aren’t as obvious on the surface.

Gather more context

Instead of making a decision based on however much data you have, wait until you have enough to make an informed decision. Sometimes research uncovers what we need to learn more about. You’ll know you have enough information to make an informed decision when you have a clear idea of the problem and sufficient information to begin on a solution.

Switch your view

Another way to diagnose if your opinion is being influenced by framing is to switch up your point of view. You can do this by reversing a data point from a success rate to a failure rate, or taking the opposite approach to articulating a problem. The point of this is to perceive the data from another angle to avoid emphasis or exclusion of specific information.

Interviewer bias

A bias caused by mistakes made by the interviewer, which may include influencing the respondent in some way, asking questions in the wrong order, or using slightly different phrasing (or tone of voice) than other interviewers.

The Hawthorne effect

A type of reactivity in which individuals modify an aspect of their behavior in response to their awareness of being observed.

A type of response bias that is the tendency of survey respondents to answer questions in a manner that will be viewed favorably by others.

We must remember that we’re just as vulnerable to the blindspots and fallacies of cognitive bias as the people who use the products and services we design. Our own bias can creep into the design process if we aren’t being diligent enough to identify and mitigate them upfront. A big part of mitigating this is simply being aware of when and how they can emerge and influence design decisions.

When we consider what we don’t see, we can get a more accurate representation of data and avoid the pitfalls of survivorship bias. When we refrain from building solutions in search of a problem, we can ensure the products and services we do build focus on the actual needs of end-users and dodges the risk of confirmation bias. Finally, we can cultivate awareness of our decision frames to mitigate their impact on design decisions.

Advice for Aspiring Designers

Mon, 08 Mar 2021 00:00:00 +0000

I’m often asked by students or those making a pivot in their careers for my advice on pursuing UX design. It’s not a question I mind taking the time to answer because I’m incredibly grateful for the guidance I’ve received throughout my own career. This article documents my thoughts on the topic as well as my own journey.

Should I get into UX design?

Let’s start off by first asking a question that exists in the subtext: “should I even get into UX?". The answer to this question, like many things in life, is it depends. Everyone’s path will look different, and we each face challenges and goals specific to who we are and who we want to be. That being said, the discipline could be a good fit if you’re:

Interested in function, not just form

How a product or service looks plays an important role, but how it works is what interests you the most. Good user experiences require an understanding of people’s needs and elegantly meet those needs. This can only be achieved when a product or service combines form and function to solve a real problem.

Think of design as a science, not an art

Understanding a problem and then using data to inform the design of a solution involves a rigorous process of observation, analyzing, testing, and validation. Design is about problem-solving, whereas art is about self-expression. That’s not to say that a design solution cannot be inspired, but its core function must be centered around solving a problem and simplifying the complex.

Enjoy collaboration and iteration

UX design is a highly collaborative discipline that requires you to work closely with your colleagues in marketing, development, engineering, leadership, etc. Great design solutions don’t just magically materialize. Participation of many different functions and perspectives within an iterative process is paramount to finding a great design solution.

Possess empathy

The ability to empathize with people to understand their goals and pain points is critical to the work of a UX designer. We are the advocates of the people who use the products and services we build, which requires that we have the empathy needed to effectively design for them.

How did you get started in UX design?

My family didn’t have a lot of money growing up but my mom was always really supportive when it came to my interests, especially art. She’d take me to art museums, enroll me in summer art classes, and buy me art supplies. She encouraged me to pursue my interest in art, even though it was an uncommon career path where I grew up in Arkansas. Her encouragement pushed me to work hard, and this hard work won me a spot in summer art camp at Memphis College of Art (RIP). It was during this time I learned about graphic design and realized that design is what I wanted to do. A couple of years later, I was back at art school but this time enrolled as a freshman.

Art school provided a more traditional design education that emphasized history, foundations, and form. I realized shortly after graduation that I needed to be more technically adept in the digital space, so I started to experiment a little bit on the side with it. I also needed an online portfolio and there weren’t a lot of great no-code options at the time, so I started learning how to code on my own. I still remember printing out the source code from sites I liked, studying each line of code, and trying to understand it. When the iPhone came out in 2007, this gravitation towards the digital space accelerated and I found myself immersed in the challenges and opportunities of designing for the web. It didn’t take long for me to be completely enveloped with interaction design and front-end web development, which lead to me seeking out opportunities to do more design work that involved it.

My big break came when I had an opportunity to work on a project for mobile Internet access provider Boingo. This project involved redesigning their web presence, ensuring the various pages could be accessed via any device, and improving the overall user experience. It was a trial-by-fire opportunity that challenged me to learn new things and exposed me to UX design. I knew that UX was where I wanted to focus from this point on, so I sought out roles and opportunities that I knew would deepen my knowledge.

Screenshots from redesigned Boingo landing pages

Over the years, I’ve increased my knowledge and skills through working in a variety of roles at different kinds of companies. Each experience has taught me something new and expanded my knowledge in the discipline. I’ve had the opportunity to work at boutique design studios, in-house design teams, experience/technology agencies, and corporations. I also put a big focus on side-projects, which allows me to learn and gain experience with things that I don’t get a chance to with my client work. This brings us to the most common question I’m asked by aspiring designers…

What’s the best way to get started in UX design?

The most common question I’m asked always centers around how to get started in UX design, to which my response is always nothing can substitute real-world experience. Building the skills required from a UX designer takes time, patience, and dedication. Higher education is a great way to bootstrap yourself with some core skills, but it will not prepare you for actual challenges you’ll face with client work. In other words, being proficient with a design tool and a few methods doesn’t make you a UX designer. There simply isn’t a one-size-fits-all process. Being effective requires versatility — something you don’t really learn in school, much less a 6-month boot camp. It’s gained through experience on the job and learning what’s appropriate given the needs of the project.

I found my way to UX through graphic design, and slowly over many different roles and experiences gravitated towards UX design. It took time and dedication to continue to pursue roles within teams that I knew could teach and challenge me. That’s not to say that I think my path is the only one — but once again, nothing can substitute real-world experience. You can start anywhere as long as you know your end goal and you commit to actively pursuing opportunities to learn and grow along the way.

How can I stand out as a UX designer?

Standing out is increasingly important, as more people are joining the design industry each year. Your portfolio is one way to stand out. Here are some things to take into consideration.

Passion

The best way to make your portfolio stand out with something additional to student work is through real-life projects, speculative projects, or passion projects. Finding real-life projects means finding a business/service/app you’re aware of that might need some help, and offering your services. Nothing beats real-life projects and the constraints that come with them to demonstrate your thought process, problem-solving and technical skills.

Self-initiated projects are great too, but often lack the real constraints of real-life projects (e.g. speculative redesign of [enter name of some popular app]). They’re still great for demonstrating thought-process and technical skills, etc.

Finally, there are passion projects, which always help you to stand out because they demonstrate what you’re really passionate about. Passional projects not only provide a big advantage for designers looking to stand out, but they’re an opportunity to explore tools or techniques to demonstrate additional skills.

Do what you love to do even if it means doing it during your personal time — eventually, it will be what you get to do all the time.

If passion projects are of interest to you, I suggest checking out this article I wrote for Smashing Magazine. In the article, I explore these benefits, as well as learn how to decide on a project and how to effectively manage our time.

Process

Designers must spend time on clearly articulating process, research, and findings, what went wrong alongside what went well, and impact or results. Make sure your portfolio is clean, easy-to-navigate, simple to use, and lets the work shine. When it comes to your work, remember there is no one-size-fits-all process — each project will necessitate a different approach, and the process that worked on the last project may not be appropriate for the next.

Nothing says inexperienced designer more than each project in your portfolio following the exact same process.

Learn what you need to when you need to and don’t get carried away with trying to always know the new shiny tool, the latest technique, or some new method. Tools and processes change, but good design is timeless.

Aptitude

Aptitude is a vital part of the growth in any career. A person’s capacity and eagerness to learn are just as important, if not more so than technical knowledge. The reality is no one comes out of school fully prepared for the challenges that come with client projects or working within a product team. Skills and knowledge must be gained through experience, and therefore the drive to learn is fundamental. Each role will have unique challenges and with each challenge comes an opportunity to grow and expand your knowledge.

I talked about my own journey and how I found my way to UX through many different roles and experiences. It took time and dedication to continue to pursue roles within teams that I knew could teach and challenge me. While I don’t think the path I took is the only one, I also think that nothing can substitute real-world experience. Each experience has taught me something new and expanded my knowledge in the discipline. You can start anywhere as long as you know your end goal and you commit to actively pursuing opportunities to learn and grow along the way. When it comes to standing out, remember that passion, process and aptitude will enable you to shine. Never stop learning, stay hungry but humble, and good luck!

AI in Design

Mon, 22 Feb 2021 00:00:00 +0000

2020 brought with it plenty of surprises, setbacks, and upheaval. Not only did the year shed a harsh light on systemic issues plaguing healthcare systems, leadership, and social injustices, but it provided a glimpse into many of the challenges we’ll face in the future. Things seemed to shift to that unmistaken point of no return — as if to signal things would never go back to being “normal” (if there ever was such a thing). For designers, it also provided a glimpse into what the future of design tools might look like with the announcement and subsequent demos of GPT-3.

GPT-3 is a language-generating AI by Open AI that can generate amazing human-like text on demand. It’s the largest language model ever created and early experiments have demonstrated its ability to produce convincing streams of text in a range of different styles given a few parameters. What’s perhaps even more unnerving is its ability to output code, which can then be consumed and acted on within design tools. Take for example Jordan Singer’s demo of a Figma plugin called ‘Designer’ that can generate a functional prototype from raw text. By describing the layout as “an app that has a navigation bar with a camera icon, ‘Photos’ title, and a message icon, a feed of photos with each photo having a user icon, a photo, a heart icon, and a chat bubble icon”, Singer demonstrated the plugin’s ability to generate an Instagram-like layout without doing anything else.

Screenshot from Designer Figma plugin demo

Singer’s demo caused quite the stir and for good reason: tools such as this will continue to improve, and we all know it. It signals a future where many of the tasks we perform now will be automated or at least aided by AI. Technology that has the potential to eliminate tasks, and by extension the potential to eliminate jobs, will invariably elicit some fear. This is especially true in an industry that already has a firm grasp on how technology can disrupt and eliminate jobs. While AI will no doubt reduce the need to manually perform many tasks, its benefits will also open up opportunities and help to automate menial tasks which will free us up to focus on the more meaningful work that provides additional value. The question becomes: how might we leverage AI and the benefits it brings to help in the design process? Additionally, how might things go wrong when leveraging AI in the design process?

AI is already here

First, it’s important to note that algorithm-driven design is already being harnessed within the greater design industry. Let’s take a closer look at a couple of the categories these current uses fall and explore examples of them already available.

Automation

Thanks to AI, we can automatically generate documentation, specifications, patterns, and anything else that is tedious and time-consuming. Take for example Zeplin, which enables us to automatically generate specification details such as font sizing, colors, spacing, and other information vital to implementation. It even customizes the output based on the intended target platform (Web, iOS, or Android) and allows for assets to be directly extracted for development. Long gone are the days of manually ‘red-lining’ design documents to provide the necessary information for development.

Screenshot of Zeplin

Then of course there are examples like Airbnb’s experiments that can live-code prototypes from whiteboard drawings, translate high fidelity mocks into component specifications, and translate production code into design files for iteration by designers. By leveraging the power of AI and machine learning, this tool can significantly speed up a part of the design process and enables the designers to focus more on the idea.

Screenshot of Airbnb generating code from low fidelity wireframes

There are even usability tests that can be conducted with tools powered by AI, eliminating the need to recruit a single participant. Take for example VisualEyes, which simulates eye-tracking studies and preference tests with a 93% accurate predictive technology. The plugin is compatible with all popular design tools, enabling instant results without leaving your design tool or browser window.

Screenshot of the VisualEyes plugin in action

These are but a few of the many examples of design tools that can automate tasks, and thus increase the productivity of the designers using them. Next up, we’ll take a look at another predominant category.

Generative

The idea behind generative design is to quickly generate a plethora of design alternatives based on a single concept. Parameters such as goals, constraints, and materials can be set to guide the generation of all possible permutations of a solution, with the software testing and learning from each iteration. The objective is to amplify human cognitive abilities to design things that were out of reach otherwise.

There’s an increasing number of examples of generative design being used both in the experimental and real-world context. Perhaps the most impressive examples of generative design come from the industrial design and architecture space. Take for example GM’s use of tools like Autodesk to generate auto parts that combine several parts into one to form a new part that is 40% lighter in weight and 20% stronger. The designer plays the role of curator by harnessing the iterative power of AI to generate and test concepts that would be near impossible to come to otherwise.

Generated parts by Autodesk

You’re not mastering the tool any longer, you’re mastering the problem — and letting the computer do all the work.

Caleb Meyer, Project Industrial Designer

There are also some early examples of generative design making its way into the UX space as well. One of my favorites is an experimental tool by Jon Gold called Rene. This declarative, permutational design tool allows you to generate variations of text treatments on a block of text. Each modification generates new iterations, displays them next to older iterations so that you can see the evolution, and enables you to select a single instance to start a new branch of iteration.

Screenshot of Rene by Jon Gold

The examples above are some of my favorites, but there are many others. Virtually any tool could benefit from some form of AI to help augment the capabilities of the designer — it’s simply a matter of identifying which process it’s suited for.

The Future

Now that we’ve looked at the various ways that AI is already being utilized by designers, let’s explore how might AI manifest itself in the future to help designers.

Integrated layout generation

Exploration and iteration are paramount to interface design. Designers often find themselves copying and pasting artboards to make small modifications over and over to get composition and styling just right. One potential use-case for AI could be the ability to generate many permutations of a layout of an interface easily within our design tool of choice, thus speeding up the process of iteration. Permutations can be generated as much as needed, with the level of granularity being controllable via the generation settings and based on the designer’s selections and preferences.

Layout generation concept mockup

Automated design system generation

Design systems have completely changed the way design teams build digital products and services. By focusing on a collection of reusable components that are guided by clear standards and can be assembled to build any number of applications, teams can expedite and scale their productivity in a consistent manner. While the effort to build and manage a design system is still a significant investment of time and resources, the benefits to the team are quite worth it. What if we could reduce the level of effort involved through automatic generation of them, and therefore lower the barrier for teams to create and manage them? Allowing AI to monitor digital properties, generate design system components and then maintain updates in real-time would ensure designers can focus more on customer needs and feel confident their designs will scale accordingly. What if we could automatically generate a design system?

What is we could automatically generate a design system?

Automated heuristic evaluation

Another potential use case for AI in the design process would be automated heuristic evaluations that happen as the design process is underway. Much like the accessibility tools designers use to check for color contrast, an automated report based on a selected artboard could surface up guidelines or feedback to help guide the design process while it’s underway. Once again, this tooling could be baked right into your design tool of choice and would help to ensure designs follow general best practices. Teams could even train the AI on specific design principles and receive feedback way ahead of a team review, helping to reduce design cycles.

Heuristic evaluation concept mockup

The speculative examples above are but a few potential ways that AI can be integrated into our design tools. There are many more possibilities here, each of which could help expedite, augment or automate the design process.

How might things go wrong?

As the potential power and impact of AI become clear, early adopters are already establishing principles for how it should be applied, and more importantly how it should not be applied. AI will inevitably become an important tool in the designer’s tool belt. Now is the time for us to consider how might things go wrong when leveraging AI in the design process and strategies for avoiding these mishaps.

The AI is trained on bad data

It’s clear at this point that AI is only as good as the data it’s trained on — AI algorithms and datasets will reflect and reinforce unfair biases if that’s what it’s fed. Our design tools and processes that leverage AI will be susceptible to the same biases, which could inevitably end up affecting the design work we do. The ultimate risk is that the latent biases that are embedded into our design tools end up harming the people who use the products and services we create. Take for example Microsoft’s AI chatbot Tay, which was launched on Twitter and was taken down in less than 24 hours. What began as an experiment in “conversational understanding” where the chatbot would learn with each interaction quickly turned into a reflection of people’s worst tendencies. It’s not hard to imagine the potential risk of leveraging a tool like this to generate conversational text strings in our design mockups or even make its way into production.

Microsoft’s AI chatbot being racist

To reduce the unjust impact on people, we must ensure the AI we incorporated in our design tools are trained on diverse datasets, especially in regards to race, ethnicity, gender, nationality, income, sexual orientation, ability, and political or religious belief.

We automate the wrong things

Automation can be quite an attractive option when it’s a possibility. It’s a slippery slope in which all tasks begin to look like nails, and automation is the hammer. The obvious risk we run here is automating tasks that should not be automated, specific tasks that require a human touch. Humans are just better suited for certain kinds of tasks, e.g. those that depend on creative problem-solving. When we automate the wrong things, we lose the human touch that makes human-centered design so effective. We must ensure any use of AI in our design tools is centered around augmenting our abilities as designers, not replacing them.

It was clear that Singer’s GPT-3 demos struck a nerve in the design community. After all, we’re all too aware of how technology can disrupt entire industries. It’s important to remember that the goal of harnessing AI in design tools is to create a better design by eliminating the need to do repetitive tasks or tasks of low value but are still necessary. We can leverage the automation that AI enables now and in the future to free us up to do the more meaningful design that provides additional value. Also, we can embrace its generative capabilities to amplify our cognitive abilities to design things that were out of reach otherwise. There are countless use cases that AI could be used to help in the design process — the opportunities here are virtually infinite. It’s time that we embrace AI in design tools and identify how they can help us do better work.

Augmenting design capabilities with AI

Check out this interview I did with UX Objective Podcast about how AI can augment design capabilities and help designers focus on problems only people can solve.

Laws of UX v2.0

Tue, 26 Jan 2021 00:00:00 +0000

Laws of UX was launched in January 2018 with the goal to make complex psychology heuristics more accessible to designers. Since this time, I’ve gotten some great feedback on the site, which I’ve collected in preparation for a major update. This post takes a closer look at the goals of this update, challenges I faced along the way, and how success was measured.

Primary Goals

The first task was to define what my primary goals would be for this redesign. In the three years since the initial launch of the website, I made relatively few design or development updates — most of the focus was on further expanding the content. The redesign was an opportunity to address the things I’ve been wanting to do for a while and I had a substantial list, so priortization was key. The following items are what I eventually identified would be the primary goals to focus on:

Refresh UI
Increase scanability of the home page
Prioritize accessibility
Prioritize performance
Enable offline browsing
Refactor develop tooling to leverage Hugo for statics site generation
Expand content to include pages related to the Laws of UX book and additional information.

There were also a number of secondary goals such as implementing responsive typography for fluid type sizing, generating an RSS feed for the home page, and removing all Javascript dependencies. These items were still important but just less of a priority given the impact the primary goals.

Refresh UI

While the website has served it’s intended audience quite well over the years, there’s always room for improvement. A key element that I wanted to iterate on was the overall color harmonization. The colors of the last design worked well but I saw an opportunity to improve this more by adding a hint of color to background, which was previously a neutral dark gray. This UI trick is useful for ensuring colors synchronize and once I applied this change, the various colors featured by each card paired much better with the site background color. In addition to this global color change, I also darkened many of the colors featured in the cards to increase contrast for better readability.

Increase Scanability

As the content on the site continues to grow, the need for better scannability on the homepage has increased. To help with this, I refactored the homepage to feature a card grid that allows visitors to quickly scan the page and find the item they’re looking for. I’ve also included a handy filter that further increases the ability to find specific content via browsing by category.

Screenshot detail from the redesigned Laws of UX homepage

Prioritize Accessibility

Accessibilty was a metric I paid close attention to with this redesign. Using Google’s Lighthouse tool to audit each page, I honed in on this metric to identify issues I needed to address. This meant ensuring the site was tranversable via keyboards and screenreaders, items were tagged with the correct ARIA attributes, sufficient color contrast was provided, headings follow a logical order, and much more.

There’s a number of handy features for testing accessibility embedded right in the developer tools of modern browsers. The abilty to test color contrast, check for appropriate labels for screen readers, and evaulate support for keyboard navigation are available without additional browser extensions. Check out Seven ways to test for accessibility of your web site with browser Developer Tools to learn more.

Color Contrast

Color contrast was an item I needed to spend a little extra time with during this process. The reason for this was because many of the original colors didn’t provide sufficient contrast with the light text. To correct this issue, I used the developer tools in Chrome to inspect text elements on the page and modified the brightness + saturation of each color until it met WCAG AA compliance. This was effective for larger text such as the heading elements on detail pages, but wasn’t effective for the smaller description text on cards. To ensure the description text of all cards met the same contrast criteria, I modified them to display on the same dark background color.

Before and after screenshots of the card component resulting from color constrast adjustments

Prioritize Performance

Performance was another metric I wanted to spend a lot of time on with the redesign. The site has always been relatively fast, but the redesign opened up an opportunity for me to really consider performance as a key design feature. Changes such as replacing GSAP with CSS animations on the hero banners of each page, removing unnecessary Javascript plugins and inlining critical CSS all helped to ensure the site performance was blazing fast. In addition, I made sure to follow performance best practices setting srcset and sizes information on images, subsetting fonts and serving up optimized file formats, concatenating and minifying all CSS and Javascript.

Cumulative Layout Shift

One challenge I faced regarding performance was acheiving a 100 on Lighthouse due to a less than ideal cumulative layout shift (CLS), the visual stability measurement that helps identify unexpected layout shifts. This is an important metric to track because layout shifts that occur during the lifespan of the page can cause items to shift around for users. This can be especially annoying and sometimes downright disorienting when they are reading text, focusing on an image, or watching a video. Even worse, they could be attempting to interact with something on the page and inadvertently select something else by accident.

Many of the layout shifts throughout the site were resolved by ensuring styles associated with anything that’s visible at the top of each page is inlined into the <head> of the page. This ensured that critical styles are applied as soon as possible, minimizing the jump that occurs to elements once the full CSS file is loaded and parsed. The subtle background graphics on each page were also affecting the CLS score, even though they are absolute positioned. I managed to resolve this issue by continuing to position the parent element absolutely, but positioning the individual elements via CSS transforms instead setting top or left values.

Enable Offline Browsing

Another primary goal with this redesign was to ensure the website would met the criteria for being a progressive web app (PWA). This means the site is not only fast and reliable, but can saved to homescreen and even viewed offline. The offline viewing part was especially important here because it ensures the content that visitors have viewed is saved in the background and still available if connection is disrupted or unavailable.

Service Workers are quite powerful scripts and can enable quite a lot of really handy features such caching content for improved performance, caching content for offline viewing, and more. They can also be a bit tricky to work with. I found this article on the Google Developers blog quite handy for wrapping my head around caching files with service workers.

Refactor Develop Tooling

The first version of the website was built using a combination of Nunjucks for templating, Sass for CSS preprocessing, and bringing it all together with Gulp for task automation. This all worked fine but I’ve come to really appreciate Hugo and it’s baked-in asset pipeline to simplify my development workflow. The redesign was an opportunity to rebuild the website with Hugo and therefore consolidate more projects I manage under a single stack; minimizing the cognitive load I take on each time I need to update something on the website.

By embracing static site generators, dropping Sass in favor of (Post) CSS, leveraging Hugo’s asset pipeline features, deploying with Netlify and augmenting my builds with Netlify Build Plugins, I’ve managed to significantly reduce the decisions needed to spin up a working environment and be productive in each development session. This change has given me the ability to focus on delivering the best possible user experience by removing the complexity debt that often times becomes a focus during the development process.

Expand Content

The intial release of the website in 2018 featured 8 heuristics. Since this time, it’s grown to 21 as I continue to add and update content. The redesign provided an opportunity to create a proper space for some new items.

Book

In April 2020, I published a book based on this project with O’Reilly Media. The book provides an accessible introduction into the psychology fundamentals that have a direct influence on design and how people process and interact with the interfaces we create. It’s full of examples and intended to be easily read and referenced by designers who wish to incorporate this information into their daily work. I wanted to be sure to have a dedicated space on the redesigned website to highlight this book because I’m not only proud of it, but also because it provides a great path for diving deeper into many the concepts included on the website.

Image of the Laws of UX book

Store link

In addition, the request for larger prints available for purhcase has been in the back of my mind for a while, so I launched an online store at the end of last year to provide these. I’ve included a link to this store via the header to ensure folks know where to go to find these posters if they’d like to purchase one. One of my favorite things about Laws of UX is the photos that folks share with me featuring the posters available via the website prominently displayed on office walls. I’ve always hoped these posters would help to inform design decisions, guide feedback and discussion, and promote an awareness on the intersection of psychology and UX design in general.

Measuring Success

In order to measure the success of many of the goals above, I leveraged Lighthouse to determine if I was meeting criteria specific to performance, accessibility, best practices and enabling offline viewing. Lighthouse is pretty fantastic because it integrates right into my exisitng development tooling (Chrome developer tools) and provided additional information related to flagged items. To top things off, it even provides a nice easter egg once you manage to get 100 across the board.

Screenshot from the Lighthouse report for Laws of UX

I’m happy where things landed with this redesign and I hope those that visit the updated website are as well. As with all things, change is good and this redesign is an effort to keep Laws of UX evolving and improving to ensure it remains a valuable and efficient resource for designers. I look forward to hearing thoughts and feedback on the all new design!

View the all new Laws of UX

UX Psychology: Google Search

Thu, 06 Aug 2020 07:18:48 -0400

In this series, we’ll take a look at various digital experiences and examine each by dissecting it step by step to identify relevant heuristics and concepts rooted in psychology. Kicking the series off will be Google Search — the ubiquitous utility that helps countless people find information in the vast expanse of the Internet every day. We’ll begin with the landing page and the process of searching before moving on to search results. Let’s begin!

Landing Page

Google’s landing page has only slightly changed in the 21+ years of its existence. The purpose of this page has remained singularly focused: provide a quick and easy way for people to search the Web. In fact, it’s done this so efficiently that the act of searching the web has become synonymous with the company name. A major contributor to the success of Google Search is its simplicity. The page consist primarily of a search input that’s positioned in the approximate center and is focused by default — ready to receive a search keyword. Once you begin typing, a list of predicted keywords based on what you’ve typed thus far appear below in input. This list of predicted keywords continues to update as you type and is designed to surface the keyword you’re likely to type before you’ve finished, therefore saving you keystrokes (and mental energy).

Google Search predictions

UX Psychology

A key psychology heuristic in play on the landing page of Google Search is Hick’s Law, which states that the time it takes to make a decision increases with the number and complexity of choices. Google keeps the decisions required to enter a keyword to a minimum by eliminating any additional content that could distract from the act of typing a keyword or require additional decision-making. The design reinforces this single goal of keeping the page focused on the act of searching by prominently placing the search input, auto-focusing the search input by default and stripping away additional search options. Hick’s Law is once again demonstrated as you begin typing and predicted keywords appear, eliminating the need to spell out the entire word (assuming a match is found). Google’s goal is to initiate search based on a search query as quickly as possible and it supports this goal by removing any friction that could lead to additional decision-making.

Search Results

The next step in Google Search is the search results page, which displays results it found based on your search query. The original search keyword is displayed prominently at the top of the page, along with additional options for filtering the results. Results are presented in a list and each one is visualized as discernible chunks of content that’s separated by ample spacing, so it’s easy to differentiate one result from the next. When appropriate, this page will also show a definition for the search term at the top of results as well as a sidebar card that links to more information regarding the term (typically on Wikipedia).

Google results page

UX Psychology

Hick’s Law is also carried into the search results page from the previous page. This is where you’ll find additional options for modifying your search, not on landing page where the goal is to remove as much friction as possible. It’s only once you’ve entered a search query that the additional options to filter the results and therefore additional decisions are made available.

Another important design feature to point out on the search results page is that the original search query is still being shown, which is helpful due to the way our minds store information in memory. Working memory is the cognitive system that holds information temporarily and is important for reasoning and the guidance of decision-making and behavior. It’s limited in capacity, so the more decisions being made means the less likely we are to quickly remember items that previously set in working memory. You can think of each item on the page as being a potential decision point: people scan the page in search of information that relates to what they’re looking for, and mentally evaluates if the content resembles something that could help them achieve their goal. Regarding Google Search, it’s helpful to see the original search term in the case that they forget what was originally being searched.

The next important key detail of Google Search is performance. Google Search is known for its speed in delivering results based on a query — it even displays the time in which it took to fetch those results at the top of the page. This directly relates to the Doherty Threshold, which states that productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other. If the search results took a long time to return, it’s possible you could begin to think of something else. Instead, Google priortizes performance and returns the results as rapidly as possible. As a result, it ensures we are remaining focused on the task at hand and we have the results we need to learn more. Performance is a critical part of the overall user experience and Google understands this.

Detail view of the search results page

Now let’s move on to the visual aspects of the search results page, which is optimized for scannability. As was already mentioned, each result is presented in a list and each one is visualized as a discernible chunk of content with ample spacing between other results. This not only makes it easier to differentiate one result from the next, but it also helps people quickly scan the results and identify which result is most likely to contain the information they’re looking for. The hierarchy of information in each result is clear, consistent and also lends itself to being easily scannable. This is closely related to the psychological concept of chunking, a process by which individual pieces of an information set are broken down and then grouped together in a meaningful whole. When applied to UX design, chunking helps to guide how we group and organize content. When we chunk content in design, we are effectively making it easier to comprehend. People can then scan the content, identify the information that aligns with their goals, and consume that information in an effort to achieve their goal.

By structuring content into visually distinct groups with a clear hierarchy, we can align the information we present with how people evaluate and process digital content.

Lastly, it’s impossible to dissect visual information without recalling Gestalt psychology and Google Search results demonstrates quite a few. One very noticeable Gestalt law in effect is the Law of Proximity, which states that objects that are near, or proximate to each other, tend to be grouped together. The spacing between each result contributes to the overall scannability of the page but also helps to effectively group each result as a related cluster of information. Additionally, the Law of Uniform Connectedness can also be seen with the border that surrounds specific items such as videos and ‘featured snippets’. This border helps to visually connect the content and also separate it from other results by giving it a bit more priority. It’s an additional layer of hierarchy on the page that helps once again with scannability.

Google Search has been incrementally refined over it’s 21+ years of its existence in order to optimize people’s ability to quickly get information based on a search keyword. It has achieved this by eliminating friction, prioritizing performance and ensuring results are easily scannable. They’ve refined this experience to a science and as a result have made Google Search the ubiquitous utility that helps countless people find information in the vast expanse of the Internet every day.

Simplified Development Workflow

Mon, 27 Jul 2020 07:07:20 -0400

The web platform has grown in complexity over the years and with it the complexity in the tools we use to build for the web. Tools like Gulp and Webpack are intended to make our life easier but also introduce a significant amount of tech debt that must be managed and maintained over the lifecycle of a project. Don’t get me wrong: I’ve always enjoyed the conveniences that task runners and module bundlers have to offer, but I also feel a bit overwhelmed by the configuration they require, the diligence needed to maintain it, and the mental energy it takes to be productive during each development session.

As a result, I’ve found myself valuing simplicity in my development workflow more and more over the years. This article explores how I’ve managed to significantly reduce the decisions I need to make in order to spin up a working environment and be productive by embracing tools that have made my developer experience simpler without the complexity debt.

This article details vital parts of a starter project I’ve made called Hugo Starter Project, which is available via Github. It’s a fork of the Hugo starter project Atlas by Indigo Tree with the addition of tooling and conveniences I use often.

Static Site Generator

Static Site Generators (SSGs) offer a host of advantages when it comes to a simpler development experience. There’s no monolithic architecture or database to manage — the HTML is build from Markdown files with reusable templates files providing structure. Additionally, authoring Markdown content files feels like a breath of fresh air in comparison to writing verbose HTML or building out custom fields in Wordpress.

I’ve experimented with a few SSGs but Hugo has remained by go-to for a few reasons. Firstly, it’s blazing fast. It clocks in at around <1ms per page, so the average site builds in less than a second. This means no more waiting for your pages to build each time you save. Secondly, it comes with an asset pipeline baked right in (more on this later). When it comes to simplicity, there’s something really nice about not needing to configure a build process for each project that leans heavily on a build tool like Grunt or Gulp. Lastly, it comes with the ability to spin up a local server and live-reload that server when changes are detected. This is typically something I’d have to setup with a task runner, but in Hugo it comes baked in.

Hugo homepage

There are lots of options when it comes to static site generators. If you want to start using one but aren’t sure which is the best for your needs, StaticGen is a great resource for seeing a high-level comparison between the most popular SSGs.

Plain Old CSS

CSS has evolved quite a bit over the last couple of years. Features such CSS custom properties, flexbox, grid, calc() and it’s ability to calculate multiple units, and functions like min(), max(), and clamp() all have dramatically enhanced the capabilities of native CSS. For me, this has slowly eliminated the need for CSS pre-processors like Sass. Authoring styles in CSS after using Sass for a long time feels lighter and simpler. I can feel confident that these styles are future-proof and don’t require tools to process it into CSS. For me, the less that can break in the future is a win because many of my projects are continuously maintained over serveral years.

Sass was the hare. CSS is the tortoise. Sass blazed the trail, but now native CSS can achieve much the same result.

Jeremy Keith, Sass and Clamp

That being said, there’s a few conveniences I’ve come accustomed to that Sass supports natively and CSS does not. Features such as the ability to break styles into separate files and concatenate them on build, nesting styles, and mixins have helped me become more efficient when writing styles. Luckily, Hugo is once again here to help. As of version 0.43 Hugo comes with Hugo Pipes, a built-in set of asset processing methods. Support for PostCSS and Sass comes baked-in, as well as file concatenation on build via the @import statement in your main file.

I use Hugo Pipes to run the PostCSS plugin Autoprefixer, which parses CSS and add vendor prefixes to CSS rules using values from Can I Use. I also leverage the built-in ability to minify the output file and fingerprint it to allow for cache busting. This covers a significant amount of what I would have used a build tool like Gulp for in the past, amounting to additional complexity and dependencies to configure and manage. With a built-in asset pipeline, it’s trivial to chain tasks as needed.

There are many more PostCSS plugins available to help augment your CSS workflow. My favorite place to search for them is the searchable catalog PostCSS.parts.

Styles

To process CSS with Hugo Pipes, you’ll need to call resources.Get on the CSS file that’s saved in a variable. The next step is to pass that variable into the href attribute along with .Permalink appended to the end. Also note that I’m chaining a series of actions within the variable to (from left to right) process CSS/Sass and combine the various files into one, run PostCSS plugins, then minify and fingerprint the file. The templating required to transform and manipulate CSS or Sass is simple, configurable, and happens where you’d normally load your stylesheet in the <head> of the page — no more dealing with asset concatenation and transformation in a separate configuration file (PostCSS plugins being an exception).

{{ $s := resources.Get "css/app.css" | toCSS | postCSS (dict "config" "postcss.config.js") | minify | fingerprint }}
<link rel="stylesheet" href="{{ $s.Permalink }}" />

Postcss Config

In order to use PostCSS plugins (e.g. Autoprefixer), you’ll need to have a config file in the root directory. This configuration file gets called by referencing it in our resources.Get statement above (postCSS (dict "config" "postcss.config.js")). Here’s a closer look at what my typical configuration looks like:

module.exports = {
plugins: [
require('autoprefixer')({
browsers: ['ie >= 8', 'last 3 versions']
})
]
};

Image Processing

Another task that can quickly complicate a build process is image processing. Whether it’s creating an array of sizes, optimizing each image size, or configuring a template to include them on a page can take quite a bit of time. Once again Hugo comes to the rescue with baked-in image processing. With Hugo pipes, creating different image sizes, cropping images, automatically optimizing file size and referencing images with paritials or shortcodes becomes a trivial task. Hugo Pipes gives us the ability to easily do tasks we’d usually have to configure through a build process, which can quickly get lengthy if you’re working with different image sizes, etc.

Image Shortcode

I usually set srcset and sizes attributes on images in order to ensure an appropriately sized images are served. In order to do this, I leverage a shortcode that takes a name and ‘alt’ value, then creates the various sizes I need. Hugo also optimizes the images it generates and can crop them if you’d like (handy for the art direction responsive image use case). Check out the Hugo docs to learn more about Hugo’s image processing capabilities.

{{ $src := $.Page.Resources.GetMatch (print (.Get "src")) }}
<img
sizes='(min-width: 35em) 1200px, 100vw'
srcset='
 {{ ($src.Resize "800x").RelPermalink }} 800w,
 {{ ($src.Resize "1200x").RelPermalink }} 1200w,
 {{ ($src.Resize "1920x").RelPermalink }} 1920w'
src='{{ ($src.Resize "1200x").RelPermalink }}'
loading='lazy'
alt='{{ with .Get `alt`}}{{ . }}{{ end }}'>

Once your shortcode is setup, you can call it from within your content files by passing in the name and alt text for the image you’d like to generate like so:

{{< image src="detail.jpg" alt="Laws of UX book detail" >}}

An important note to make here is that Hugo requires images to live in the same directory as your content markdown file when referencing images via the method shown above. I’ve found the ability to group content and assets together quite nice because it eliminates the separation across directories. If you’re interested in learning more about Hugo page bundles I recommend checking out the docs.

Javascript

Much like CSS, Javascript can grow to the point that breaking it up into smaller chucks make sense due to size and complexity. Hugo pipes not only enables me to concatenate JS files, but also to minify, fingerprint and create sourcemaps. If I need external plugins, I can install them via NPM and include them in my JS bundle. This allows me to manage dependencies in one place, while also allowing for items in my node_modules folder to be available in my project.

Scripts

Processing Javascript files with Hugo Pipes is as simple as assigning each file to a variable, adding them to an array and then concatenating them into a bundled file.

{{ $pluginjs := resources.Get "js/plugin.js/dist/plugin.js" }}
{{ $mainjs := resources.Get "js/app.js" }}
{{ $scripts := slice $pluginjs $mainjs | resources.Concat "js/bundle.js" | minify | fingerprint }}
<script src="{{ $scripts.Permalink }}" integrity="{{ $scripts.Data.Integrity }}" media="screen"></script>

Hugo also enables you to split your JS into bundles if you’d have conditions which require some pages to get different scripts. For more information, check out the Hugo javascript bundling docs.

Hugo Config

Hugo Modules allows you to import and configure almost anything into your project. In order to include NPM scripts into your bundle, you’ll need to first copy over the script via module.mounts. Once this is set, you can include the file in your JS bundle like any other file.

[module]
[[module.mounts]]
source = "./node_modules/plugin.js"
target = "assets/js/plugin.js"
[[module.mounts]]
source = "assets"
target = "assets"

Here’s a tip that might save you some time: when adding a mounts section, I’ve found it necessary to also declare the assets directory. Otherwise, you’ll receive an error that will prevent your site from building.

Extending the Tools

Hugo Pipes handles most of my use cases when it comes to build tooling but there are often times when I need to extend it. For example, one task I commonly include in all of my projects is to take a collection of SVG files, and combine them in order to build an SVG sprite. To achieve this, I install svgstore-cli, specify where it can find my individual SVGs, where it should output the combined SVG sprite, and when it will run in relation to the overall build process. This can be repeated for any number of tasks you’d like to add that isn’t covered by Hugo Pipes.

package.json

In order to use NPM as a build tool, you’ll need to install the dependency as normal via NPM, then call it in the scripts section of your package.json file. As you can see below, I’ve installed the svgstore-cli tool, then created a build:icons task that will run the tool along with any options I pass it. The next step is to run the build:icons task, which I do by leveraging the pre hook to build my SVG sprite file before the start and build tasks runs.

{
"scripts": {
"prestart": "npm run build:icons",
"start": "hugo server",
"prebuild": "npm run build:icons",
"build": "hugo && npm run build:functions && hugo --minify",
"build:icons": "svgstore assets/svg/**/*.svg > static/sprite.svg --inline",
"build:functions": "netlify-lambda build assets/lambda",
"server": "hugo server"
},
"dependencies": {
"svgstore-cli": "^2.0.0"
}
}

Netlify

The final piece of my workflow is deployment, which is made incredibly easy thanks to Netlify. By connecting your Github repo with your Netlify account, you’ll get automatic deployments each time you commit changes. Not only are your deployments configurable, but you extend the functionality of the Netlify Build process with Build Plugins.

Netlify Build Plugins directory

Build Plugins are great because they enable you to perform additional tasks on your project after each build. Tasks such as running accessibility checks, running performance testing, optimizing images and SVGs, building and inserting critial CSS, and even visual diffing are all one button press away. Not only that, but you can write your own, save them locally in your repository, or share them with others via npm and the Netlify plugins directory. I’ve found that extending by build process with Build Plugins helps me to augment my development workflow without the overhead of configuring additional tooling.

As much as I like exploring new tools, I’ve come to really appreciate simplicity when it comes to my development workflow. By embracing static site generators, dropping Sass in favor of CSS, leveraging Hugo’s asset pipeline features, deploying with Netlify and augmenting my builds with Netlify Build Plugins, I’ve managed to significantly reduce the decisions needed to spin up a working environment and be productive in each development session. This gives me the ability to focus on delivering the best possible user experience by removing the complexity debt that often times becomes a focus.

To further reduce the friction that comes with starting a product and configuring the build tooling, I’ve created a Hugo starter project that’s available via Github. It’s a fork of the Hugo starter project Atlas by Indigo Tree with the addition of tooling and conveniences I use often. Feel free to clone it and use for your own Hugo projects and enjoy the simplified development workflow without the complexity debt.

References

Peak-End Rule

Mon, 20 Apr 2020 00:00:00 +0000

A closer look at how our feelings during the most emotionally intense moments and at the end are averaged in our minds and heavily influence how we assess an overall experience to determine if we’d be willing to do it again or recommend it to others.

Read Article on UX Collective

Laws of UX: The Book

Mon, 13 Apr 2020 00:00:00 +0000

Over the past year, I’ve been working hard on a book that expands on many of the principles from my website Laws of UX. Today, I’m happy to announce that this book is available on Bookshop, Amazon and Barnes & Noble for pre-order, and a digital version is available now on O’Reilly Online Learning. In this book, I deconstruct familiar apps and experiences to provide clear examples of how UX designers can build experiences that adapt to how users perceive and process digital interfaces.

Description

An understanding of psychology—specifically the psychology behind how users behave and interact with digital interfaces—is perhaps the single most valuable nondesign skill a designer can have. The most elegant design can fail if it forces users to conform to the design rather than working within the “blueprint” of how humans perceive and process the world around them. This practical guide explains how you can apply key principles in psychology to build products and experiences that are more intuitive and human-centered.

What you’ll learn

How aesthetically pleasing design creates positive responses
The principles from psychology most useful for designers
How these psychology principles relate to UX heuristics
Predictive models including Fitts’s law, Jakob’s law, and Hick’s law
Ethical implications of using psychology in design
A framework for applying these principles

Details from the book

Where you can find it

Bookshop, which financially supports local, independent bookstores
Amazon
Audible
Barnes & Noble
O’Reilly
O’Reilly Online Learning
Google Play
Target
Books-A-Million
IndieBound
Kobo
OnBuy

Translations

If you’ve found value in the Laws of UX website then this book is for you. It’s an accessible introduction to the psychology fundamentals that have a direct influence on design and how people process and interact with the interfaces we create. It’s full of examples, and intended to be easily read and referenced by designers who wish to incorporate this information into their daily work.

Presentation: Humane Design Patterns

Sat, 21 Dec 2019 00:00:00 +0000

Throughout the past year I’ve given a variant of a UX-themed talk called Humane Design Patterns. I gave this talk a number of events and conferences, which are listed below.

Abstractions II (Video)
Midwest UX (Video)
Detroit UX
NAGW National Conference

Summary

The exponential growth of mobile technology has ushered in an age where time and attention is an increasingly scarce resource. Instead of technology enhancing our abilities as humans, we’ve seen it become a vehicle for extracting our attention, monetizing our personal information, and exploiting our psychological vulnerabilities. As designers, we play a key role in the creation of such technology, and it’s time we take responsibility for the impact that these products and services we build are having on people it should serve.

In this talk, I focus on the guiding principles I’ve outlined in my recent project Humane by Design. I explore various UX patterns that designers can use that consider user well-being, as well as the ultimate benefits of designing humane products and services.

You can view the slides from this talk here.

The Psychology of Design

Fri, 05 Oct 2018 00:00:00 +0000

Designers can leverage psychology to build more intuitive, human-centered products and experiences. Instead of forcing users to conform to the design of a product or experience, we can use some key principles from psychology as a guide for designing how people actually are. But knowing where to start can be a challenge. Which principles from psychology are useful? What are some examples of these principles at work? In this article, I cover the basics and discuss the ethical implications of using psychology in design.

Read Article on A List Apart

Presentation: Psychology of Design

Fri, 09 Mar 2018 00:00:00 +0000

Throughout the past year I’ve given a variant of a UX-themed talk called Psychology of Design. I gave this talk a number of events and conferences, which are listed below.

Summary

The human brain is so complex that understanding it has proven to be arguably the greatest challenge of modern science. It exhibits patterns that are integral to how we perceive and process information, which we’ve evolved for survival over thousands of years. An understanding of these patterns is fundamental to designing human-centered experiences, and we can use established principles from psychology to guide us. Instead of forcing users to conform to the design of a product or experience, we can use this knowledge to design for how people actually are.

In this talk, I’ll take a look at how designers can leverage psychology to build more intuitive, human-centred products and experiences. I share my project Laws of UX and show how we can use some guiding principles from psychology to design for how people actually are, examine several examples of these principles in action, and explore how these principles relate to ethics and design decisions.

You can view the slides from this talk here.

Effective Design Feedback

Mon, 04 Dec 2017 00:00:00 +0000

Most designers know the feeling of walking into a presentation feeling confident and expecting sign off on their work, only to walk away with a mountain of edits. Even worse is the realization that we missed the mark and will need go back to the drawing board.

But the truth is critical feedback is a fundamental step in creating good design. The ability to give effective feedback and openly receive it in order to improve is a vital skill for designers. In fact, actively seeking and learning from feedback is the most effective way to grow as a designer.

The following tips will help to ensure we’re getting the most out of the feedback we’re provided, and that feedback we are giving is as effective as possible.

Receiving Critical Feedback

Start early

Good design isn’t art, it’s a solution that effectively and efficiently solves a business problem. And to solve the problem, a designer needs feedback early and often. Without feedback, there’s no way to know you’re heading in the right direction.

All feedback, even feedback that we don’t agree with, is an opportunity to see our work from a different perspective.

Seeking feedback early, even if the design is still in progress, is the best way to ensure we’re on track and can anticipate questions and concerns from our team and stakeholders later on.

Be open

The first thing we must remember is to be open to different perspectives. Design isn’t about self-expression—it’s about solving problems and making something easier to understand and use. That’s why having insight into how others might perceive our work is critical.

To do this, we need diversity of opinion, and this will only happen when we open up to feedback from our peers and from users.

Don’t just hear

There’s a difference between simply hearing feedback, and actually listening to it. Listening when others are providing feedback can help us identify areas in which our work can improve faster.

Why is that exactly you ask? It’s quite simple: listening allows us to see things from another point of view, and question our own assumptions.

Don’t be defensive

It’s important to remember that critical feedback isn’t a personal attack on our capabilities as designers. It’s purpose is to give us insight and allow us to think of our work from a different angle. By being defensive, we deny ourselves the opportunity to grow from the feedback being provided.

The result is our colleagues will be less likely to provide feedback in the future, or they might hold back to avoid our defensiveness.

Take it with a grain of salt

All feedback, even feedback that we don’t agree with, is an opportunity to see our work from a different perspective. It’s a dialogue centered on how to improve the design, not a mandate on what must change.

If we decide to not make revisions based on a particular point of feedback, it’s perfectly alright as long as we have a good reason for doing so.

Don’t mistake praise for feedback

While it can be self-gratifying to receive praise for our work, it doesn’t provide the critical analysis necessary for growth and improvement. Praise is typically superficial and only serves to validate design decisions, even if they are shallow or non-existent.

To exacerbate this issue, many social platforms that are popular with designers have a tendency to quickly devolve into praise networks. These networks only vindicate designers, as opposed to providing a network in which we can seek critical feedback.

Providing Critical Feedback

Frame your feedback

The most important thing to remember when providing feedback is to keep it framed within the context of the project’s goals. Shared goals help to align the team on intent by keeping design conversations focused and move things forward by making it easier to rationalize decisions within the team. They ensure continuity around the decision making process and keep the team aligned on what matters.

In order to receive critical feedback on our work, we must open ourselves up to opinions that we might not necessarily agree with.

When we provide feedback to others, it should always circle back to one or more design goals that the team has aligned on.

Be clear and concise

Feedback that isn’t clear or direct is less likely to be helpful, and can potentially set a project off in a bad direction. It’s important that we know how to articulate our feedback, and we have considered the implications of it.

Only then will feedback be clear and concise, which increases it’s helpfulness by making it more actionable.

Ask questions

Feedback that is too specific doesn’t give the recipient room to engage the problem, and the results are often less effective. A better approach is to ask questions that invite the recipient to reconsider their approach and solve the problem on their own.

Asking questions, as opposed to providing solutions, will ensure team members feel like respected contributors and enables them to do their job more effectively.

Be respectful and patient

In order to receive critical feedback on our work, we must open ourselves up to opinions that we might not necessarily agree with. For those whom are providing feedback, it’s important to remember this and to remain respectful and patient when providing feedback to our colleagues.

Doing this will allow the feedback process to be more effective, and ensure the recipient is more receptive to our opinions.

The benefits of actively seeking and providing design feedback are numerous. They not only enable us to identify problem areas in our work quickly, but also validate effective solutions. Most importantly, design feedback enables us to grow professionally and learn from our fellow designers.

The tips that we’ve covered on giving and receiving feedback will help to ensure we’re getting the most out of the feedback we’re provided, and that feedback we are giving is as effective as possible.

Balancing Data with Intuition

Mon, 30 Oct 2017 00:00:00 +0000

As designers, we know that data is key to understanding user behavior. It is powerful information that increases the effectiveness of our work when it’s leveraged in the right places. Data can also be problematic if it is misinterpreted or teams become over-reliant on it. We must understand it’s advantages without allowing it to dictate our decisions, and to do this we need to balance data with intuition.

Where Data Exceeds

Data is great at a lot of things, specifically the things that humans aren’t as good at seeing. Here’s a few common ways we leverage data to help inform our design decisions:

User Testing

User testing is a fundamental part of the design process. Whether it’s usability test, card sorting, click test, or any other exercise, we leverage this data to validate the effectiveness of our design decisions. Data from user testing helps us validate design decisions and anticipate potential issues or bottlenecks so that we can then optimize our designs.

Analytics

Analytics are a key ingredient that gives us a benchmark for our design decisions. Not only do they allow us to identify how users actually interact with a product, but they allow us to identify patterns of behavior and issues that users might be having. This data can then be used to inform our decisions while we iterate on a design in order to address bottlenecks or simply validate what’s there is working.

Instead of treating data as a mandate, we must leverage it as the basis for more design iteration.

Best Practices

It’s part of our job as designers to know best practices. Not only should we understand why they exists in the first place, but also when and how to use them. Proven methods or techniques are considered a best practice only after consistent validation of results, and these results come from data.

Where Data Fails

While data excels in certain areas, it falls short in others. Here’s a few downsides when relying too much on data:

Data doesn’t tell the whole story

Data can provide us with helpful insight, but it can’t tell the whole story. As a simple example, let’s say your analytics indicate that users are dropping off on your product’s website before signing up. The data shows that they scroll halfway down the page and then back up to the top before leaving, but we need them to scroll to the bottom in order to find the sign-up form. Based on the analytics data avialable, we decide to move the sign-up form higher up on the page, and we walk away feeling confident that the problem is solved.

Soon it’s discovered that users are still not signing-up, despite seeing the sign-up form. It turns out the problem is actually how the product’s features are described, which lacks a clear value proposition for users. This simple example demonstrates how data can fail to tell us the whole story. In this case, it’s the message that’s being communicated — not the placement of the sign-up form.

Data is interpretive

While data is inherently non-subjective, there are a number of ways it can be manipulated. Firstly, the way user tests are constructed or conducted has the potential to skew the results. Secondly, how we interpret data can be skewed by our own subjective bias. Misinterpreted data can quickly lead to us solving problems that don’t exist or creating new ones unknowingly.

Data can become an obstacle

There’s a fine line between using the insight that comes from data to inform our design decisions, and data dictating our design decisions. An over-emphasis on data can become an obstacle in two ways: 1) it can be interpreted too literally, or 2) stifle change altogether. Both of these result in data being treated as a mandate, instead of using it as a tool that informs our decisions. When everything must be validated with data, there’s little room left for intuition to guide designers to more innovative solutions.

Finding the Balance

The ability to synthesize information and make informed design decisions is a fundamental part of our job as designers. We must consider nuance and the human element in tandem with data—things like emotion, appropriateness, and accessibility must all be part of our design solutions.

When teams regard data as the ultimate deciding factor, they eliminate the power that intuition has to make these connections. Instead of treating data as a mandate, we must leverage it as the basis for more design iteration.

By identifying the ‘why’ with user behavior and then using our intuition to guide us, we can make better design decisions that account for the nuance of human factors that data cannot see. We should utilize data as a tool for guidance without allowing it to dictate our approach.

Be the Wolf

Sun, 08 Oct 2017 00:00:00 +0000

Fictional characters can sometimes inspire us professionally. Few have had more of an influence on me than Winston ‘The Wolf’ Wolfe, the charismatic fixer in Quentin Tarantino’s classic film Pulp Fiction. Played by Harvey Keitel, The Wolf is called upon to fix a messy situation in a hurry. He not only manages to get the job done, but he gets it done with grace and style. He’s the epitome of cool under pressure.

If you aren’t familiar with the film, or if you need a refresher, watch the video below and you’ll see what I mean. I’ve found that there’s a lot designers can learn from this no-nonsense master of performance.

Be reliable

Reliability is one of the most important characteristics any professional can have. The Wolf understands this: he states what he’ll do, when he’ll do it by, and then he delivers. He doesn’t over-promise or get cocky—instead, he collects the facts and then confidently states what’s doable.

Reliability is also vital in the role of designers. We must be dependable and deliver what is expected, when it’s expected. It only takes one time of falling short to dissolve other’s trust in your reliability, so it’s important to set expectations and then execute consistently.

Assess the situation

When faced with a complex task under a stressful deadline, it can be tempting to just dive in and sort things out as you go. More often than not, this ends up resulting in less efficiency and ultimately more work.

It’s important to always assess the situation by identifying stakeholders, defining roles, objectives, and any other information that will help you get a clear picture of what’s ahead. When you do this, you can make decisions that consider the problem holistically.

Stay calm, cool, and collected

The Wolf was called upon to fix the situation caused by Jules and Vincent, and it had the potential to go incredibly wrong: irritable stake holders, a very tight deadline, and a complex problem to solve. And if that wasn’t stressful enough, failure will result in jail time for everyone involved.

The job of a designer can often times be stressful, especially when faced with a tight deadline. The key is to stay calm, cool, and collected — and no one does this better than The Wolf. His unflappable demeanor assures everyone that the situation is under control, and that if they listen to him, they’ll get out of the circumstances they’re in.

Take notes

This is a simple takeaway, but nonetheless an important one. It can be hard to remember specific details when there are lots of moving parts. If you aren’t listening carefully and capturing notes, it’s almost impossible to account for everything that was discussed. Collecting notes on important facts and details is vital in recalling specifics later on, and it instills trusts in those that are depending on you to be effective. Not to mention, notes have a way of becoming great checklists for next steps.

Delegate if needed

The Wolf is quick to divvy up tasks after identifying the stakeholders, gaining a clear understanding of the goal, and accessing the situation in the car. He understands that the goal can’t be met if he attempts to do it himself — he must involve his team: Vincent, Jules, and Jimmie.

Part of what makes a good designer good is attention to detail. We want to see tasks completed with the level of attention that we’d give it, and this often leads to us taking on the tasks ourselves. The result is we stretch ourselves thin and lose sight of overall strategy because we are too focused on immediate tasks. It’s important to delegate tasks to your team members if needed and trust in their capabilities.

Prioritize

When The Wolf tells Vincent and Jules to clean the car, he gives them very specific instructions. The first priority is to put the body in the trunk. The next priority is to clean the car, but prioritize the cleaning of “the really messy parts”. The last step is to cover the upholstery in blankets provided by Jimmie, the gracious host.

A fundamental step in working smarter is to know your priorities. While this seems straightforward, it can be more difficult than it sounds. All too often, we confuse urgent tasks with important tasks, and we fill our task list with items that do not contribute to our long-term mission, values, and goals. The way to avoid this is to evaluate each task, determine it’s priority, and address the important items first.

Give clear direction

When The Wolf gives direction, it’s clear and concise. He doesn’t waste time elaborating on details that aren’t important, nor is he vague. His direction is crystal clear and to the point: Jules and Vincent are to stick the body in the trunk and clean the car fast, Jimmie is to get comforters and blankets that aren’t white, then Jules and Vincent are to camouflage the inside of the car with these comforters and blankets.

Providing clear direction saves time, and time is valuable. It provides an understanding of what is expected, why it’s expected, and when it should be completed. Those whom you are delegating tasks to will appreciate the clarity because it will save them time and energy, and reduces the possibility of needing to do the tasks again.

Be firm

The Wolf doesn’t stand down when challenged by Vincent—he is firm and states his objective. He makes it clear why he is direct and what the outcome of cooperating will be.

If I’m curt with you it’s because time is a factor. I think fast, I talk fast, and I need you guys to act fast if you wanna get outta this. So pretty please, with sugar on top, clean the fucking car.

Winston Wolfe

Whether it’s a design critique, client review, functionality discussion, or delivery timeline with project managers, there are many times that designers must also be firm. When this happens, remember to keep the conversation centered on the mutually shared objective of your team.

For example, you decided to cut the image slider at the top of your product’s sign-up page in order to streamline user conversion. Marketing isn’t happy about this because they liked those images, but the images did very little to encourage user sign up. In this case, the designer should stand their ground, but do it in the context of streamlining the mutual objective, which is increasing user sign up.

Be empathetic

The Wolf understands that he must empathize with his stakeholders. In this case, it’s Jimmie and the explosive result of his wife returning home before Vincent and Jules are gone. He immediately confirms the facts: there’s a corpse without a head in the garage, Bonnie is to return in forty minutes, and she would be very unhappy to find them still there.

Later, The Wolf generously compensates Jimmie on behalf of ‘Uncle Marsellus’ for offering up his best linen that was a wedding present from his deceased Uncle Conrad and Aunt Jenny. He reassures Jimmie that his family members would understand given the situation.

The key here is that despite the stressful circumstances, The Wolf understands that empathy is the key to gaining the trust of his stakeholder. He recognizes the sacrifice being made by Jimmie, and offers up a sacrifice of his own. Lastly, he provides some logical reassurance to ease the concerns of Jimmie.

Designers must also know how to empathize with both our stakeholders and users. Understanding their concerns is key to providing a solution that effectively solves the problem they face.

The Wolf Checklist

Here’s a checklist for steps to gain control of any given project or ‘situation’:

Introduce yourself
Identify your stakeholders
Confirm the facts
State the roles and objectives
Assess the situation
Identify risks
Prioritize tasks
Get to work and delegate if needed
Have a backup plan

Things I’ve Learned in 10 Years of Design

Mon, 25 Sep 2017 00:00:00 +0000

Ten years of design is a milestone, so I’d like to take the opportunity to reflect a bit. During my short career as a designer, there’s been occasions where I’ve learned something that you just aren’t taught in school. Some of these lessons are common-sense, while others are very specific to an experience. These are by no means all the things I’ve learned, but are some of the most important ones.

I’d love to share them with you in the hopes that you can take away some useful advice.

Give a shit

This one is especially important because if you don’t care, the work will suffer. And when the work suffers, you give Design a bad rap within your organization. It makes it harder for designers that do give a shit to be taken seriously.

Learn to shut up

Take in the information around you, make note of what’s being said, and listen for the things that aren’t being said. It’s amazing how much we miss when we’re just thinking about the next thing we want to say.

Feedback is an essential part of Design

Don’t get precious

Criticism about your work isn’t criticism about you as a designer, period. Don’t go on the defense the second you receive feedback that you don’t agree with. In fact, try to leave the ‘you’ out of it altogether — it’s about what’s right for the user. Being precious about your work will only prevent you from remaining flexible and open to alternative solutions.

Always add more whitespace

Whitespace is a transformative design element: the more you add, the better a design can feel. Be prepared to add more whitespace (or reduce elements in favor of it) than you’re comfortable with. You won’t regret it.

Burnout is the enemy

Burnout kills productivity and the ability to be an effective problem-solver, which is kind of important to a designer. It’s in your best interest, and the best interest of your employer, for you to protect yourself from burnout. Do whatever it takes.

Some projects suck. But…

Look—everything can’t be a Dribbble shot. It’s important to treat every project as an opportunity to learn something new. Sometimes that means finding the one thing about it that interests you, and make it the best you can.

Good solutions come as a result of good process

There, I said it. No good process, no good design. You don’t get to an effective solution that solves a real problem by just going willy-nilly.

Design is a discipline, not a hobby

Design is about much more than making things look pretty— it’s about solving problems. You need process to solve problems, and process requires discipline. And like any discipline, you must practice — every, single, day. You’ll never be a good designer if design is just a hobby for you.

Remember that design software is just another tool

I know everyone has their own way of working, blah blah blah. But if the first thing you do when starting a design is launching [insert flavor of the week design software], then you’re doing something wrong. Don’t let your design software become a crutch.

When you fail

There will be times when you miss the mark, and it will feel horrible. When this happens, remember that it’s just an opportunity to learn. Oh, and also remember that it’s time to bust your ass and make it right.

Learn to write

If there is one piece of advice I could give to a young designer, it would be to write. Write about the problems you’re solving, write about what inspires you, write about your opinions. This will not only help you clarify your own thoughts, but it increases your ability to articulate problems, solutions, and results.

Whether you just starting out, or you’re a seasoned veteran of Design, it’s important to always be learning from your professional experiences. I’ve shared with you some of my lessons learned during ten years of design, and I hope you found some valuable information in there.

Designing with Occam’s Razor

Mon, 11 Sep 2017 00:00:00 +0000

Complicating the simple is commonplace in web design — even the experienced designer will find themselves reaching for an overly complex solution from time-to-time. It’s easy to get carried away with details that we assume will enhance the user’s experience, when in reality they have the potential to distract and confuse them. The challenge is to make the complicated simple, and to do this we need a guiding principle; one that can cut through complexity and guide our decision making process.

The Principle

Occam’s Razor is a problem-solving principle attributed to William of Ockham, an English Franciscan friar and scholastic philosopher and theologian during the Medieval period. The name derives from Ockham’s surname plus ‘razor’, which refers to the distinguishing between two hypotheses either by shaving away unnecessary assumptions or cutting apart two similar conclusions. It states that among competing hypotheses that predict equally well, the one with the fewest assumptions should be selected.

Ockham didn’t invent “the razor”, but he used it to great extent in his own work. The principle has since been applied in a number of fields that include science, biology, medicine, probability theory and statistics.

Applying Occam’s Razor

So what does this have to do with design? The answer lies in a modern interpretation of Occam’s Razor: “Entities must not be multiplied beyond necessity”. When applied to our work as designers, Occam’s Razor can be adopted as a guiding principle that informs our decisions and keeps us from reaching for a complex solution when a simpler one is sufficient.

By only introducing complexity when it is necessary, we can ensure that our designs stay lean and void of superfluous elements that do not add value to the user’s experience.

Keep It Simple

One way to leverage the principle of Occam’s Razor is evaluate each and every design element based on it’s necessity. We must constantly ask ourselves when designing: “What is the minimum amount of UI that will allow the content to best found and effectively communicate to the user?”. It’s easy to make the mistake of thinking that you‘re enhancing the experience by sprinkling in delightful animations or hiding away navigation in an offscreen menu. The reality is you might be introducing unnecessary complexity that potentially can become an obstacle.

While there’s techniques for reducing design complexity, the best approach is to avoid it in the first place. The key is to start with the simplest solution and only introduce complexity if needed. Our UI should reinforce the content message, eliminate any barriers, and not impede the ability to traverse the content.

Good design is as little design as possible.

Dieter Rams

Edit Ruthlessly

Another way to apply the principle of Occam’s Razor is to be aggressive when editing your work. Every design element and pattern should be evaluated on it’s effectiveness, and edited if a simpler solution exists. If it doesn’t have meaning or provide value, it should be altogether removed.

The most effective method I’ve found for evaluating my work is through design critiques. These iterative sessions provide an opportunity to initiate discussion and get feedback on design decisions from your peers. They force us to articulate why we made specific design decisions, and in the process strengthen our work by identifying spots that aren’t as clear or effective.

Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.

Antoine de Saint-Exupéry

This simple principle can help to inform our design decisions and keep us from reaching for a complex solution when a simpler one is sufficient. By shaving away complexity, our designs will have clarity and be more impactful. Users will appreciate that you’ve eliminated obstacles and streamlined the interface, allowing for them to find what they need faster and more efficiently.

Flexible Design Consistency

Tue, 22 Aug 2017 00:00:00 +0000

Consistency is a core principle of good design. In UX and UI design, it is paramount to a good user experience because it provides familiarity, strengthens the intuition of the user, and establishes the identity of the brand. In addition, consistency can save design time through the reuse of components or patterns, and enable a design system to scale and adapt with ease.

Without consistency, an interface will feel disjointed and cheap, which results in the erosion of trust in the brand or service. There’s also technical drawbacks: design systems that lack consistency are difficult to maintain or scale, and are more likely to be refactored or discarded.

But design consistency requires discipline. As graphic design legend Massimo Vignelli said in his manual The Vignelli Canon:

Discipline is a set of self imposed rules, parameters within which we operate. It is a bag of tools that allows us to design in a consistent manner from beginning to end. Discipline is also an attitude that provides us with the capacity of controlling our creative work so that it has continuity of intent throughout rather than fragmentation.

It can be all too easy to reach for a one-off solution to solve a design problem, instead of relying on an established system to provide a solution. One-off solutions quickly become hard to manage in relation to the design system as a whole, and this results in fragmentation over time.

As designers, we must constantly ask ourselves “what solution best fits the content, while leveraging the design system in place?”. The challenge is to maintain consistency over time, while remaining flexible enough to accommodate changes or additions to the design system.

There needs to be some flexibility in how the design system is managed and evolved — consistency should not come at the expense of innovation.

We can achieve this balance by defining design principles, creating a style guide, and adopting flexibility as a core part of our process.

Design Your Principles

Design principles are specific guidelines created by the design team to help with generating and evaluating design ideas and artifacts. They are invaluable for aligning the team on intent, keeping design conversations framed, and helping to move things forward by making it easier to rationalize decisions within the team. This helps ensure continuity around the decision making process, and keeps the team aligned and focused on what’s important — both to the organization, and to the user.

Without a prioritized list of concise principles, design decisions within an organization can become a struggle, and ultimately will affect the output of the team.

Recommended Design Principle Resources

Here’s a few design principle resources I find myself referencing frequently:

Create a Style Guide

Style guides are a critical step in documenting the design system for the whole organization. They can be comprised of anything that helps in the process of design at that organization, including the components and patterns that make up the design system. And much like the design system itself, style guides should be able to evolve over time—it’s living documentation of the system as it exist at that moment.

There are some great benefits to leveraging a style guide to document a design system. First, they allow us to define guidelines that inform when, where and how to use a particular component or pattern over another. Consistency is promoted through these usage guidelines and ensures the design system will continue to be used as the makers intended.

Secondly, style guides give us an aerial view of the design system as a whole. This perspective is invaluable for designers because it allows us to see where the system is strong, where it needs work, and how it functions as a whole.

Recommended Style Guide Resources

Here’s a few style guide resources I find myself referencing frequently:

Stay Flexible

Design principles and style guides are incredibly helpful for establishing design continuity, but they can also limit a team’s ability to innovate. A design system must be flexible enough to accommodate modifications or additions but rigid enough to scale. To achieve this balance, there needs to be some flexibility in how the design system is managed and evolved—consistency should not come at the expense of innovation.

Content can be evaluated by asking the following questions: 1) “can I leverage the existing design system to accommodate this content effectively?”, or 2) “do I need to create a new component or pattern to accommodate this content effectively?”.

Leveraging the Existing Design System

If your able to leverage the existing design system, then your job is easy and you can let the system do the work for you. You might find that a pre-existing component or pattern is close to what the content requires, but with some slight changes. These are pattern variations, and they are fundamental to the flexibility of a design system. It’s important to document variations within the style guide to have a sense for the flexibility of each component or pattern.

Adding to the Design System

If there’s no pre-existing component or pattern that fits your content, then it’s time to introduce a new pattern or component. The ability to evolve the design system is key to flexibility, but it’s important to evaluate each addition based on the following criteria: 1) “can I reuse this new component or pattern beyond this single use?”, and 2) “does this component or pattern make sense in the overall design system?”. If the answer is no to either of these, then the decision should be reevaluated and a more appropriate pattern or component should be used.

Each component or pattern should be created to be flexible enough to meet a variety of conditions. What if there is little to no content? What if there is lots of content? What if the content is in a different language? Can it be modified to fit extra elements? Planning for these variables will ensure it will endure longer as part of the design system.

Maintaining consistency over time while remaining flexible enough to evolve the design system is possible through defining principles, creating a style guide, and adopting flexibility as a core part of the process. This continuity will not only ensure the design process is more efficient in your organization, but will improve user experience by strengthening familiarity within your product(s).

Designer’s Guide to Flexbox and Grid

Thu, 27 Jul 2017 00:00:00 +0000

CSS has come a long way since its introduction in 1996, but the tools we have available for layout haven’t changed much. Table layouts were incredibly too rigid, float-based layouts were basically a hack, positioning-based layouts were not adaptable, and none could handle a great deal of complexity in an efficient way. Don’t get me wrong — these methods got us really far, but they aren’t intended for complex layout purposes.

The short-comings of these old methods for layout have become even more apparent with responsive web design, in which embracing the fluidity of the Web is fundamental.

With flexbox and grid, we finally have tools intended specifically for layout that are more efficient and void of hacks necessary with previous layout methods. They unlock new possibilities to old problems, enable things that weren’t possible before, and solve real problems we face with responsive web design.

Flexbox

Flexbox, aka CSS flexible boxes, is a new layout method that gives us alignment control that no other CSS method can produce. It excels at ‘micro layout’: the ability to align, order, and distribute space among items in a container, or alter an element’s width or height to best fill the available space.

Improved Wrapping

In Responsive Web Design, the width available varies as the viewport width changes sizes. This can lead to unintended content wrapping, especially when the content is longer than designed for, or the content’s container is too narrow. We’ve probably all seen before: the design accounts for the ‘ideal’ content length, but as soon as it’s implemented and real content is added, the content wraps to the next line because there wasn’t enough space or breaks out of its container. Both are not ideal, and can cause layouts to break.

The problem is not being sure the available space will always be large enough to accommodate content that can vary in length. Traditionally, we’ve used CSS Media Queries to adjust layout at specific breakpoints to mitigate issues with content wrapping. But Media Queries don’t take into account the length of the content itself — they respond to an explicit width or height. This often results in an excessive amount of media queries to control a specific piece of content at explicit breakpoints.

Flexbox Improved Wrapping

Flexbox solves this problem by enabling us to take advantage of the space available and then wrap content when it’s not. This auto-adjust behavior is not only convenient, but improves maintainability because we don’t have to rely on breakpoint to manually adjust the styling. The example above demonstrates this behavior: display the location label adjacent to the title if enough space is available, and align the location label to the left below the title if sufficient space isn’t available.

Traditional methods like floating would have resulted in the location label remaining right-aligned on smaller viewports, which is less than ideal. You could correct this by floating the label to the left at a specific breakpoint. The problem with this approach is now you are dependent on a breakpoint to change the styling of your content, which can vary in length.

Improved Spacing & Alignment

When it comes to spacing and alignment in CSS, we’ve had to get clever to accomplish anything that wasn’t the default behavior. Even effects that seem trivial can be tricky in CSS, like vertical alignment or evenly dividing space amongst items, must rely on workarounds or hacks. Some things are downright impossible to achieve.

Flexbox solves this by enabling the distribution of space between an unknown number of items within an area of unknown width 0r height, and align items on the X or Y axis. It works much like how design tools such as Sketch or Illustrator can control spacing and alignment, enabling the control we’d expect on the Web.

Example of improved space distribution with Flexbox

A great example of this control can be seen above: navigation items are evenly distributed, vertically centered, and the first and last item are flush to the edge of the navigation container. This would have been impossible using traditional methods such as applying inline block to items, or relying on table layout.

Source Order

Source order refers to the order in which elements are displayed on the page based on where they appear in the HTML. By default, elements will display from top to bottom and left to right by default — their width being determined by their display property.

The natural source order of the document should guide you when thinking about how your design will adapt to various viewport widths, but there are times when it’s useful to modify it in order to rearrange items. The only way to do this prior to flexbox was to hide the element and show another, resulting in duplicate HTML, or to rely on absolute positioning, which doesn’t always work when content can vary in size. With flexbox, you can simply modify the order of flex items without the need to modify the underlying HTML structure.

Example of item ordering with Flexbox

The example above demonstrates ordering in Flexbox: we display the logo on the left side of the footer, which is consistent with the header. On small viewports, we display the locations before the logo. This reordering makes sense because the locations are more important in this context.

Grid Layout

CSS grid layout is a two-dimensional layout system created specifically for the Web. It gives us the ability to divide the page into regions which can each be further defined in terms of size, position, and layer, resulting in an incredibly powerful native framework.

Fit for Purpose

CSS has never had a true fit for purpose layout tool, so we’ve had to get pretty inventive with how we can apply a grid to our work. Grid frameworks have emerged to fill this need, but not without introducing their own problems. Many of the most popular grid frameworks require layout definition in the markup, which can lead to code bloat, maintainability issues, and blurs the separation of document structure and presentation.

With grid, we no longer need a grid framework—it’s a native framework baked right into CSS. It allows us to define layout in CSS in an intuitive way, all the while embracing the default fluidity of the Web. The capabilities of this new layout tool are endless, and it enables us to accomplish layouts that were only possible with Javascript before it’s arrival.

Example of Grid Layout

Next-Generation Web Layouts

When it comes to layout, we’ve been stuck in a rut for quite a while. Established patterns and the limitations of previous layout tools in CSS have led us down the path of layout homogeneity in the past. You don’t have to go far on the Web to spot it: header, main content, sidebar, footer.

The arrival of responsive web design has initiated some new ideas for page layout, and with it some good patterns are beginning to emerge: ditch the sidebar, simplify the design, and focus on the content. But we are also seeing patterns emerge that have become so ubiquitous that we’re hearing the exclamation that “all websites look the same”.

Grid layout will enable us exit the layout rut we’ve been in and give us the tools we need to build the next-generation layouts. We can finally build around the content instead of forcing it into generic design patterns that can be found on every other responsive website.

A Word of Caution

It’s important to note that not all browsers support flexbox and grid features. We must take into consideration who our audience is for each project and determine if the majority of users will benefit from these more advanced features, while providing a sensible fallback for non-supporting browsers. It’s perfectly acceptable to provide users in legacy browsers with a simplified version of your UI, and enhancing it for users in newer browsers.

There’s More. A lot more.

We’ve only scratched the surface of what flexbox and grid can do. Luckily, there’s lots of great documentation available that touch on the capabilities of these new layout tools. Here’s some of my favorites:

Flexbox

Grid

Anyone that has been building for the Web is painfully aware of various limitations when it comes to layout in CSS. Often times, this required compromising the design so that it works as expected in development, or worse, relying on Javascript to implement the behavior we needed.

The arrival of flexbox and grid layout signal a new era of layout on the Web. We must adopt a new mindset when it comes to layout in order to not be limited by the habits, drawbacks and hacks of the past. Let’s embrace these new tools and renew our exploration for what’s possible with layout on the Web.

The Making of King of Soul

Sun, 11 Jun 2017 00:00:00 +0000

Fifty years ago, the world lost musical legend Otis Redding. The power he brought to soul music transcends the genre, and his influence can still be heard today. I created a web experience in commemoration of Redding’s legacy called King of Soul, and I’d like to share a little about how and why I created it.

Let’s Start with Why

I’ve become increasingly interested in the power of storytelling, specifically in the context of the Web. The Web gives us the ability to tell rich and engaging stories to an audience all over the world. I’ve come to realize that it can be leveraged for much more than just social media, corporate, and e-commerce websites. The Web can be a vehicle for storytelling, and therefore a powerful way to share history, ideas, and culture.

It doesn’t take long to go from being inspired by something, to wanting to try it out yourself. Since I’ve always admired websites that seemed to break outside the boundaries of the conventional and into the realm of storytelling, it was time for me to shift some focus and create my own.

After brainstorming a bit, I landed on a site dedicated to Redding’s musical legacy for 3 reasons: 1) his death was exactly 50 years ago, 2) his impact and story is significant, tragic and relevant to me personally (I was born and raised just outside of Memphis, TN, a crucial location in Redding’s story), and 3) the project provided plenty of opportunity for creative exploration.

Research and Wireframes

An early paper wireframe for King of Soul

I rolled my sleeves up and got to work during early spring of 2017. The first step was researching Redding’s life and making note of key events. I was already familiar with his music and it’s impact, but focused research always has a tendency to surface facts and connections unknown. With this research, I then began to loosely piece together the framework for the story I wanted to tell with paper wireframes. This is one of my favorite parts of a project — everything is possible and ideas are still malleable. I worked the wireframes until I had a loose idea of how the content would flow from one section to the next.

Style Tiles

A style tile created for King of Soul.

The next step was to explore general design aesthetic. My preferred method to do this is by creating style tiles, which allow you to create a direct connection with actual interface elements without defining layout. The goals here was to juxtapose design elements in a loose manner that could begin to formulate a design system quickly, without getting locked into high-fidelity design comps.

High-Fidelity

Once I felt both the wires and aesthetic were formed enough to begin, I created my first high-fidelity comp. The goals at this point is to get through an entire design, even if you feel that it’s not working. This is important because you are building a foundation for iteration, and along with it a clearer picture of what the design will look like in it’s entirety. If you continuously abandon a design halfway thought because it doesn’t feel right, you will continue to iterate over the same areas. It’s often this simple act of pushing through that opens creative alternatives and options.

I’ve come to learn after King of Soul that the process of refining and pushing content strategy doesn’t end when code begins to be written. In fact, it can and should evolve as much as the design will, and refinement should continue all the way up to launch (and beyond).

Design Iteration

The evolution of designs for King of Soul.

The next step is to iterate and refine both the design and content. This is the hardest part, at least for me. This is because it can be hard to know when to call it complete. It’s tempting to call it complete prematurely if you are anxious to get things in the browser. Making decisions in the browser is fundamental to the work of those creative Web based experiences, but it can also push us to hastily-made content decisions as well.

I’ve come to learn after King of Soul that the process of refining and pushing content strategy doesn’t end when code begins to be written. In fact, it can and should evolve as much as the design will, and refinement should continue all the way up to launch (and beyond).

Development

King of Soul was an opportunity for me to explore a number of things from a front-end development perspective. I’ll address some the more important items here:

SVG Animations

Firstly, there is SVG animations. I’ve experimented with SVG animations before, but they were rather simple. I wanted to take the opportunity and dive into the world of complex, sequential animation. For this purpose, I reached for the GreenSock library TimelineMax, which is described on it’s website as “the ultimate sequencing tool that acts like a container for tweens and other timelines, making it simple to control them as a whole and precisely manage their timing”. On top of it’s simplicity and power, the library smoothes out cross-browser differences, and most importantly, is built with performance in mind.

I leveraged the power of TimelineMax in several areas, but perhaps the most notable is it’s use for animating records playing. Creating these animations were quite fun and I look forward to exploring this more in future projects.

Nunjucks

King of Soul provided an opportunity to also explore Nunjucks templating. Nunjucks is a powerful templating language for JavaScript, and it made building and organizing HTML a cinch. Not only does it support file includes and macros (like functions that allow parameters but for HTML), but it also supports the ability to define a template document with extends. This feature designates a predefined space for content that will be different for each page which the template is used. This way, your page markup can stay quite clean and focused on the content while inheriting the overall framework of the template file.

One particularly useful feature that I used for King of Soul is the ability to populate HTML with data defined in JSON. This allowed for me to keep markup simple can clean, while tracking similar bits of data in a separate file. Changing content was much easier this way, since I didn’t need to edit HTML.

If your interested in learning more about Nunjucks, Chris Coyier put together a great introduction over at CSS-Tricks, and this more in-depth one by Zell Liew is quite helpful for getting started.

Lazy-Loading

The ability to lazy-load images was fundamental due to the shear amount of them required on the page. In addition to this, all images had high-resolution alternatives available if needed, which are being served via srcset and sizes. I needed a flexible solution to lazy-loading images that worked well with these image attributes, while giving me programatic control of events if needed. I found the perfect solution with LazySizes, which did exactly what I needed without any configuration. Not only did this speed up the page significantly once added, but it gave me fine grain control of events on each image and provided me the ability to respond when needed.

I hope you’ve enjoyed this overview of how and why I created King of Soul. I had a lot of fun making this project, and I hope to continue making more storytelling experiences. Check out my curated storytelling resource/gallery over at storytelling.design, stay up to date by following the project on Twitter, and keep an eye out for more original stories which will be posted on this page.

Introducing Storytelling.design

Wed, 24 May 2017 00:00:00 +0000

Storytelling is core to the human experience. We use stories to elicit an emotional response, to learn, or simply to make sense of the world around us. It’s an effective communication methodology that is fundamental to how we express thoughts, feelings, and experiences with others. When combined with the ubiquity and distribution power of the Web, we have quite an effective storytelling platform. This is quite unprecedented in that we can now tell more richer and more engaging stories while reaching more people than ever before.

There are many who have recognized this potential and are using the Web to share experiences that stand out alongside the endless sea of informational websites that seem to all look the same. I’ve become increasingly interested (and inspired) while watching these experiences come online.

In fact, my bookmarks have become so extensive on the topic that I’ve decided to team up with the talented Elizabeth Smith Mally and create a central repository that documents these experiences, alongside related articles on the topic. We’re calling it Storytelling.design, and we’ll be updating the site on a weekly basis to showcase the latest and greatest. Have a look, signup for our newsletter for regular updates, and follow us on Twitter to stay up to date!

Check out Storytelling.design

Thoughts on Productivity

Mon, 10 Apr 2017 00:00:00 +0000

Productivity has always been a topic of interest for me. While we all have our own approaches to getting stuff done, I’ve found that being able to identify different methods and choosing the appropriate one to manage the tasks ahead is incredibly valuable. This knowledge has enabled me to work smarter — a fundamental ingredient to better productivity.

Methods

Dotted-Line Principle

Tupac Shakur had a relatively short but extremely prolific musical career. In his last 8 months alone he created 150 songs — an average of 3 songs per studio session. In fact, he created enough material in that time for several posthumous albums, with plenty of unreleased music to spare. Tupac managed this impressive output by following the dotted-line principle: extremely quick recording sessions that consisted of recording a track in a single take, and then going back to fill in gaps where parts were missed.

The basic premise of this approach is simple: work through an initial concept without editing, then go back to refine, edit or add at a later time. It works because it’s easier to build on top of a rough draft than it is to begin with a blank canvas.

Eisenhower Box

Dwight Eisenhower was the 34th president of the United States, and a productivity legend. He served two terms as president, launched several programs during his presidency, served as Supreme Commander of the Allied Forces in Europe during World War II, planned the invasions of North Africa, France, and Germany, served as President of Columbia University, and served as the first Supreme Commander of NATO. In addition to this, he also somehow managed to hold down several hobbies.

The methodology he followed is now known as the Eisenhower Box: a decision matrix that separates your actions based on four possibilities. The first is ‘urgent and important’, which are tasks you should do immediately. The second is ‘important but not urgent’, which are tasks you should schedule for later. Thirdly are ‘urgent but not important’, which are tasks you should probably delegate to someone else. And finally, there are tasks that are ’neither urgent or important’, which are tasks that should probably be eliminated all together.

This method is great for identifying where our time and effort will be the most effective. Instead of continuously reacting to urgency, we can use this framework for making the decisions that prioritize tasks that get us closer to achieving important goals.

Pomodoro

The Pomodoro Technique is a simple way to power through and get tasks completed in short bursts, while taking frequent breaks. This approach to productivity was invented by the author Francesco Cirillo while a student, which he used to track his work with a tomato-shaped timer.

This technique is the most effective when facing a large task, or a series of tasks. By concentrating focus in short sprints, you can ensure your consistency productive and you keep your motivation high.

Seinfeld

Not all tasks can be accomplished quickly — some will require a lot of hard work over a long period of time. A great productivity method for achieving these tasks is the Seinfeld Method, which works like this: build a ‘chain’ by picking a task that you can sustain daily and will make an impact on your final goal. Then don’t break the chain.

This approach, which came as a response by comedian Jerry Seinfeld when asked his advice about developing comedic prowess, is great for those tasks that take a long time. By building a ‘chain’ of daily completed steps toward the long-term goal, you build motivation for yourself to continue and keep pushing forward.

Procrastination

As ironic as it might seem, procrastination can actually be a great productivity hack. Humans have a natural tendency to avoid difficult tasks and deliberately look for distractions. This is where the hack comes in: replace the distractions with other tasks instead of non-productive work like watching TV. The result is more items checked off the todo lists that were of lesser importance, and more focus on the primary task when your are mentally prepared to take it on.

Additional Insights

Busyness

Fight the urge to give into busyness. We must be deliberate in our actions, and consider how each task will helps achieve the larger goal.

Focus

It is imperative that we carve out significant blocks of uninterrupted time, during which we can dedicate focus to substantial tasks.

Burnout

Burnout is the enemy of productivity. Take breaks and spend time doing other activities as often as needed.

Screentime ≠ Productivity

Working a predetermined amount of hours doesn’t result in a proportional amount of tasks completed. In fact, studies have shown that the longer people work, the less productive they become.

Perfectionism

We must battle perfectionism. Trying to do things perfectly all the time will only lead to bad prioritization decisions.

Everyone has patterns they follow to ensure they’re productive, even if they don’t realize it. The ability to identify and choose the appropriate approach for managing different tasks is incredibly useful. These methods and insights that I’ve shared have enabled me to work smarter, and therefore be more productive with my time. I hope you find them just as useful!

Slides

Redesigning The Web Field Manual

Thu, 16 Feb 2017 00:00:00 +0000

Redesigns are a great opportunity to re-evaluate an experience, learn from how users are actually using it, and then optimize the design to improve it. They can also be a way to experiment with different interaction patterns, design aesthetics, or both. I recently got the opportunity to do all of the above with a side project of mine called the Web Field Manual. Here’s a recap of what I learned along the way, and some insight into various aspects of the redesigned experience.

History

Web Field Manual circa 2014

The Web Field Manual was first launched in May, 2014. What began as a post-conference presentation for my colleagues quickly evolved into something I thought would have a slightly longer shelf life: a website that highlighted not only the key take-aways from the conference, but also related reading organized by category. The project was quite successful upon launch and promptly became a labor of love that I have continued to update on a weekly basis since.

Over the last three years, I’ve experimented with different types of content, as well as incremental adjustments to the overall design, but no major overhauls since the initial release. The time had come for me to consider what the future of the Web Field Manual would be moving forward, and what a redesigned site would look like. I collected inspiration and articles for the better part of a year before starting, and this provided the research I needed to outline how I wanted to move forward.

Content

The content on the Web Field Manual has grown throughout the lifespan of the project. I’ve had the opportunity to try different ideas, some of which worked really well, and some of which were fun but didn’t evolve how I’d hoped. So with the fourth release, I decided to do a site-wide audit and purge anything that didn’t get updated on a regular basis. A ‘back to the basics’ release, I guess you could say.

Resources

Web Field Manual Resources

The resource links have always been the meat and potatoes of the project. These links have been added on a regular weekly basis since the initial launch in 2014, and audited periodically to ensure they remain relevant. The site initially only had ‘Design’ resources, but this quickly grew to also include ‘Code’ resources separated on a new page.

Tools

Web Field Manual Tools section

The fourth release of the project includes a new section called ‘Tools’. The mission of this new content is to provide small, single-purpose helper tools for designers and developers that are focused on common tasks. I’m very excited about this new section: not only will it be a great value to us that are building digital experiences, but it provides a lot of opportunity for me to grow while building these helper tools. These projects require a decent understanding of Javascript to work in the browser, and this is admittedly an area I’d like to continue and strengthen.

Search

Web Field Manual Search Feature

Lastly, there has been the need for search functionality on the project for a while. The content has grown to the point where the ability to search by keyword would be incredibly helpful. So partly for convenience and partly for necessity, the introduction of keyword search is now available on the project. I think this addition is a big improvement to the site, and will definitely help in finding specific content easily.

Auditing

The initial site release also included “Do’s and Dont’s” that were displayed along with resources, broken down by category. My vision for these tips were to provide some high-level insight pertaining to each category — sort of like a TL;DR. Over time, these tips didn’t get updated very often, and more often than not seemed like an add-on. The same applied to the ‘Guides’ section, which was a fantastic idea but didn’t get quite the amount of traction I wanted. So I decided to drop these for the forth release and see how things go.

UI

The aesthetic evolution of the Web Field Manual

The latest release of the Web Field Manual includes the biggest evolution of the design since the initial version. What started as very utilitarian design has evolved to being a little more layered and playful, while still of course being purposeful.

Aesthetic

The design aesthetic of the project has evolved in parallel with the content along the years. While there’s always been a playful ‘campiness’ to the site, the UI has been grounded and not too flashy, with a priority always placed on functionality over form. This reason for this is because the content must be scannable and users should be able to find resources quickly. If the aesthetic of the site gets in the way, then the site has failed to fulfill its primary goal.

But the Web Field Manual is also a passion project of mine, and therefore it’s sometimes necessary to have a bit of fun in order to stay engaged. I had been collecting inspiration for the better part of a year, and with this recent redesign I decided now was the time to push the design aesthetic a bit more. One aspect I really wanted to push was a more layered look that could come alive while the page scrolled, but say out of the way when it comes to the primary content (more on this later).

Color Scheme

Color evolution of the Web Field Manual

The color scheme of the initial release back in May 2014 could best be described as saturated yet subdued. The primary colors were a dark red and a heavily desaturated dark blue. These colors shifted toward being more muted by brining down saturation levels, and increasing the saturation of the base off-white.

Iconography

The iconography on the project is the one design element that has perhaps evolved the most. All original iconography was created by the extremely talented Geoff Tice, was a prominent element in the initial site release. With the second release of the project, a refined logo was introduced by design maverick Garrett Wieronski, and over time the iconography would evolve to be consistent with the logo.

Typography

The typography on the project has remained the same since the initial release. I’ve explored many different variations, but have always came back to the combination of Futura Bold for Headlines and Museo Slab 300 for body text. There’s something about this simply combination that is versatile and has formed the backbone of the design system for the Web Field Manual. Futura is an all-time favorite typeface and can make things feel very classic or vintage. When juxtaposed with Museo Slab, there is a great vintage meets modern aesthetic that really comes across the screen.

Animations & Transitions

Motion can add an incredible amount of magic to any experience, but they can also be used functionally to providing context and meaning to the user. I wanted to explore how animations & transitions could be leverage beyond the standard changes on mouseover to breath some life into the site. From page transitions to subtle adjustments to what’s visible while scrolling, I took the time to really consider how subtle uses of motion could transform interaction on the site and provide more meaning. The result is an experience that feels more fluid, responsive to user interaction, and far less jarringly when moving from one page to the next.

UX

Refactored resource list on the Web Field Manual

Improving the user experience throughout the site was a primary objective. The following were a number of key areas that were identified as needing some adjustment or total refactoring.

Card Pattern

Resources throughout the site have always been displayed as a lists, which made sense when there were a smaller amount of items per category. Over time, the amount of items has grown, and with it the need to improve scannability. By leveraging the card pattern to display each resource, we can ‘chunk content’ by providing distinct boundaries for each item, and therefore increasing scannability significantly.

Refactored category navigation on the Web Field Manual

The category navigation is a key component on the Web Field Manual. This component allows for uses to access and navigate to specific category sections on resource pages. Therefore, it must be easily accessible when needed, but not too obtrusive to distract from the primary content on the page.

This component has undergone significant change on each release of the project, with each variation attempting to balance ease of use and discoverability while trying to avoid becoming too distracting.

The latest variation of this component was born from the desire to move it from the primary header area to somewhere less prominent, but keep it easy to access and retain it’s discoverability for the user. By centering the component toggle at the bottom of the viewport and making it available when the user has landed on the page, or when they are scrolling up (more on this below), the component could achieve these objectives easily. This took a bit of trial and error and the feedback that my fellow designers provided me was invaluable. Eventually, I landed on a solution that I think works well and has the right balance.

Auto-Hide Sticky

Last but not least is a key piece of functionality: the auto-hide sticky pattern. This interaction pattern allows for key UI to be displayed by default but hidden as the user scrolls the page, and then revealed with the user scrolls up or lands at the bottom of the page. It is incredibly useful because it allows the user to focus on the tasks at hand: focusing on the content while scrolling, but remaining easily accessible when the user is likely to be looking for navigation.

Both the header/navigation and utility bar (which includes the category navigation) benefit from the functionality that this pattern provides. It is an excellent pattern that helps to keep the user focused and reduce the visual clutter that they must cognitively manage while interacting with the site.

While redesigns can be time-consuming and exhausting, they can also be incredibly rewarding. I learned a lot from this redesign that not only improve the experience, but will help inform designs on other projects in the future. I look forward to continuing to evolve the project and the value it provides to the community.

Check out the new Web Field Manual

Access and Experience

Fri, 02 Dec 2016 00:00:00 +0000

The Web has changed drastically since its inception more than 20 years ago. What was once a simple means of document sharing is now a fundamental part of everyday life, continuing to grow at an accelerated speed. At the heart of this growth is technology, changing the ways in which we access and experience the Web. The following are a few technologies we’re actively experimenting with and watching to see how they shape the future of Web experiences.

Progressive Web Apps

Progressive Web Apps (PWAs) are web applications using modern web capabilities, previously only available in native applications, to deliver an app-like user experience. Features such as background sync, ability to work offline, real-time push notifications, and installation to home screen ensure that PWAs are faster, more reliable, and more engaging than their traditional counterparts.

PWAs offer several advantages to users. They are discoverable via the web, negating the need to visit the app store to search, install, and launch the application. They not only live among native apps on mobile home screens, but they launch in full screen mode without the distraction of the browser. Service Worker ensure PWAs are fast and responsive to user interaction, while also providing the ability to deliver content even when the user is offline or connected to an unstable network. Additionally, there is no need to download updates from an app store, resulting in up-to-date content. And finally, push notifications ensure users remain engaged with the application beyond first-time use.

PWAs are relatively new (Google first introduced them in 2015), but are already seeing successful early-adoption by companies such as Lyft, West Elm, Alibaba, Flipboard, and more. These companies are adopting PWAs to solve business problems to provide a better experience to their users, all with similar results: increased conversion, efficient acquisition, and the ability to deploy/experiment quickly.

Physical Web

With the boom of Internet of Things (IoT), virtual and augmented reality (VR/AR), and increased accessibility to technology, the creative thoughts of humans have brought with them a new age where the gap between imagination and reality is beginning to close. Many of us have heard these buzzwords, but what do they mean for us?

The key to understanding the physical web is recognizing the lack of context we currently have when accessing the Web. In the beginning, our connection to the Web was heavily driven on our thirst to “know more”. For example, if we saw an interesting ad, we’d have to search the web manually or try to install a QR (quick response) code scanner on our phone to learn more. However, the entry into new experiences can now be driven off the full connectivity of the physical space. Bluetooth Low Energy (BLE) beacons, for example, can broadcast information from simple objects in physical space like parking meters, movie posters, or a sample display of fine cheese. The data can be tuned uniquely to provide specific physical and contextual detail to a user’s device. The user can then connect with a web experience tailored exactly to what they are interacting with, be it movie times, allergen information, or statistics. This gives way to new experiences where objects can provide us the context we lack during manual web-based searches.

IoT also provides new contextual data from the physical world. Not only can connected devices be monitored and controlled, but they also offer new ways to engage with the data. Contextual data opens new web entry points such as purchasing flows, for example, by smartly detecting low stock or need for replacement parts. This physical context gives us powerful ways to smartly engage with the world around us.

At the heart of this growth is technology, changing the ways in which we access and experience the Web.

WebGL

WebGL is a JavaScript API which allows supporting web browsers to render 3D content efficiently using hardware acceleration. One of the biggest advantages of WebGL is not requiring any additional plugins, whereas other means of rendering 3D graphics in a web browser do. WebGL has many commercial applications on the web which could easily give companies who use it an advantage over their competitors. Native 3D applications on the web are rare enough that no one expects to find them, which means consumers will usually be impressed and surprised when they do encounter them. Companies selling products online stand to benefit greatly by rendering their products in interactive 3D allowing users to obtain a better idea of the product’s scale, dimensions, and appearance.

The following examples are just a sample of what is possible when using WebGL.

Nike created a beat-maker featuring a variety of their shoes animated in 3D here
Heroforge allows users to customize tabletop fantasy characters and have them 3D printed and shipped
An interactive music video features Ellie Goulding using WebGL
Sketchfab uses WebGL to allow users can share their 3D creations directly in the browser – one of the most impressive and applicable uses
Google uses WebGL to allow users to view Google Maps in 3D
Another great opportunity to use WebGL exists in the Real Estate Industry. A 3D virtual tour will give prospective property buyers more confidence without having to see the property in person.

As internet speeds continue to increase, streaming high fidelity models on the web is becoming more accessible for larger audiences. A great number of industries are missing out by not including WebGL as a progressive enhancement to their websites.

WebVR

WebVR is a new technology allowing VR developers to target a wider audience by delivering content via a web browser. Available as a JavaScript API, WebVR provides the movement and position of a device, as data, available for a developer to tap into. By targeting a platform as common as the web, developers can leverage this API to bring virtual environments alive within their applications.

VR technology can be used for many types of experiences — gaming, virtual product or home tours, and interactive training applications just to list a few. Traditionally, content for VR devices is only offered through focused download pages or VR-content-specific sites preventing a seamless experience for the user. However, with WebVR, developers can now provide content that is easier to distribute and access by their users. Current websites and web applications now have the option of hosting VR experiences alongside traditional content, offering a more explorative and personal level of interaction. For instance, galleries containing pictures of a house for sale can now be accompanied by a WebVR tour inside the house.

To experience VR content, a specialized device has traditionally been required. While the number of devices available to consumers has increased significantly over the past few years, the reality is not everyone owns one of these devices. This severely limits the audience that can engage with VR content. Now, anyone with a mobile device can experience VR. With the web as a target, users can interact with products and take virtual tours anywhere they can access the internet.

Web technology is dramatically evolving how users both access and experience the web. Whether it’s providing more app-like experiences with PWAs or utilizing physical devices that provide us with meaning and context, people are engaging with the Web in entirely new ways. As we see with WebVR and WebGL, these experiences are becoming even more immersive and interactive. These technologies will continue to fuel the growth of the Web making the platform more diverse and rich.

Web Performance as a Competitive Advantage

Wed, 26 Oct 2016 00:00:00 +0000

Web performance is often considered an engineering optimization which developers are responsible for resolving at the end of the development process. This mindset is also why performance is one of the most overlooked optimizations on the Web. Performance must be an essential design feature that is prioritized during each phase of your process. In doing so, the speed at which your site loads will not only result in better user experiences, but can become a key competitive advantage.

Time is Money

Simply put, it is not enough to have a responsive website available on any device; it also must be fast. The average user expects your site to load in two seconds or less; after three seconds, up to 40% will abandon your site. Another consideration is that 88% of online consumers are less likely to return to a site after a bad experience that resulted from slow performance. This equates to lost revenue from not only that consumer, but also prospective consumers who may learn of the bad experience via social media or word of mouth.

It’s fair to say that online customers are impatient, and the implications are quite alarming. For example, Amazon has discovered for every one second delay, conversions dropped by 7% and would result in an annual loss estimated at $1.6 billion. Now let’s say your company sells $100k per day online. A single second delay that is making users wait longer than they want is costing your company an annual loss of $2.5m.

What Contributes to Poor Performance?

There are several contributing factors when it comes to poor performance on the web. Below are a few which have the most impact:

Page Weight

Page weight is the total file size of all elements that must be loaded in order to render a Web page, including the HTML document, stylesheets, scripts, images, fonts, and other media. In 2015, the average page weight increased by 16% to reach a whopping 2,262KB, and the year before saw a very similar increase.

Images are still the largest contributing factor to this, but things like custom web fonts, bloated CSS and Javascript are also adding up. Then there are the other features that supposedly “increase engagement”: third-party ads, obtrusive sign-up popups, underused social media buttons, and redundant tracking scripts. These combined elements contribute to bloated pages, and are likely hurting you more than helping.

Ignoring Progressive Enhancement

Progressive enhancement is a web design strategy which prioritizes content delivery to all browsers (usually via HTML and mobile-first structured CSS), and progressively adds enhancement layers. This layered approach is focused on providing everyone with access to basic content and functionality of a web page, while taking advantage of browser/device features if available.

Let’s take Javascript for example. This powerful scripting language is what powers most of the interactivity you will find on the Web. Unfortunately, many websites rely on Javascript to simply have a useable interface. There are a number of reasons why a device can fail to load this enhancement layer, resulting in a broken experience for the user. When and if this happens, the user will likely never return.

Adopting progressive enhancement not only ensures that users can utilize your website sooner, but the experience will remain useable even if something fails to load fast enough (or fails to load altogether).

Poor Planning

Web performance is an invisible feature, which often means it is overlooked. This inevitably results in performance optimization being put off until the end of the project, at which point it’s too late to have a significant impact beyond what is achievable with development optimizations. Performance must be treated as design if it is to become a competitive advantage. This means it is essential for everyone, not just developers, to make performance a priority and properly plan for it from the beginning.

Web performance is often considered an engineering optimization which developers are responsible for resolving at the end of the development process. This mindset is also why performance is one of the most overlooked optimizations on the Web. Performance must be an essential design feature that is prioritized during each phase of your process. In doing so, the speed at which your site loads will not only result in better user experiences, but can become a key competitive advantage.

Prioritizing Performance

We have covered why optimizing web performance is important, as well as what contributes to poor performance. Now let’s look at some ways we can prioritize performance in the early planning stages of the website creation process.

Planning

There are plenty of technical considerations when optimizing performance, but impact is limited if performance isn’t planned for and established as an essential feature from the beginning. Performance is an invisible feature, so it is critical for everyone on the team to treat performance as a priority. This means including performance as a primary objective in project documentation such as statements of work, project proposals, and design briefs.

Process

It is important that performance downfalls are discovered as soon as possible. By adopting a more agile design process and leveraging the power of prototypes, you can discover potential performance bottlenecks early. This will allow your team to address issues before launching your website, saving both time and money.

By prioritizing performance as an essential design feature, it is possible to leverage the resulting increase in page speed as a key competitive advantage. Per Google’s DoubleClick, ROI can be substantial. When comparing sites that load in 5 seconds to sites that load in 19 seconds, the faster sites had 70% longer average session lengths, 35% lower bounce rates, and 25% higher ad reach than their slower counterparts.

These findings reflect what many companies experience when prioritizing performance and serve as a catalyst to ensure that performance is a top priority for all projects relating to web development.

Scalable Design Foundation

Sat, 22 Oct 2016 00:00:00 +0000

Designing for large-scale is one of the biggest challenges a designer will face. Every aspect of the project is amplified and the complexities, risks, and unknowns can have a crippling effect. Luckily, there are some steps we can take early on to build a scaleable foundation and help set our large-scale projects on the path to success.

Designate Space

Large-scale projects involve a lot of moving parts: timeline, budget, milestones, objectives, dependencies, etc. A dedicated physical space (aka ‘war room’) is invaluable for extending a team’s collective memory and establishing a centralized location for developing a shared understanding of the project. This space becomes a room-sized communication tool that facilitates team collaboration and knowledge sharing.

Collective Memory

Digital documentation is useful, but nothing can replace seeing important knowledge and artifacts from the project on a wall together. It doesn’t take long for this information to grow as the team adds articles, additional documentation, design iterations, etc.

Since human visual short term-memory is limited, this space will extend the collective memory of the team by providing a means to finding crucial project information and free them up to focus on the tasks at hand.

Centralized Hub

Another benefit of a dedicated project space is it serves as a centralized hub of project information that is visible to everyone. It becomes a facilitator for the team, allowing them to effectively and efficiently make informed decisions, collaborate, solve problems, address concerns, etc. And last but not least, this space fosters a sense of team commitment and accountability.

Define Principles

Large-scale projects require a lot of design decisions and it’s essential that these decisions be made in a consistent manner. You’ll quickly hit a bottleneck if your team is relying on a gatekeeper to make each and every decision. A more sustainable approach is to define a set of useful design principles which establish the core values from which all design decisions should be made.

As Julie Zhuo points out, these principles enable design decisions to scale across many decisions and designers:

Instead of relying on gatekeepers to keep a high quality bar, better instead that everyone gets to agreement on a smaller set of guiding values, so that the best decisions get made in a consistent manner, scaling across many decisions, and even many designers.

Julie Zhuo, A Matter of Principle

Useful Principles

Useful design principles avoid being too obvious, open-ended, or weigh a positive against a negative. For example, “The design should be simple” is not a useful principle because it’s hard to disagree with and it lacks specificity. An effective design principle is one that helps to solve a practical design problem while also being able to address questions in the future.

Develop Language

Large-scale projects often require a wide variety of user interface components and patterns. These can quickly become fragmented, inconsistent, and hard to manage if the proper measures aren’t taken to document them.

A pattern library can provide many benefits for a team, including a means of documenting established design patterns in order to remain consistent and systematic, making testing easier, and providing a foundation for future growth.

Additionally, pattern libraries help to align team members on a common design language by isolating the elements that make up the interface in a central location. It is a check and balance measure that is mutually beneficial and one that promotes an understanding of each other’s discipline.

In turn, design will stay grounded in the patterns that have been established and reduce design fragmentation, therefore reducing development time and making the end user experience more consistent.

Modularity

A significant challenge for many teams is moving beyond the ‘page mindset’. Building a design system around solving problems on a page-by-page basis creates a design language that is unable to scale. The more scaleable approach is to build a system of reusable components and patterns that can be used in any context, and are detached from specific viewport widths.

The key to building modularly is to ensure each component or pattern follows specific criteria. Each should be clearly defined, have specific functions and named according to this function, standardized, reusable, and detached from specific viewport widths.

Following this criteria will ensure a cohesive library of components and patterns that can be assembled to build interfaces that work across a myriad of screen sizes, devices, browsers, and environments.

Naming

Language is fundamental to establish a design system. The first instinct of many is to name components or patterns according to how they appear. For example, a ‘promo banner’ which displays promotions and consists of a large image, title, supporting text and a button. The name given to this component defines how it will be used: when we need to display a promotion, we use a promo banner.

The problem is the lifespan of this component has been defined in it’s name: no promotions means no component, and therefore the component is not reusable in instances where we need other kinds of banners.

By detaching components and patterns names from their styling and naming them according to their function, you extend their lifespan and enable reuse. In the instance of our promo banner, naming the component ‘banner’ will ensure it an be leverage whenever there’s a need for any type of banner.

Test and Iterate

The amount of unknowns and potential risks grow with the scale of a project. This can affect our design systems in a number of ways, and can easily result in some false assumptions about how our users will interact with the interface.

If design is working toward one big ‘hand-off’ to the development team, these false assumptions will be discovered when the costs of fixing them is much higher.

A more effective process is to incorporate prototyping and testing into the design process in order to validate design decisions, discover potential issues, and address them early. This will effectively mitigate risks and ensure we are building a design system that is grounded in validated decisions.

Prototype

Prototypes are a great way to quickly test an idea and validate assumptions. This can be done on a component level, or expanded to test a collection of patterns or components. Building prototypes early in the design process enables us to identify potential issues that might occur later on. As a result, we can quickly address issues before they become larger problems when the stakes are much higher.

An example of this I find myself repeating on each project is the global navigation. This crucial interface element can get complex when adapting to various screen sizes or content.

By prototyping a solution early on, I am able to not only test if it a viable solution, but I can ensure that any design moving forward is grounded in a solution that’s best tested and is more resilient.

User Testing

User testing gives us the ability to inform design decisions and free ourselves from relying solely on design intuition or subjectiveness. This analytical understanding of how users interact with our product/website will not only improve the work, but it gives us solid reinforcement when justifying design decisions to clients and stakeholders.

In addition to this, user test gives us measurements to gauge success and identifying places that need improvement after launch, ensuring that the work will continue to evolve and respond to users.

The amount of challenges that a designer will face is proportional to the scale of the project, but we can manage these challenges by building a scaleable foundation.

A dedicated physical space will extend our team’s collective memory and establish a centralized location for developing a shared understanding of the project. Design principles help to establish the core values from which all design decisions should be made, and ensure that decisions are made in a consistent manner. A pattern library is useful for documenting established design patterns in order to remain consistent and systematic, making testing easier, providing a foundation for future growth, and aligning team members on a common design language. And lastly, incorporate prototyping and testing into the design process is fundamental when validating design decisions, discovering potential issues, and addressing them early.

The Modern Web Is

Mon, 10 Oct 2016 00:00:00 +0000

The Web has come a long way since it’s inception over a quarter of a century ago. We’re undergoing a renaissance of browser and device technology now, and this quickly changing landscape has me pondering what the next 25 years will look like. Specially, what are the best practices that will define what makes up a modern web experience?

Accessible

Modern web experiences are accessible to all users. According to the World Health Organization, 285 million people are estimated to be visually impaired worldwide, 39 million which are blind and 246 have low vision. In addition, 275 million people are considered deaf and hearing impaired. The modern web ensures support for these users and others by following best practices for maximum reach and access.

Performant

Modern web experiences treat performance as an essential design feature and we understand that users expect them to load fast. In fact, users expect pages to load in two seconds, and after three seconds, up to 40% of users will abandon the experience. In addition, mobile users expect web experiences to load at least as fast or faster than the same experience on a desktop device.

Progressively Enhanced

Modern web experiences aim to deliver the best possible experience to the widest possible audience, regardless of browser or device. It embraces the variability of the web by prioritizing content delivery to all browsers, and then progressively layer enhancements according to the device or browser capabilities.

Device Agnostic

Modern web experiences take into consideration the variability of the web and understand that people can fluidly move between devices. They account for not only screen size, but also the infinite combinations of screen resolutions, input methods, browser capabilities, and connection speeds.

Content First

Modern web experiences are built around the content. We understand that without content, design is merely decoration. Therefore, we design experiences that prioritize content and by extension the needs of the user.

Mobile First

Modern web experiences focus on the key tasks that users want to accomplish without extraneous features or content. We understand that mobile devices are the primary means that people access the web. We also understand the constraints of limited screen space force us to prioritize content and features, which leads to a better user experience.

Modular

Modern web experiences are no longer designed as pages. Instead, we’ve embraced the creation of systems for scalability, portability, and reuse. The quantity and diversity of connected devices have necessitated the adoption of modularity in our strategy, process, content, design, and development.

Purposeful

Modern web experiences are designed purposefully. Design elements such as animations are utilized to improve feedback, aid in orientation, direct attention, show causality, and express brand personality. They find the right balance of purpose and style while blending into the interface seamlessly.

A Collaborative Effort

Finally, modern web experiences are a collaborative effort between teams and skill sets. We know that the success of a project can be directly correlated with how well it’s creators can collaborate to produce the best experience possible for the user. To achieve this, we have abandoned the assembly-line process of creation, and turned to a more iterative approach which allows us to break down our processes into smaller, more manageable chunks. Our workflow have been de-compartmentalized so we can quickly design, build, test and then evaluate.

Reducing Design Complexity

Mon, 03 Oct 2016 00:00:00 +0000

To distill a design down to its simplest form, designers must reduce complexity and eliminate anything that distracts from the primary goal of the user. This process is often time-consuming and only possible through repeated iteration and refinement. To help in this process, there are a few strategies I’ve found quite effective when it comes to reducing complexity in my work: thinking mobile-first, leveraging progressive disclosure, and designing with progressive enhancement.

Mobile First

‘Mobile first’ is a strategy that forces designers to consider what’s really important in a product or service. The limited screen real available on smaller screens require us to remove any extraneous elements or features. Additional features and supporting elements can be selectively introduced as screen real estate increases, but they are absent by default. This strategy is effective for simplifying designs because it eliminates the need to cram complex desktop experiences into mobile screens. The result is a design that is focused on key tasks and content without the extraneous obstacles, and therefore a better user experience.

Example of Mobile First

News websites have long been a great example of desktop-centric experiences that fail at providing mobile-friendly content without resorting to a separate mobile version. One stand out exception to this is TheGuardian.com. It’s clear on the Guardian website that smaller viewports have been prioritized by the lack of extraneous elements. As a result, the experience is mobile-friendly without resorting to a separate mobile site, and additional content is revealed as the browser capability and screen real estate increases.

Progressive Disclosure

‘Progressive Disclosure’ is an interaction design technique that displays only important actions or content by default, while making additional features or content easily accessible. The result is a more streamlined interface that helps to keep the use’s attention focused by reducing clutter, confusion, and cognitive load. Anytime we use a dropdown, accordion, or toggle that reveals content that is hidden by default, we are utilizing progressive disclosure. This strategy is incredibly useful for simplifying designs because it enables us to defer less important actions, advanced features, or additional content to a secondary screen (like a dropdown, accordion, or content toggle).

Example of Progressive Disclosure

A great example of progressive disclosure can be found on stripe.com: by hovering the mouse over any item in the primary navigation, a menu will appear that reveals the various links in that category. Stripe has created a simple interface in which users can quickly scan and find relevant information without needing to dig through a mountain of content in the process.

Progressive Enhancement

‘Progressive Enhancement’ is a technique that focuses on access to the basic content and functionality for all users, and then layering enhancements to the page for more capable browsers and devices. Much like thinking ‘mobile first’, progressive enhancement forces designers to prioritize a baseline experience that becomes more complex only when appropriate. Progressive enhancement can effectively simplify designs because it requires a shift in mindset: reprioritize the emphasis to what is essential in the experience. It’s a subtle shift that has a lasting effect: spend more time on what’s important and less time on what’s nice-to-have.

Example of Progressive Enhancement

A Bear’s-Eye View of Yellowstone by National Geographic is a great example of progressive enhancement in action. This rich, interactive experience is built around a baseline experience: text and video that tell the story of a bears journey through Yellowstone. The baseline experience is enough to adequately tell the story, but additional features are introduced when additional browser capabilities and space are available. These additional features serve to simply enhance the user’s experience — they aren’t core to the essential content.

By following the strategies I’ve outlined above, it’s possible to dramatically reduce unnecessary complexity in your designs. The result will be an improved user experience that allows users to focus on the pertinent content or features. Give them a try and see how they not only simplify your designs, but simplify your design workflow.

Designers Web Performance Checklist

Wed, 14 Sep 2016 00:00:00 +0000

I created a project checklist to help aid designers in prioritizing performance during the design process. This checklist is based on my article ‘Designers Guide to Web Performance Optimization’, which takes a look at how designers can help to champion and prioritize performance on the web.

View WPO Checklist

Designers Guide to Web Performance Optimization

Tue, 06 Sep 2016 00:00:00 +0000

Performance is one of the biggest issues we face on The Web today. As the weight of the average page continues to rise, discussion around performance on most web teams quickly descends into the realm of development optimization. The reality is that performant web experiences begin with treating performance as an essential design feature. In this article, we’ll be looking specifically at ways that designers can help to champion and prioritize performance.

Why Performance Is Important

Web performance optimization is important because it directly impacts user experience and page metrics. You can pack as many micro-interactions, animations and beautiful images you want into a page — if the page is slow, the user will likely never see them. This is exacerbated by connection speeds on mobile devices, which is now the predominant method people all around the world are accessing the internet. All to often, we tend to forget that the fast internet connections we enjoy while designing experiences for the web is not the norm for those whom will visit it.

The road towards better performance doesn’t start with developers or technology stacks (though I’m certainly not suggesting those things are unimportant). It begins with a shared interest on everyone’s part in making a product that’s lightning fast.

Brad Frost, Performance As Design

Process & Workflow

By prioritizing performance and making it part of our workflow and process, designers can help to make performance an essential design feature. We must shift to emphasize performance, instead of tacking it on at the end or leaving it up to the development team.

Shift Your Perspective

It is pretty common for designers to jump right into designing for ‘desktop’ and then work their way down to ‘mobile’ when exploring design concepts in high-fidelity. This is a mistake because it fails to consider viewports that fall in–between common viewport sizes, or viewports that are on the extreme ends of the spectrum (like TVs). As a result, this failure of consideration can be problematic in development and result in half-baked solutions.

Secondly, it’s more effective to think in terms of the smallest viewport first, which helps prioritize content and features by forcing us to consider what’s important from the very beginning. This ‘mobile-first’ mentality goes hand-in-hand with progressive enhancement, or adding layers of enhancements to a solid foundation in order to deliver an accessible experience to all users.

Collaborate

One of the most effective steps a designer can make is to simply involve the developers in the design process as early as possible. The insight that developers will provide is invaluable, and it will help to ensure design decisions are being validated up front.

If discovery whiteboard sessions are part of your process, then development team members should be in room. When your team reviews wireframes, sitemaps or design mockups, then developers should be right there in the mix. And finally, when anything is being shown to the client, the development team should be represented.

Another benefit of collaborating closely with development team members is the ability to build prototypes and identify performance bottlenecks early. Design comps cannot tell us how much that banner image or additional font will affect page speed on a 3G connection. With prototypes, we can spot potential issues and make design decisions in the appropriate environment sooner.

Sticking to a Budget

An effective method for keeping page size in check is to set a budget up front. Commonly referred to as a ‘performance budget’, this approach requires first identifying a page weight limit early on, and then ensuring that the total weight of assets on the page doesn’t exceed this limit.

You’ll need to work closely with development team members to both identify and track this, but the end result is well worth it. Not only will a performance budget help to set some boundaries for you in the design process, but it will help to ensure that every design decision being made must happen with performance in mind.

Avoid One-Off Solutions

It’s all too easy to create one-off solutions that abandon patterns established elsewhere in your system for the sake of solving a particular problem. What you don’t see when you do this is an increasingly bloated code base that will ultimately affect performance (not to mention increased difficulty in maintaining or extending the code in the future).

A better approach is to avoid one-off solutions by thinking of your designs as systems of components which make up a whole. If you find yourself creating a one-off solution that isn’t likely to be leveraged elsewhere, it’s time to consider reusing or modifying a pre-existing component or pattern you’ve already created.

Even better, consider starting with a style guide and use it to lay the foundation for all UI solutions.

Animation & Effects

Enhancements such as animations and effects can add a lot to the users experience, but can also take a toll on performance. To find a balance, we must weigh the value these enhancements add to the experience with the costs at which they come.

Meaningful Animation

Animations can improve the user experience by providing context, visual cues, anticipation and functionality. They can also be misused as a means of embellishment. All too often, I hear of animation being used to ‘enhance’ an interface, when instead it’s simply meaningless motion with no purpose outside of being flashy. Using animations in this manner can not only impede usability and understanding, but it can also have a negative impact on performance. Good animation is invisible and provides meaning for the user, as opposed to animation for the sake of animation or because it’ll look great for your next Dribbble shot.

Scroll Effects

A good design rule of thumb in general is to have a purpose behind every single design decision. This means when we intend to have parallax, scroll-jacking, or animation effects happening as the user scrolls the page, we better have a good reason. Doing anything that fires on the scroll event can be costly, especially when it isn’t properly implemented — not to mention annoying for the user.

Fonts

While web fonts are awesome, they must be used with caution. This is because they not only contribute to the overall weight of the page, but can also block rendering of text on the page.

Limit Fonts in Use

Each weight and style of a typeface that you decide to use is a separate web font that results in a server request. The simplest way to mitigate this is to keep custom web fonts to a minimum. While this isn’t necessarily a design best practice specific to the web, limiting the fonts in use is even more pertinent here. A general rule of thumb is to not exceed 2-3 web fonts per page and to use web-safe fonts whenever possible.

Choose Wisely

Not all fonts are created equal. It’s important that the fonts you choose have been optimized for web use, i.e. they’ve been hinted, they render as expected cross-browser, and they’ve been subsetted to contain only the necessary glyphs in order to reduce file size.

Formats

There isn’t a single format that works in all browsers. As a result, we must define multiple formats and let the browser choose the one it supports in order to provide a consistent experience. When doing so, don’t forget to provide font formats that are designed to be more performant, like WOFF 2.0. Browsers that support this format can leverage its advantages, which browsers that don’t will fallback to a format it does support.

Fallbacks

Since custom web fonts can delay the rendering of text on the page, it’s important to have web safe alternatives ready. This will help to ensure that text can be rendered as soon as possible, and then progressively enhanced to make use of the custom fonts when they are available.

Images

Images are by far the biggest contributor to page weight in most circumstances. While there are some significant ways developers can ensure that the footprint of images is as small as possible, the best way to avoid them weighing down pages is for designers to plan accordingly.

Use Sparingly

The best method for avoiding images from weighing down the page is to only leverage them when they provide value beyond what a simple icon or well-written piece of copy would provide. In other words, use images sparingly and for maximum effect — while a picture is worth a thousand words, it can also contribute to poor page performance and ultimately a high amount of user abandonment.

Choose the Right Format

Simply choosing the appropriate file format for an image can have a significant affect on page load. While JPEGs have a tendency to compress better and result in lower file sizes, they lack alpha channels and therefore cannot contain transparency. PNGs on the other hand have the ability to contain transparency, but can easily weigh 3x the size of JPEGs.

There are also new image formats that provide even smaller file sizes, but lack wide support by browsers. The WebP image format proposed by Google promises superior lossless and lossy compression, but browser support necessitates developers implementing fallbacks in order to leverage them. There’s also the JPEG 2000 format, which has even less browser support. If you’d like to leverage these image formats for optimal file sizes, be sure to take into consideration browser support and your users, as we’ll as work with your development team to ensure the proper fallbacks are in place.

A note on JPEGs: When exporting out images as JPEGs, it’s a good idea to save them as ‘progressive’. This will ensure the image is rendered in browsers that support this feature as increasing sharp layers until the image is fully loaded, as opposed to rendering loading it from top to bottom.

Responsive Images

A relatively recent feature in front-end web development is the introduction of responsive images, which are images that adapt in response to different environmental conditions. These adaptations can include, but are not limited to, changing the dimensions, crop, or even the source of an image. Such attributes allow developers to define an array of images, and then either define (with the ” element) or allow the browser to choose (via ’srcset’ and ’sizes’ attributes) a more appropriate image based on the users conditions.

As designers, we can facilitate the use of responsive images by first identifying the various image sizes that will be needed, and then outputting these assets for development. This process can be a bit tricky at first because you must know your breakpoints in order to determine the right image dimensions, and also take into consideration higher resolutions screens. I’ve written an article that outlines how I like to identify and consolidate these values, which you can find here.

Optimization

An asset that isn’t optimized for the web does’t belong on the web — this is especially true for images. Don’t just assume assets will get optimized in development. Instead, it is our responsibility to ensure proper assets are delivered. By leveraging tools such as ImageOptim and ImageAlpha, we can significantly reduce file size by removing necessary image data while preserving the overall quality of the image. These post-optimization steps should of course following saving the image out in your design program of choice ‘For the Web’.

However, image optimization isn’t limited to compression. Another method for optimizing images is to blur sections of the image of lesser importance while preserving the focus on key areas. Additionally, you could convert the image to greyscale to reduce color information, which can have a noticeable impact on file size.

SVG

SVG, or scalable vector graphics, offer many advantages over their raster counterparts. Not only are they resolution agnostic, i.e. they can scale and look great at any resolution, but they also can be applied directly on the page. This eliminates the need for an additional server request, and ensures they can be highly compressed with the page content.

Know When To Use

There are a few things to keep in mind when using SVGs on the web. The first thing is to know when it’s appropriate to use SVGs. SVGs are great for vector-based 2-dimensional graphics such as icons or even complex illustrations. On the other hand, SVGs are not appropriate for photographs.

The next thing to consider is browser support, which varies depending on how the SVGs will be implemented. The best bet here is to work closely with your development colleagues to determine the best approach.

A Note on SVG Animation: An added benefit of SVG that you don’t have with images (aside from GIFs, which are on average much larger in file size) is programatic control over the entire or individual sections of the SVG. This means you can animate them, and there are various methods of doing this. Each method of animating SVGs comes with own pros and cons, so be sure to test in various browsers and devices when using them.

Optimization

SVGs can be compressed alongside page content via server compression methods like gzip, but they should also be optimized beforehand. The reason for this is that SVG files can often contain extraneous data that doesn’t affect how the icon will appear in the browser (in many cases, it’s simply there as an artifact from the design program in which it was created). It’s a good idea to run your SVGs that are being used in your designs through an optimization tool before handing them over to development, and there are plenty of great tools to help with this (check out below).

Perceived Performance

Perceived performance, or the speed at which users perceive a website to be, can play a crucial role in user satisfaction. There will inevitably be instances in which site performance isn’t ideal due to conditions beyond our control, like network latency or intense server processing. However, we can plan ahead and design for such instances by creating the illusion of speed and responsiveness.

Provide Feedback Instantly

Perhaps the most frustrating part of a slow web experience is when you perform an action, but it isn’t clear whether or not the action was successful for even received. This issue can be mitigated by designing interfaces that provide instant feedback, while optimistically processing the action in the background. As a result, we can ensure processing isn’t delaying the feedback that users need, and the experience feels smooth and responsive.

Placeholder Content

Another technique for increasing perceived performance is to populate the page with placeholder content by default and then allow this content to be replaced with actual content once it’s been loaded. This will create the illusion that something is processing, and as a result the user is willing to wait longer for their content. This approach is arguably better than displaying loader elements in place of content because it feels like content is being loading faster.

Conclusion

Web performance optimization isn’t something we can tack on the end of our processes or assume is handled with development. Fast web experiences start in the planning and design phase, and as designers we must champion it on our teams and incorporate it into our processes and workflows. After all, good performance is good design.

Designers Web Performance Checklist

I’ve created a project checklist which reflects the techniques outlined in this article, which you can find here.

Developing Extensible HTML and CSS Components

Mon, 29 Aug 2016 00:00:00 +0000

The days of building fixed-width web pages from pixel-perfect Photoshop files are gone. In order to produce flexible layouts that smartly adapt to any screen size, our workflows have undergone changes to be more iterative and agile. We’ve come to understand the importance of modularity and how it facilitates the flexibility we need to stay nimble in the browser. As a designer and front-end developer, this flexibility is integral to how I approach web projects. I find myself making design decisions in the browser more often than design files, and to support this workflow I need the ability to build user interface modules that can be easily extended.

Read Article on CSS-Tricks

Bridging the Divide

Sun, 26 Jun 2016 00:00:00 +0000

There is occasionally a divide that separates designers and developers, and it can be the source of friction during a project. Inevitably, it results in a ‘us versus them’ mentality originating from a lack of knowledge, failure to communicate, or lack of collaboration. To exacerbate matters, design and development teams are often segregated to opposing sides of the office or even by geographical location. We can effectively bridge this divide to not only improve the experience of working together but to produce better work.

Obtain an Overlap

An effective method for bridging the divide between design and development teams is to have an overlap of knowledge. This doesn’t mean as a designer you must also be a skilled front-end developer, but understanding the principles will help to inform our work and how it will eventually be developed. Likewise, a developer doesn’t need to be a skilled user interface designer, but a working knowledge of the fundamentals like typography or design principles can provide helpful insight into why designers request specific features and functionality.

A knowledge overlap will help us anticipate questions and provide solutions in advance, communicate in terminology that each team members understands, and ultimately strengthens our work by allowing us to work more efficiently. The end result is we free up time to focus on the details that improve the overall user experience.

Communication

Communication is the most vital component of any team. Effective communication will help to ensure that design and development team members are sharing knowledge and that collaboration is efficient.

Define Goals and Process

Without proper planning, it can take a team well into a project before they find a process that works for everyone. Unfortunately this means that up until that point, the efficiency of the team wasn’t optimal. Details like project goals, principles, and specifications pertaining to deliverables such as file handoff and interaction states are prime examples of things to define early between design and development team members. The earlier your team can align on an agreed upon set of project goals and process, the quicker it can avoid miscommunication and be productive.

Fortunately, we work in a time when there are many tools available to help streamline our workflows and how designers and developers work together. Tools such as Invision provide the ability to quickly prototype and demonstrate project flow, while tools like Zeplin can be of tremendous value for documenting the finer details of designs. When paired with programs like Sketch, these tools integrate seamlessly and make the project documentation effortless.

Create Communication Channels

Opening the channel for direct communication not only eliminates work for project managers, but allows for design and development team members to resolve issues more efficiently. What’s the best way to enable direction communication amongst team members? This is achievable by having daily team meetings in the form of stand-ups or scrum meetings, opening a dedicated channel with tools like Slack, and fostering a culture of open communication by encouraging team members to engage with others directly.

Review Periodically

All too often, quality assurance doesn’t happen until the end, which leads to the development team most likely becoming overwhelmed with bug fixes and task in the backlog due to a shortage of time. A much wiser approach to reviewing a product is to test quality early and often, where items can be addressed sooner and the snowball affect mitigated or avoided altogether. Instead of waiting for one large QA at the end of development, try quality reviews after each sprint or page is completed. This will ensure that reviews are less overwhelming, and can have the return effect of reducing total QA items over time by addressing issues early that otherwise would snowball into larger ones.

Collaboration

Collaboration is the cornerstone to a successful team. Through collaboration, designers and developers work together to ensure the final product is the best possible quality.

Get Involved

Perhaps the most effective method in closing the divide between design and development teams is to simply involve the developers in the design process as early as possible. If discovery whiteboard sessions are part of your process, then development team members should be in room. When your team reviews wireframes, sitemaps or design mockups, then developers should be right there in the mix. And finally, when anything is being shown to the client, the development team should be represented.

The reason for this is because the insight that developers will provide is invaluable for how design on the project will evolve. Their knowledge can and should help shape the experience, and it also serves as a check and balance measure to ensure that ideas are aligned with technical limitations. It is a mutual beneficial method of inclusion that developers appreciate, and will help to ensure that the transition from pixels to code is smooth.

Make a Style Guide

A style guide can provide many benefits for a team, including a means of documenting established design patterns in order to remain consistent and systematic, making testing easier, and providing a foundation for future growth. Perhaps most importantly, style guides help to align design and development team members on a common design language by isolating the elements that make up the interface in a central location. It is a check and balance measure that is mutually beneficial and one that promotes an understanding of each other’s discipline. In turn, design will stay grounded in the patterns that have been established and reduce design fragmentation, therefore reducing development time and making the end user experience more consistent.

Be Flexible

Last but certainly not least, it is important to be flexible. This means being open to other opinions, even if those opinions differ from your own. Being flexible doesn’t mean that design should be compromised: compromising design quality should never happen, but finding middle ground on how to approach a problem is vital for a successful end product. Being respectful and considerate to those whom have a different perspective will not only strengthen the end product, but will promote collaboration and flexibility from other team members as well.

Knowledge

Knowledge is key to understanding. An increase in knowledge directly affects how designers and developers communicate, and in turn how effectively we collaborate.

We’ve looked at the three factors behind the designer/developer divide: lack of knowledge, failure to communicate, and lack of collaboration. These factors have a dynamic relationship and by improving one, you can have an affect on the others. Likewise, a failure in one factor can have an adverse effect to them all. By balancing all three through the strategies we’ve outlined, the divide that separates designers and developers can be effectively bridged, resulting in an improved working relationship and better end results.

A Guide to Personal Side Projects

Thu, 26 May 2016 00:00:00 +0000

Personal side projects are a cornerstone of creative growth and discovery. While they might not always result in financial gain, the long-term benefits are often much more useful. Benefits such as personal growth, creative exploration and generation of professional opportunities are some of the reasons to engage in them. In this article, we’ll explore these benefits, as well as learn how to decide on a project and how to effectively manage our time (using my recently launched project an an example). Finally, for inspiration, we’ll look at some great examples of personal projects.

Read Article on Smashing Magazine

Optimizing for Large-Scale Displays

Mon, 09 May 2016 00:00:00 +0000

With the rise of ultra high-definition displays and devices that enable browsing the web via smart TVs, the internet is increasingly being accessed and viewed on screens that dwarf traditional desktop displays. Most websites fall short of being optimized for this scale. But if you’re building responsive websites, it’s likely that the tools you need to scale your content are already in place. In this article, we’ll take a look at the challenges and techniques for optimizing your site on large-scale displays.

Read Article on CSS-Tricks

Designing the Unseen

Mon, 25 Apr 2016 00:00:00 +0000

It’s quite easy as a designer to become hyper-focused on the details of our work. From the nuances of typography and color pairing, to how content will adapt across various viewports, there are plenty of details to manage and perfect on each project. But how often do we take the time to focus on designing the unseen details? These details are just as important as the ones that people will see, and if done right will differentiate a good product from an exceptional product.

The Unseen

You have to make the back of the fence that people won’t see look just as beautiful as the front, just like a great carpenter would make the back of a chest of drawers … Even though others won’t see it, you will know it’s there, and that will make you more proud of your design.

Steve Jobs, recounting an early design lesson from his father.

I love this quote that Steve Jobs attributes to his father because it touches on how important the ‘unseen’ details are. And much like Job’s reference to the ‘back of the fence’, there are many unseen aspects of our work as designers. Let’s take a look at a few and why they are important.

File Organization

File organization can easily be overlooked as laborious and without significant benefit. But contrary to this point of view, meticulous file organization can have a number of benefits. By naming layers, grouping elements and arranging groups in the order in which they appear on the page, you gain a significant amount of efficiency. Not only will it be faster to work in the file, but it will be easier for other designers to jump in and make changes when necessary.

Another notable benefit of keeping your design files neatly organized is pride in the execution of your work. When you take the time to organize your design files, you are ensuring that the aesthetic is carried through. This pride in your work will inevitably show through in the work, and the users of your product will appreciate the attention to detail.

Design Principles

Defining a set of design principles based on the needs of your users should be one of your first task on any project. Why is this you ask? The answer is simple: because there is an exhausting list of design decisions that must be made on every project, and in order to have a consistent design system that scales, a solid set of principles are key to help guide the decision making process. These principles serve as guiding values in which a designer can leverage for any design decision they encounter.

So what makes for a good design principle? Unlike the subjective things like “how it looks/feels”, a good design principle has a tendency to feel timeless and not anchored in opinion. It must be solid enough to withstand many decisions and still hold up, like for example those found in Google’s Material Design or Apple’s iOS Human Interface Guidelines.

Collaboration

Everything can benefit from a bit of design, and your design process is no exception. If collaboration isn’t a pillar to your design process, it’s time to reconsider how you work with other members of your team. This is because behind any good product is an effective team that knows how to communicate and involve disciplines in their process.

As a designer, this means bringing the development team into the design process and making them part of the decision making that goes into your work. Developers will help to ensure your interface is consistent with patterns you’ve already established, as well as serve as validation on design features you want to include in the interface. The feedback that developers can provide is invaluable, as they will be seeing your work from a implementation perspective and therefore considering things you might not have thought about during design.

Performance

The performance of your product is not solely a technical concern for the development team — it is an essential design feature. As such, performance should be identified as a goal early on in project documentation, design should be grounded in performance best practices, developers should have the ability to identify performance concerns early on, and designs should be tested on actual devices in an effort to gauge performance metrics and identify potential bottlenecks. This will give designers the ability to adjust during the design process and address performance concerns before it’s too late.

Design Systems

Design systems are an essential tool to help teams maintain consistent experiences, but often go unseen outside of those doing the work. That doesn’t mean they are any less important: not only do design systems establish a common language, but they save time and effort when it comes to design, testing and scalability.

Media Slat Component

Sat, 27 Feb 2016 00:00:00 +0000

A demonstration of a full-width media component comprised of part text and part image. The component is governed by a few rules: 1) the image must fill it’s designated space at all times, and 2) the image must be inline.

Let’s start by taking a look at the markup behind this component. I’m keeping this simple and semantic by leveraging an <article> tag, and then naming the child sections in the context of the parent element with B.E.M. syntax. The first child element in the slat will be the slat body where all text content will go, and the second child element will be the slat image. The slat image is a content image, therefore it will be inline.

<article class="slat">
<div class="slat__body">
// Text content goes here
</div>
<div class="slat__item">
// Inline image goes here
</div>
</article>

It’s a good idea to leverage a responsive image solution here. This way, we can ensure that only one appropriately-sized image is downloaded.

Next let’s take a look at the styles that make the media slat component work. It’s important to set relative position on the parent element so the children have a context for their positioning. Next, we ensure the width is 100%, that all overflow is hidden, and that the height of the slat is explicitly set. Setting an explicit height is crucial because the children will be absolutely positioned and as a result, the parent will not have a height.

.slat {
position: relative;
width: 100%;
overflow: hidden;
@media #{$small} {
height: 150px;
}
@media #{$medium} {
height: 250px;
}
@media #{$large} {
height: 300px;
}
@media #{$xlarge} {
height: 400px;
}
}

The next step is to define the behavior of the children elements. Both the slat body and slat item will be absolutely positioned. We are moving the elements into their place, centering the text vertically, and defining the image behavior within the slat item container.

.slat__body {
padding: $base-spacing;
@media #{$small} {
position: absolute;
z-index: 2;
top: 50%;
transform: translate( 0, -50% );
// Adjust alignment of content so that is aligns with non-slat content
 max-width: (map-get($breakpoints, large) - $base-spacing )/2;
}
@media #{$large} {
left: 50%;
padding-left: 0;
transform: translate( -(map-get($breakpoints, large) - $base-spacing )/2, -50%);
}
}
.slat__item {
@media #{$small} {
position: absolute;
z-index: 1;
top: 0;
right: 0;
width: 50%;
height: 100%;
overflow: hidden;
}
}
.slat__item img {
display: block;
position: relative;
}

If you have multiple media slats back-to-back, it makes sense to introduce some variation by adjusting the order in which the text and image are displayed. To do this, I am adding a parent modifier class (’.slat--reversed’) which rearranges the order. The following are the styles necessary for this modifier to work:

.slat--reversed {
.slat__item {
@media #{$small} {
right: 50%;
left: 0;
}
}
.slat__body {
@media #{$small} {
left: 50%;
}
@media #{$large} {
transform: translate( 0, -50%);
padding: $base-spacing*2;
}
}
}

View Demo on Codepen

I’ve come to like this component quite a lot due to it’s dynamic and versatile nature. Much like the media object component, it is a foundational element that can be modified to create countless variations.

Design Principles for Reducing Cognitive Load

Mon, 30 Nov 2015 00:00:00 +0000

Every time you visit a website, a process of learning is initiated in the brain. Whether it’s the navigation, layout, or that auto-rotating image slider on the homepage, your brain has to learn how to use the site while keeping track of the reason you came there in the first place. The mental effort required during this time is called cognitive load. Now the catch: the working memory in which this information is processed and stored is limited. Your brain begins to slow down or even abandon the task at hand when it receives more information than it can handle. Although cognitive load isn’t entirely avoidable, designers must strive to manage and accommodate these limits.

What Causes Cognitive Load

To understand how to reduce cognitive load, we must first understand what causes it. Generally speaking, the causes of cognitive load can be traced back to three main factors:

Too many choices
Too much thought required
Lack of clarity

Each of these factors will require processing and takes up mental resources that doesn’t actually help users understand the content.

Methods for Reducing Cognitive Load

Now that we know the factors that increase cognitive load, let’s take a look at how we can reduce it. This is by no means a comprehensive list, but instead a few common principles that can help inform design decisions.

Avoid Unnecessary Elements

Like everything in design, less is more. Any element that isn’t helping the user achieve their goal is working against them because they must process it and store it in working memory, alongside the things that will help them. Avoiding excessive colors, imagery, design flourishes, or layouts that don’t add value is crucial. But simplicity comes with a caveat: don’t overvalue it at the cost of clarity.

Leverage Common Design Patterns

By leveraging common design patterns when it makes sense, you are giving the user familiar elements which they already understand. This in turn reduces the amount of learning they need to do, thus enabling them to move right along and get closer to achieving their goal. My favorite sources for design pattern inspiration are Design Patterns on CodePen and the Blueprint Archives on Codrops.

Eliminate Unnecessary Tasks

Anywhere you are asking the user to read content, remember information or make a decision contributes to cognitive load. Whenever possible, it is good to shift these tasks away from the user and make it easier for them to stay focused on their goal. While it isn’t possible to remove all tasks, there is usually an opportunity to offload some task by setting defaults that can be edited, or leveraging previously entered information. Some companies are even taking this a step further with anticipatory design.

Minimize Choices

As previously mentioned, our working memory is limited. When confronted with too many choices, cognitive load will increase due to decision paralysis. It is important that we minimize the choices the user must make at any given moment, especially in places such as navigation, forms, and drop-downs.

Display Choices as a Group

When choices are split into separate groups and hidden, users often mistake the options that are visible as the complete group. This means that users are likely to never find the additional choices, which not only limits what is available to them, but also makes it more difficult to decide on which option to select because they are not aware of the alternatives. Therefore, it is best to eliminate the resulting cognitive load by always displaying choices as a group.

Strive for Readability

Making our content legible isn’t enough — we need to make it readable. This means our typography must be aesthetically pleasing, appropriate for the content and easy to read while design remains relatively invisible. By doing this, we can ensure there are as little distractions as possible for the user, which results in a better understanding of the content by the user.

Use Iconography with Caution

Research has shown that iconography can be hard to memorize and, contrary to intuition, can increase cognitive load by requiring mental processing to infer meaning or recognize. While universally understood icons work well (ie. print, close, play/pause, reply, tweet, share on Facebook), most are subject to the user’s understanding based on previous experience (in which there is no standard). When leveraging the power of iconography, it is best to accompany them with text labels to communicate the meaning and reduce ambiguity.

By following the principles above, you can drastically reduce the user’s cognitive load and ensure their attention isn’t being wasted on elements that do not help them. It is important to remember that the user has a goal, whether it is to buy a product, understand something or simply to learn more about the content. The less they have to think about what they need to do to achieve their goal, the more likely it is they will achieve it.

Flexbox Myth Busting

Sat, 24 Oct 2015 00:00:00 +0000

If you write CSS with any kind of regularity, then chances are you have heard of ‘flexbox’ (Flexible Box Layout Module). You might have even heard that flexbox can solve many problems that are thought hard or impossible to solve without the aid of Javascript. But you might have also heard or assumed a few barriers to leveraging flexbox this early. In this post I will be debunking many ‘myths’ that surround this powerful layout model.

Myth #1: Flexbox is Slow

CSS Flexible Box Layout Module has undergone a lot of changes since its first appearance in 2009. The specification and what the browsers have implemented has evolved, resulting in multiple versions of the syntax. In 2013, a case study on Smashing Magazine identified performance issues related to the use of the original (legacy) flexbox that used display: box. This performance issue has since been rectified with the newer version which uses display: flex and is 2.3× faster than the older flexbox.

Myth #2: Flexbox Lacks Good Browser Support

Contrary to what some still think, browser support for flexbox is good (83% globally as of late 2015). With full support in the latest releases of every major browser, you can begin to use it in your own work without much worry. In addition, you can support older browser versions by mixing in earlier versions of the flexbox syntax and leveraging browser prefixes.

In many instances, flex box properties can co-exists with non-flexbox properties. This allows you the ability to use floats or table for a base layout and then override these properties with flexbox in supporting browsers. In instances where this will not work, feature detection will allow you to target supporting and non-supporting browsers individually. This approach comes in handy for browsers like >=IE9, where a fallback is necessary as long as you support these browsers (as of late 2015, global support is at ~1% for IE9).

Myth #3: Flexbox is Too Complicated

As with anything new, the flexbox syntax can seem daunting at first glance. Traditionally, developers had to rely on tables, floats, or inline-blocks for the job; all of which were limited and fraught with drawbacks. With flexbox, developers now have a more efficient way to lay out, align and distribute space among items in a container. This is especially handy in responsive layouts where flexibility is a necessity. In order to create this flexibility, we need a more robust way to deal with layout.

But flexbox isn’t too complicated — it’s just a different way to think about layout on the web. Once you get a grasp on how it works, you immediately realize its power. In addition to this, there is no shortage of resources on the web to help you learn the flexbox syntax (check out Chris Coyier’s Complete Guide to Flexbox or this handy tool by Bennett Feely for starters).

As you can see, the barriers to using flexbox in your work now are either nonexistent or are easy to work around. Not only can it be leveraged to achieve things once thought impossible without Javascript, but it can also improve your layout in browsers that support it without affecting older browsers. So go forth and start flex-boxing.

User Testing for Designers

Sat, 17 Oct 2015 00:00:00 +0000

Usability testing is a helpful tool when it comes to informing and validating design decisions. What was once thought of as the responsibility of just information architects or user experience designers is now a tool available to anyone. This is great because the more accessible user test are, the easier it is to incorporate data and analysis into your design process. But it is often a challenge to know what test is the most appropriate, and when it should be leveraged.

Categories of User Tests

There are two categories of user test: those that are moderated, and those that are unmoderated. While both have their benefits, unmoderated test have a number of advantages. Not only are they easier to implement, but they also save time, money, and provide more accurate results in regards to how your design will perform in the wild. For this reason, they are a great fit for designers that need to quickly incorporate user testing into their process without having to coordinate experienced moderators and users that come at a significant cost.

Types of Tests

There are numerous types of user tests, some of which are more useful than others. An important factor in determining the right test is knowing how test work and when they are most effective. Let’s take a look at some time-tested approaches:

Card Sorting

Card sorting tasks participants with sorting ‘cards’ that represent sub-pages or content into categories. This test is useful for creating and testing any taxonomy, particularly navigation. In addition to sorting cards, participants can also be asked to label each category in which the cards are sorted under.

When to Use:

Card sorting is most effective for determining top-level navigation or testing the efficiency of pre-existing navigation against actual users. It’s a good idea to roll this one out early.

Tree Test

Tree test tasks participants with finding information in a clickable sitemap which is represented via a simple tree navigation. By simplifying your information architecture and then asking participants to find specific info, you can evaluate if the structure of your sitemap will make sense to users by measuring time and success rate for each task.

When to Use:

Tree test are most effective for testing a sitemap because it will identify problems with your site hierarchy, which lays the foundation for your content structure. It’s a good idea to roll this one out early as well.

First Click Test

First click test work by examining what the first click is for participants tasked with finding specific information. By asking participants to interact with a working prototype or wireframe of your design, you can begin to get quantitative guidance into how actual users will respond.

When to Use:

First click test are most effective for gaining insight into how users will interact with your design. Therefore, this test is a good one to leverage towards the end of wire framing and during the early stages of design.

Remote Usability Test

Usability test come in a variety of flavors, all of which are engineered to measure the overall usability of your product. These test work by monitoring a larger sample of participants while providing deeper insights into behavior. There are many options available for usability tests, including the ability to monitor participants screens and record articles.

A popular alternative to remote usability testing is “Hallway” Usability test, which comes at a much smaller price tag. This works by asking a random selection of participants* to complete a specific task while you stand back and takes note. The key here is to not intervene with their interaction and to pay close attention to common bottlenecks for participants.

When to Use:

Usability test are most effective once your website or product is stable and is ready to launch, or before and after a major release or update.

A/B Test

A/B test (also know as split test) work by having two variations of the same design in production and then monitoring which one is more performant in regards to a specific metric, which can be anything from clicks to conversions.

When to Use:

A/B test are most effective for comparing relatively small variations against actual users. Therefore, it must be implemented after your product/website has launched.

Once you know what user test is the most appropriate and when they should be leveraged, you have the ability to inform design decisions and free yourself from relying solely on design intuition or subjectiveness. This analytical understanding of how users interact with your product/website will not only improve your work, but it will give you solid reinforcement when justifying your design decisions to clients and stakeholders. In addition to this, user test will give you measurements to gauge success and identifying places that need improvement after launch, ensuring that your work will continue to evolve and respond to users.

Recommended Services

Progressively-Enhanced Breadcrumb Navigation

Sat, 10 Oct 2015 00:00:00 +0000

Breadcrumb navigation is an incredibly useful design pattern: it’s simple, recognizable, and it provides great usability. Traditionally, this pattern allows users the ability to retrace their path through the website, with each ‘crumb’ being a link to a parent page. In this post, we’ll walk though how to build a progressively-enhanced breadcrumb navigation that incorporates dropdown menus for each parent page link to allow easy access to sibling pages.

View Demo

Step 1: Baseline

By starting with baseline experience, we ensure that our component is available in some useable form to all users regardless of browser version, CSS feature support, Javascript feature support, etc.

Base Markup

We’ll start with the markup, which is essentially an unordered list and an additional nested list for each submenu. Let’s take a look:

<ul id="js-breadcrumb" class="breadcrumb">
<li><a href="#">Home</a></li>
<li>
<a href="#" class="breadcrumb__toggle">Grandparent A</a>
<ul>
<li><a href="#">Grandparent A</a></li>
<li><a href="#">Grandparent B</a></li>
</ul>
</li>
</ul>

This will provide us with a clean base to build on. Now let’s move on to base styling:

Base Styling

.breadcrumb {
font-size: 1em;
> li {
display: inline-block;
padding: $base-spacing/2 0;
&:after {
content: "/";
display: inline-block;
margin: 0 $base-spacing/2 0 $base-spacing/4;
color: lighten($base-accent-color, 20%);
font-weight: 300;
}
}
> li > a {
color: lighten($base-accent-color, 35%);
}
@media only screen and (min-width: 40em) {
font-size: 0.825em;
}
}
// Set Indicator state to read media queries with Javascript
.breadcrumb:after {
display: none;
@media (hover) {
content: 'hover';
}
}
.breadcrumb > li:hover > a {
color: white;
}
.breadcrumb li {
position: relative;
ul {
position: absolute;
top: 100%;
left: 0;
left: -9999px;
z-index: 2;
background-color: white;
a {
display: block;
white-space: nowrap;
padding: $base-spacing/2 $base-spacing;
}
}
}

Our base styling for the breadcrumb nav is pretty straight-forward. The basic gists is we align our top-level list items horizontally via display: inline-block and ensure that we apply position: relative to give our nested sub-menus a context. Next, we place the sub-menus under its parent list item with some absolute positioning and hide it off-canvas. For our breadcrumb dividers, we are using generated content (:after) on the top-level list item for some visual separation. This should do it for our baseline breadcrumb nav.

An important thing to note here is the use of the child selector (‘>’), which helps to ensure we are selecting the correct list or list-item. To learn more about this helpful CSS selector, check out the [Mozilla Developer Docs](https://developer.mozilla.org/en-US/docs/Web/CSS/Child_selectors).

The next step is to allow our sub-menus to be toggled by users that can support the necessary Javascript. LetÆs dive in and tackle this one piece at a time:

Base Javascript

We’ll start by testing if the users browser understands the .addEventListener() method — if it does, then it can proceed. If it doesn’t, then it is returned and the rest of the Javascript isn’t read. This means that legacy browsers like IE8 will fallback to our baseline breadcrumb navigation. Additionally, letÆs add an enhancement class to the document element, which we’ll use later for adding arrows to each dropdown.

(function (win, doc) {
'use strict';
// Return if addEventListener isn't supported
 if (!win.addEventListener) { return; }
// Add Enhancement Class
 doc.documentElement.className += ' ' + enhanceclass;
}(this, this.document));

This method of feature testing is known as ‘[cutting the mustard](http://responsivenews.co.uk/post/18948466399/cutting-the-mustard)’, which was popularized by the developers over at BBC News.

Toggling the Active State

Provided that the users browser cuts the mustard, we can then listen for click events on elements with the breadcrumb__toggle class, which will fire the breadcrumbListener() method. This method will prevent the default behavior of the link and then toggle our activated class (‘is-toggled’). By targeting this class in our styles, we can reveal the sub-menus on the ‘crumb’ that has been selected:

(function (win, doc) {
'use strict';
// Store Variables
 var enhanceclass = 'cutsthemustard',
breadcrumbNav = document.getElementById('js-breadcrumb'),
breadcrumbToggleClass = 'breadcrumb__toggle',
breadcrumbHoverClass = 'is-toggled';
// Return if addEventListener isn't supported
 if (!win.addEventListener) {
return;
}
// Toggle className Helper Function
 var toggleClassName = function (element, toggleClass) {
var reg = new RegExp('(\\s|^)' + toggleClass + '(\\s|$)');
if (!element.className.match(reg)) {
element.className += ' ' + toggleClass;
} else {
element.className = element.className.replace(reg, '');
}
};
// Process event on Breadcrumb Nav
 var breadcrumbListener = function (ev) {
ev = ev || win.event;
var target = ev.target || ev.srcElement;
if (target.className.indexOf(breadcrumbToggleClass) !== -1) {
ev.preventDefault();
toggleClassName(target.parentNode, breadcrumbHoverClass);
}
};
// Add Enhancement Class
 doc.documentElement.className += ' ' + enhanceclass;
// Listen for clicks (or taps) in Breadcrumb Navigation
 breadcrumbNav.addEventListener('click', breadcrumbListener, false);
}(this, this.document));

.breadcrumb li.is-toggled ul {
left: 0;
}

We also want to be sure to indicate to the user that the crumbs are able to be toggled. To do this, we’ll leverage the class that was added to our element once the browser cut the mustard and add arrows after each toggle element.

.cutsthemustard .breadcrumb__toggle:after {
content: "";
display: inline-block;
vertical-align: middle;
width: 0;
height: 0;
margin-left: $base-spacing/3;
border-left: 4px solid transparent;
border-right: 4px solid transparent;
border-top: 5px solid lighten($base-accent-color, 35%);
}

Things are looking good so far: we have a baseline breadcrumb navigation for users in less capable browsers, and a toggle-enabled breadcrumb navigation which reveals sub-menus for everyone else. What about making things a bit easier for the user and reveal those helpful sub-menus on :hover instead?

The final enhancement is to reveal our sub-menus when the parent list item is moused over, saving the user some clicks. But there is a challenge here: how do we determine if the user is using a mouse versus if they are on a touch-enabled device, and therefore cannot detect mouse events? You would think that it is as simple as testing if the device is touch-enabled; unfortunately, there is no reliable way to detect touchscreen.

Another approach could be to just reveal the sub-menus with the :hover CSS selector. While this will work for devices that do understand mouse events, it becomes problematic on devices that emulate :hover (which is basically all touch device browsers). This is because emulated hovering has some ugly quirks, including hovered elements staying in the :hover state even after the user stops interacting with it. This would not be an ideal side-effect.

But, what if we could test if :hover is properly supported and provide our enhancement only to those devices that pass? With CSS level 4 media queries we have interaction media features, which includes the ‘hover’ media query. Which provides us a reliable way to query the user’s ability to hover over elements on the page. While the support is not perfect, it is enough for us to confidently implement a solution for browsers that do support it, and have our toggle to reveal fallback there for those browsers that don’t support it. Progressive enhancement FTW.

Query for Hover

Our first step in this last enhancement is to add the hover media query to our styling. This can be applied like a normal media query, but we are passing in hover in the query string. Within this media query, we are simply revealing our sub-menus on each parent list item once they are moused over.

@media (hover) {
.breadcrumb li:hover ul,
.breadcrumb li:focus ul {
left: 0;
}
}

Final Touch

Everything is working great so far. There is just one thing: the top crumb link is being intercepted by our toggle method for users that can properly support hover. This not only prevents the link within from working, but also toggles our menu open if clicked. We can easily fix this by telling our Javascript that hover is supported, and then prevent the event listener on these top level links from being activated. To do this, we can use a pseudo-element on our breadcrumb that is hidden but will have a keyword that can be read in Javascript.

.breadcrumb:after {
display: none;
@media (hover) {
content: 'hover';
}
}

Next, we will write a method that can check this value and see if it matches. In our case, we are checking if the keyword equals ‘hover’. If it does, we can return before the event listener is added to our breadcrumb toggle elements:

(function (win, doc) {
'use strict';
// Return if addEventListener isn't supported
 if (!win.addEventListener) {
return;
}
// Store Variables
 var enhanceclass = 'cutsthemustard',
breadcrumbNav = document.getElementById('js-breadcrumb'),
breadcrumbToggleClass = 'breadcrumb__toggle',
breadcrumbHoverClass = 'is-toggled';
// Remove string quotes to normalize browser behavior
 var removeQuotes = function(string) {
if (typeof string === 'string' || string instanceof String) {
string = string.replace(/^['"]+|\s+|\\|(;\s?})+|['"]$/g, '');
}
return string;
};
// Get value of body generated content
 var checkBreadcrumbMedia = function() {
var media = window.getComputedStyle(breadcrumbNav,':after').getPropertyValue('content');
return removeQuotes(media);
};
// Toggle className Helper Function
 var toggleClassName = function (element, toggleClass) {
var reg = new RegExp('(\\s|^)' + toggleClass + '(\\s|$)');
if (!element.className.match(reg)) {
element.className += ' ' + toggleClass;
} else {
element.className = element.className.replace(reg, '');
}
};
// Process event on Breadcrumb Nav
 var breadcrumbListener = function (ev) {
ev = ev || win.event;
var target = ev.target || ev.srcElement;
if (target.className.indexOf(breadcrumbToggleClass) !== -1) {
ev.preventDefault();
toggleClassName(target.parentNode, breadcrumbHoverClass);
}
};
// Add Enhancement Class
 doc.documentElement.className += ' ' + enhanceclass;
// Fire checkMedia to get value
 checkBreadcrumbMedia();
/**
 * Do nothing if pointing device can relay a hover state
 * Else, attach event listener to breadcrumb
 */
if ( checkBreadcrumbMedia() === "hover" ) {
return;
} else {
breadcrumbNav.addEventListener('click', breadcrumbListener, false);
}
}(this, this.document));

The `removeQuotes()` method is necessary here in order to normalize what our output of the checkBreadcrumbMedia() method returns. This is due to the fact that some browsers return double-quotes, while others return single-quotes.

All done! Here is the final result:

Progressive-enhancement is a great way to add functionality to your components in layers that can build on top of each other, all the while providing fallbacks to browsers that don’t support the necessary features. We have used this methodology to create a breadcrumb navigation that leverages all the usability of the pattern, and then enhances it with additional functionality. In this case, we are allowing for sibling pages to be easily accessible via dropdown menus at every level, but ensuring that a baseline experience is available for less capable browsers.

Front-End Principles for Designers

Sun, 23 Aug 2015 00:00:00 +0000

Designers that code is becoming increasing common in the web community; and while not a requirement, this skill can have an substantial effect on the quality of the designer’s work. Is that to say that a designer must know how to code to create great digital experiences? This mind set is dogmatic and fails to ask the right question, which is what principles do designers need to understand to create better designs?

Let Go of Control

It is the nature of the web to be flexible, and with this flexibility comes a degree of letting go of control. The first step in this process is to leave behind the idea of pixel perfection: our medium is fluid and our decisions must be made with this in mind. It is absurd to design comps in Photoshop and then print them out in all their pixel-perfect detail in order to critique or present them as if they were posters.

Avoid Too Much Variation

Variations of elements can grow during the design process, particularly with things like color, type sizes, and spacing. When there is too much variation, the CSS can become bloated with edge-case styling that results in a file that is difficult for the developer to author and maintain. This problem can be amplified on a larger project and result in a negative impact on page performance. The solution is simple: audit your design and ensure that variations are kept to a minimum by distilling them down to a few common values.

Keep Performance in Mind

Performance is an essential design feature, not just a technical best practice. It is imperative to make performance part of your design workflow from the beginning and not an afterthought. There are lots of things designers can do to design for performance, including setting a performance budget, embracing conditional loading, eliminating unnecessary downloads, using SVG in place of raster graphics, optimizing images and encouraging your development team to adopt a responsive image strategy. By prioritizing performance and educating others on your team, you ensure that the end result is not hampered by a slow experience.

Understand Source Order

Source order refers to the order in which elements are displayed on the page based on where they appear in the HTML. Elements will display from top to bottom and left to right by default — their width being determined by their display property. While it is easy to position elements outside the flow of the document with CSS, changing the order in which elements appear inside the flow of the document is a bit more difficult and has some limitations. The natural source order should guide you when thinking about how your design will adapt to various viewport widths. If you need to change this, be selective and have a good reason.

Know Your Numbers

It can be quite frustrating to see a project in production with elements not appearing as you intended. From type sizes and general spacing to grid values, your design is full of numbers that you should be intimately aware of. If your development team is using a framework, then you should know the default values of this framework’s styles and the options available when changing them. If your project is platform specific, then you should be an expert on that platform’s DPI and other specs. By knowing your numbers, you can speak more knowledgeably when communicating these details to your development team.

Let Content Determine Breakpoints

Determining breakpoints based on popular device dimensions or common screen resolutions is like building a house on a sandbar: the landscape is always changing and making decisions on what’s there today is inherently flawed. It makes much more sense to let content determine breakpoints instead of basing these values on a few devices or resolutions that are relevant today.

Maintain Consistency

Consistency is the key when creating an environment that is easy for users. It will ensure that there is a common design language, which makes development easier because there are fewer edge cases that the developer must account for. It is important to always audit your designs for consistency and to reduce one-off solutions whenever possible.

Communicate Early and Often

The most important principle when working with developers is to communicate early and often. Being proactive and finding out what they need, including them in on design decisions, and taking into consideration any technical restraints they point out is essential for a successful collaboration. Remember: the development team shares the same goal in that they want the best possible experience for the user.

By keeping these principles in mind, not only will your designs improve but the result can have a chain reaction effect: better designs mean less back and forth with the development team, which can lead to more time on features that enhance the experience of the user. A better user experience will lead to happier users, and this will reflect back on the client. And finally, happier clients can lead to more great projects.

Responsive Image Workflow

Sun, 09 Aug 2015 00:00:00 +0000

The average website weighs in at 2.16 megabytes and growing, with the majority of downloaded bytes being attributable to images. It is safe to say that the web has quite the weight problem and images play a significant role. While there are a number of steps that can be taken to reduce this weight, perhaps one of the more important steps is to ensure that a responsive image solution is in place. By leveraging a responsive image solution, we can ensure the best image is being loaded and bandwidth isn’t being wasted due to excessively large images. This is where the ‘picture’ specification comes in: a client-side solution for delivering alternate image data based on device capabilities. By leveraging the tools made available by the ‘picture’ specification, we now have a standardized responsive image solution that we can put into practice today.

tl;dr

Breakpoints should be determined by your content and not device-specific widths
Define image dimensions in relation to breakpoints
Calculate pixel density factors and add these to your image list
Consolidate image list to a more manageable length by eliminating values that are too close
Leverage automation when outputting your various image sizes
Utilize the srcset and sizes attributes to switch out a different source of the same image in order to respond to size and pixel density factors
Picturefill allows us to leverage the power of these attributes today
Although the polyfill has some potentially downsides, they are outweighed by the benefits

Define

The first step is to define the image dimensions and related breakpoint of each image which you plan to apply a responsive image solution to. A working prototype of your webpage with actual content is needed to accurately identify this information. It is important to note that your breakpoints should be determined by your content, not device-specific widths. The reason for this is because the device landscape is constantly changing; therefore, today’s popular device dimensions are always in flux. By letting the content determine where breakpoints will take effect, we are ensuring that our interfaces look and function on any screen instead of just a few arbitrary displays.

When determining which images qualify for a responsive image solution, please remember that the most appropriate images are those that are in the content, i.e. the images that are part of the HTML, and not images in which the [background is defined in CSS](http://www.smashingmagazine.com/2013/07/simple-responsive-images-with-css-background-images/).

Image Dimensions

Start by scaling your browser window out to it’s maximum size (or to the point at which you have defined a max-width to constrain the overall width of your content). Then, document the max-width of your content and the width of the image as it appears on the screen using developer tools or a similar browser extension.

Next, scale the browser window down until you reach the next breakpoint that affects the image. At this point, you should document both the breakpoint value and the width of the image. Continue scaling down and documenting each breakpoint and the corresponding width of the image until there are no longer breakpoints that will affect the image. When you are done, you should end up with a list similar to this for each image (with your values of course):

[max-width] : [image width]
[breakpoint large] : [image width]
[breakpoint medium] : [image width]
[breakpoint small] : [image width]

An important note regarding breakpoints: the more breakpoints you have, the harder the code will be to maintain. In addition to this, an excessive amount of breakpoints could result in bloated CSS. Therefore, its best to keep these at a minimum and consolidate them wherever possible.

Hi-DPI

The next step is to calculate the width of each image multiplied by the pixel density factors that you plan to support. Deciding on what range of pixel density factors that should be supported can be difficult not only because there are so many (and the list is growing), but support for each multiplier will introduce an array of additional images that you must create and define in your responsive image solution. The best thing to do here is to be pragmatic and make a decision based on what’s best for your users.

Our list should look similar to the following once we have calculated our supported pixel density factors:

[max-width] : [image width], [image width x1.5], [image width x2]
[breakpoint large] : [image width], [image width x1.5], [image width x2]
[breakpoint medium] : [image width], [image width x1.5], [image width x2]
[breakpoint small] : [image width], [image width x1.5], [image width x2]

Consolidation

As you can see, our image size list is growing and will get even larger with more pixel density factors and breakpoints. It makes sense at this point to consolidate the list to a more manageable set of values, e.g. any values that are the same or do not have a difference of more than ~200px. When there are two values that are less than this amount apart, eliminate the lesser value. Here is an example list that clearly illustrates our values once it has been consolidated:

(min-width:1280px) : 1040px, ~~1560px~~, 2080px
(min-width:1120px) : ~~924px~~, 1386px, 1848px
(min-width:800px) : 800px, ~~1200px~~, 1600px
(min-width:400px) : 400px, 600px, ~~800px~~

I am using pixel values for the breakpoints in the example above to clarify the correlation to image width, but in practice your [breakpoints should be relative units](http://bradfrost.com/blog/post/7-habits-of-highly-effective-media-queries/#relative).

Output

Now that we have a consolidated list of image widths, the next step is to export each image with a naming convention that identifies both the breakpoint and the multiplier; for example: I have nicknamed my next to largest breakpoint ‘large’ and the multiplier is 2x, so my file name will be ‘image_large@2x.jpg’. I like to save images for web from Photoshop at ~70% quality to ensure maximum optimization without losing image quality (this will vary based on the image — the goal here is to find lowest quality setting without degrading the finer details of the image). If you are saving as JPEG, be sure that the image is visible as soon as possible for the user by selecting the ‘progressive’ image format.

Actions

One method to save out varying image sizes is to use predefined actions that will automatically save your image to the sizes you need. This sort of automation can easily be done in your design program of choice. Unfortunately you will still need to manually rename each image with the relevant breakpoint name and modifier. If you use Photoshop, here is a guide to setting up your own actions in Photoshop, or of course you can utilize predefined actions.

Build Tools

Another method of automating the export of images is to leverage a build tool, my favorite being Gulp. Gulp is a javascript streaming build system that keeps things simple and makes complex tasks manageable by leveraging the power of Node streams. There are plugins for every imaginable task, including image resizing and file renaming. With a little configuration, you can fully automate this portion of the workflow and never have to think about it. An added benefit to utilizing a build tool such as Gulp is that you can chain additional tasks and configure the sequence in which they need to occur.

Optimization

Finally, its important to remember to optimize your images before implementing them into your page. This will ensure that any image data that can be removed or simplified is done, resulting in significantly smaller image files. Similar to the process of resizing images, there are multiple ways to handle this task: you can manually optimize images via an app or console tool, or you can leverage a build tool to automate this task. My favorite image optimization apps are ImageOptim for JPGs and ImageAlpha for PNGs, but there are several others to choose from. Alternatively, you could leverage the power of automation via a build tool, which is great because you don’t have to remember to optimize — you simply configure the tool to do this for you every time there is a new image in your project. I like to use the Gulp plugin imagemin, which can also optimize SVG and GIF files.

Implement

The final step is implementation. Our use case will be what’s known as ‘resolution switching’ because we are simply switching out a different source of the same image in order to respond to size and pixel density. Therefore, we will make use of the the srcset and sizes attributes, which are part of the picture specification. These attributes extend the <img> and <source> elements to provide a list of available image sources and their sizes in which the browser can then use to pick the best image source. We are essentially providing the browser the information we do know, and letting it determine the most appropriate image in response to factors that are unknown, e.g. pixel density of the user’s device, bandwidth, etc.

Srcset Attribute

Let’s begin with srcset. First, we will provide a fallback image in the ‘src’ attribute in the case the browser doesn’t understand the srcset attribute — an image that’s roughly in the middle of your image list is sufficient. Next, we will target the <img> tag that will contain our image information and add the ’srcset’ attribute. Then we will list each image from smallest to largest in a comma-separated list, with each image source followed by the width of the image that we documented in the previous step and followed by the width descriptor (‘w’). The result should look similar to the following (with your values of course):

<img src="image_medium.jpg"
srcset="image_small.jpg 400w, image_small@1.5x.jpg 600w, image_medium.jpg 800w, image_xlarge.jpg 1040w, image_large@1.5x.jpg 1386w, image_medium@2x.jpg 1600w, image_large@2x.jpg 1848w, image_xlarge@2x.jpg 2080w"
alt="Image description" />

Now we have a image with a list of available sources, each with information that the browser can use to determine the best choice, along with a fallback image and alternative text. If srcset is supported, the browser will download only the image it calculates is most appropriate for the user’s device, otherwise it will load the fallback image. Thus, the chances of wasted bandwidth and the resulting page bloat is significantly reduced.

Note: there is also a ‘resolution’ descriptor available to the srcset attribute, which allows you to define alternative image sources based on pixel density factors. While this simplifies the amount of sources you have to define, it will limit the options for the browser. Also note that the width and resolution descriptor do not mix, so you must chose one or the other.

Sizes Attribute

We can provide the browser with additional information to help it determine the best image by also leveraging the sizes attribute. This isn’t completely necessary for srcset to work — the browser will still parse though the information provided in the srcset attribute and select an image, but it will assume that the image is suppose to take up the full width of the viewport. This can obviously lead to unwanted results, so its probably best to provide some information here:

<img src="image_medium.jpg"
sizes ="(min-width:1120px) 924px, (min-width:1280px) 1040px, 100vw"
srcset="image_small.jpg 400w, image_small@1.5x.jpg 600w, image_medium.jpg 800w, image_xlarge.jpg 1040w, image_large@1.5x.jpg 1386w, image_medium@2x.jpg 1600w, image_large@2x.jpg 1848w, image_xlarge@2x.jpg 2080w"
alt="Image description" />

The above example is telling the browser that at a minimum-width of 1120px the image should be 924px wide, and at a minimum-width of 1280px the image should be 1040px wide. Otherwise, the image should take up 100% of the browser window.

The browser will then use this information to further aid it in selecting the appropriate image source for the user. You can get as detailed as you want here by listing each breakpoint and the corresponding width of image (which can obviously result in duplicated layout info), or you can keep things relatively generic. The point is the more information the browser has, the better it can determine the right image source.

Art-Direction Use Case

The srcset and sizes attributes will cover most use cases. Alternatively, there is the possibility that you need to modify the images, e.g. crop images differently at each size, which is known as the art direction use case. If each version of an image needs to be different, you will want to use the <picture> element, which is part of the same specification as srcset. Which responsive image method you chose depends entirely on the use case. To learn more, read Jason Grigsby’s article explaining the details.

Support

Browser support for the srcset and sizes attributes is gaining traction but for most projects you will need to go a bit deeper. Luckily, there is an excellent polyfill called Picturefill which provides cross-browser support for the <picture> element and associated features (this includes srcset). This polyfill allows authors to use the recommended picture syntax, therefore enabling them to remove the polyfill once deeper browser support is available. Although the polyfill has some potentially downsides, they are outweighed by the benefits.

Note: When using picturefill, it is recommended that you leave off the ’src’ attribute in order to prevent some users from experiencing [double-downloads](https://www.filamentgroup.com/lab/to-picturefill.html).

Smarter Tabs

Thu, 23 Apr 2015 00:00:00 +0000

The task of building adaptable UI components in responsive web design can be quite tricky due to fact that we cannot always predict how the content within any given component will change over time. By building ‘smarter’ components, we can make our UI more adaptable to these conditions.

The Content Predictability Issue

Let’s take for example the common tabs component: a simple yet effective way to display lots of content within a condensed amount of space. If you know the exact amount of content that the tab will hold and can be certain it will not change, you can easily apply different styling to ensure the tabs (and its content) always look good by leveraging CSS media queries. This approach works great in most instances, but what if we cannot control the amount of content the tabs will hold? By relying on specific breakpoints and responding to them with CSS media queries you can maintain this unpredictability up to a point, but eventually the tabs component will break.

A Potential Solution: Smarter Components

One way to deal with this content predictability issue within our components is by making them smarter. Let’s take our tabs example: if we can monitor when there is enough room to fit the tab links that display the content, and do so without the use of CSS media queries, then we can decouple the tabs component from explicit breakpoints.

Let’s take a look at our example:

By resizing the browser, you can see that our component starts as a simple accordion at smaller viewports. When there is enough space to fit the tab navigation, the nav links become visible and the component switches to tabs. This is being done without the use of media queries, so you can add or subtract content from the component and this behavior will remain the same! The advantages of this approach becomes apparent when you begin to think about tabs that are being maintained by clients via a content management system, etc.

How It Works

Here is the general gist:

Create clean, semantic markup that will serve as the baseline experience and progressively enhance based on if the necessary Javascript features are available.
If Javascript is available, initialize the function which contains our various methods that power the tabs component and change the class name on the <html> element from .no-js to .js. This class will serve as a hook in which we can begin CSS enhancements knowing that the Javascript has our back.
Use CSS to hide the body content for each tab and then display it if the parent tab content element has the class we will be using to indicate an active tab. The trick here is to qualify this CSS with the class we are using to indicate Javascript is available, which can be done as follows:

.tab__body {
// If necessary JS features are available
 .js &amp;amp; {
display: none;
}
// If parent has active class
 .is-active &amp;amp; {
display: block;
}
}

At this point the tabs component enters into its ’accordion’ phase: if a click event is detected within our tabs component and it is on any tab header, then we will toggle the tab content associated with that header and remove the active state from any siblings to ensure only one tab is active at a time.

Another important event to happen during this phase is the creation of the tab navigation, which happens automatically to ensure the navigation is available if needed. This navigation is created via our createNav() function, which works by looping through all headers in each tab content section and creating links that contain href values based on its parent container’s ID attribute. We are then inserting this navigation within the tabs component and allowing CSS to hide it until needed.

Next, we will check to see if the tabs navigation that was created dynamically is narrower than the tab container. By firing this function immediately and then checking on page resize via a throttled function, we are ready to add our final enhancement class to the parent component if the conditions are right. When they are, we add our enhancement class and let CSS take care of the rest by hiding all tab headers and displaying the navigation. Thus, we have our fully enhanced tabs component, and when a tabs link is clicked we can toggled the corresponding content.

Potential Drawbacks

Taking this approach certainly has its limitations: We are limited on how we can style the tabs because we must be able to read the total width of the navigation, thus it must shrink to wrap its children links and cannot be 100% width (which would prevent an accurate width to compare to the total width of the tab parent). With that being said, this small styling sacrifice is ok when you are trading it for reliable behavior and reasonable fallbacks across all browsers, or peace of mind when it comes to an undetermined amount of content.

Product Detail Gallery Component

Sun, 15 Mar 2015 00:00:00 +0000

The ability to quickly toggle a variety of angles of a single product is a quite common feature on modern e-commerce websites. It allows users to see various details of a product, and often times even zoom in on a particular area of the product before potentially adding the product to their cart. In addition, a component such as this should should be as self-contained as possible and also easy to maintain.

How It Works

The way our component works is quite simple when broken down: first, we listen for any clicks on anchor tags from within our gallery component via javascript event delegation. When an anchor tag has been clicked, the default behavior (go to what is in the href value) is intercepted and prevented via event.preventDefault(). Next, the value of the anchor’s data-attribute is stored in a variable which we use to call the appropriate method, along with references to the necessary elements. These references will be passed to the method call so we can use them later. The next step is to fire the appropriate method based on which kind of anchor tag was clicked: if the anchor’s data-gallery attribute was ‘zoom’, we will fire the .zoom(); if the data-gallery attribute was ‘thumb’, we will fire the .switch().

.zoom()

Starting with our ‘.zoom()’ method: we will store the original height of the main section in a variable via jQuery’s .outerHeight() method, as well as the ‘src’ attribute of the hero image. This method then does one of two things, based on what the ‘src’ value: a) set the hero image container height so that the container will not change when the image is replaced, switch the image to a larger version, add a ‘is-zoomed’ class on the parent element, and then initialize the .draggable() method to enable the enlarged image to be draggable within the container (via jQuery UI); or, b) remove the set height on the container (this will restore the height relative to the ‘normal’ image), change the image ‘src’ attribute to the original, and remove the ‘is-zoomed’ class on the parent element.

The basis for how this works is to have the same image in three separate directories, each directory reserved for what size the image is: thumb, normal, and zoom. By naming the image the same and placing them in these different directories, you can easily change the directory name in the src attribute to change the image.

.switch()

Next is .switch(), which will change the hero image based on the thumbnail that is selected. This is done by storing the target image’s url in an anchor tag that wraps the smaller thumbnail image. When the thumbnail is clicked, the hero image is changed by replacing the src attribute of the image with the url.

We start by storing the necessary values as variables. Next, we will add a class of ‘is-active’ to the target thumbnails wrapping anchor tag so we can styling it differently from the other thumbnails. If any of the other thumbnails have the ‘is-active’ class, we will remove it by looping through each anchor tag that wraps the thumbnail images. If the parent .gallery element has the ‘is-zoomed’ class, we will remove it and also reset the height on the wrapping element of the hero image. Finally, we change the hero image’s src attribute with the value that was stored in the anchor tag that wraps the target thumbnail.

And there it is — simple, efficient and easy to maintain. This component serves as a great foundation that can be further enhanced and customized.

Category-Specific Tags List in WordPress

Thu, 08 Jan 2015 00:00:00 +0000

Listing tags in WordPress is relatively easy to do with the get_tags() template tag, but finding tags for a specific category (or multiple defined categories) can be quite challenging. The following does just that, while avoiding duplicates.

<ul>
<?php
$query_args = array(
// Define Category via ID or slug
 // You can list multiple categories via comma separate list
 'category__in' => array( 'category-name' ),
// Grabs ALL post
 'posts_per_page' => -1
);
$query = new WP_Query( $query_args );
$posttags: "";
while( $query->have_posts() ) {
$query->the_post();
if( get_the_tag_list() ){
$posttags: $posttags . get_the_tag_list('',',',',');
}
}
// Reset
 wp_reset_postdata();
// Explode tags in array
 $sortedtags: explode(',', $posttags);
// Sort array
 asort($sortedtags);
// Remove duplicates from array
 $sortedtags: array_unique($sortedtags);
// Remove the blank entry due to get_the_tag_list
 $sortedtags: array_values( array_filter($sortedtags) );
// Wrap each tag in list element
 foreach ($sortedtags as $tagname) {
echo '<li>' . $tagname . '</li>';
}
?>
</ul>

The New Nativeyewear.com

Sat, 16 Aug 2014 00:00:00 +0000

There are occasionally projects that come along and teach you so much that it takes a while for you to process all that your have learned. The redesign of Nativeyewear.com was very much this sort of project for myself and my colleagues. The following is an attempt to capture and reflect on the lessons I learned through the duration of this project and to highlight some key decisions that helped to make this a successful project.

1. Research

Like any project, we kicked-off things by digging in and doing some serious research. Doing your homework up front is not only crucial to understanding the goals and objectives of the project, but helps to build a solid foundation of knowledge that can be pulled from throughout the process. With that said, its important to have defined objectives for your research. Here are a few that we focused on:

Project Goals

Establishing the goals for a project early on is vital. We began by defining improvements that should be made over Native’s™ previous website in regards to functionality, content and maintainability.

Analytics

We made sure to pay close attention to the site analytics of Native’s™ previous website and documented key data that would help inform our decisions in the planning phase. This included data related to user devices, browser versions, and operating systems. This documentation would be prove to be invaluable.

Define Your Audience

During our initial research we also sought to define who was the target audience for Native’s™ product and engrain this into our thinking moving forward.

Inspiration

The research phase is a perfect time to really explore different approaches and get inspired. We spent a large portion of our research simply documenting web experiences that we really liked and were inspired by and then sharing them. By doing this our team began to collectively envision the possibilities which would serve as plenty of creative fuel moving into the next phase.

2. Planning

The next phase of the project was the planning phase. This was the most critical phase in the process because it would lay the foundation for the entire project moving forward. We made sure to really take our time and get the planning right by iterating over the following:

Site Map

We started by defining a general architecture for the website. By getting everyone in a room, working through this on a whiteboard, and then later refining and tweaking the site map, we were able to quickly define what pages and by extension what content we could expect on the website. This step was key in defining what the site would generally involve and also helped to establish a sense of collaboration between the client, our design team, and the development team early on.

User Flows

The next step was to define key user flows in order to clarify the journey that the user would take and to help our team really wrap our heads around the experience of the user. We quickly discovered that by spending time on user flows, important aspects that might not be initially considered became apparent.

Wireframes

The last step of the planning process was to dive into wireframes and begin to prototype the website’s general architecture. We decided early on to adopt a more interactive wireframe process — one that could be interacted with and would serve as a testing ground for ideas during the design phases.

View the Native™ Interactive Wireframes.

Mobile-First

We knew that we wanted to adopt a Mobile First strategy so that the end result is an experience focused on the key tasks users want to accomplish without the extraneous detours and general interface debris that litter today’s desktop-accessed web sites. The advantages to this strategy are numerous, but it means a slight shift in thinking — and also means it should be adopted early.

Collaboration

It is important to work collaboratively with not only your team, but other teams involved in the website from the very beginning — this includes the client, the development team, UX team, etc. We made sure to bring everyone to the table early on and then continually keep them involved by showing them progress. This approach keeps everyone invested in the project and instills a sense of ownership.

3. Design Exploration

The next step in our process was to begin a design exploration to establish general look and feel, which essentially would be done for client approval. While this was the least agile phase in the whole project, it was vital for the design team to be able to remain flexible and accommodate expectations on the part of the client and our project managers. We soon found a middle-ground where only a few key pages would be addressed for this purpose. Parallel to this step, we continued to refine our live wireframes and even use them to prototype interactions and features. During this phase, there were two key themes that we adhered to:

Stay Nimble

During the initial design exploration it is important to stay nimble and not get too tied to specific features or functionality. The purpose of this phase is to establish aesthetics.

Keep the Development Team Involved

It is paramount to keep the development team involved early and often — this includes even initial design exploration. A good developer will not only be able to spot potential issues but can provide insight and suggestions that will enhance the experience of the user.

Style guides are key: they allow designers to really refine design aesthetics, document all the states of a component like a button or a form input without bloating design files, and they serve as a constant reference for the design team which will help to keep design consistent.

Upon client approval on a specific design aesthetic, we moved into the design refinement phase. This phase of the project was longest, and there were many moving parts. Going into this phase, we knew a few things we wanted to do: 1) Focus design around ‘templates’ instead of the more traditional and inefficient process of designing around every single page in addition to mobile and tablet designs, and to 2) create an interactive style guide to document and refine design components. We dove in after establishing these guidelines but quickly discovered a few key things:

Focus on one key component at a time

It is easy, when focusing on the larger picture, to oversee subtle but often crucial details of a specific component. Our team made sure to go back and to micro-focus on individual components throughout the site, and made sure we explored and evaluated all possibilities before deciding on an approach to that component. A great example of this would be the product modules on the main product pages: we explored every potential way to lay these out and weighed the implications of this before landing on a definitive solve.

Style Guides

Style guides are key: they allow designers to really refine design aesthetics, document all the states of a component like a button or a form input without bloating design files, and they serve as a constant reference for the design team which will help to keep design consistent. In addition to this, they are an immense help to the development team, which can use the style guide to pull assets and reference details established by the designers. An added bonus: they will come in handy for many projects to come!

View the Native™ style guide.

5. Support

The final phase before launching the website was support and refinement. We continued to refine design components and address feedback while the development team took on the heavy lifting. It was important for us, as the design team, to stay involved with the development team and have regular check-ins after development sprints. These check-in served to address any feedback that the development team had. In addition to this, there were a few things we didn’t plan for that became key during this phase:

Things Will Change

There will inevitably be things that will need to change from the original designs, as any web project will have details that were missed in the initial stages. It is important to remain fully engaged and to be available to address any issues that might arise. Which brings me to the next thing:

Stay Engaged

The last phase of any web project is often hardest to stay as focused as you were in previous phases. It is important to keep in mind the project isn’t done (even after launch), and you must stay on your toes.

In Conclusion

The above is a breakdown of each phase throughout the project, but there were some themes that were constant in each phase. These are general points of advice that come in handy for any project.

Communication is key

The more you communicate with your team and other teams involved in the project, the easier it will be to effectively solve problems that arise.

Collaboration

The project’s success hinges on all team members taking ownership, and ownership is cultivated through collaboration. Collaborate early and often.

Be Proactive

During this project there were many times which being proactive and doing things without being asked to do them was very beneficial.

Never Settle

It can be tempting to settle on your first solve in regards to a UI component’s design when there is lots to do — always take the time to really think through key elements in isolation.

Stay Flexible

A key attribute that our team constantly exhibited was the ability to remain flexible. This is key because there will always be unexpected obstacles, and how you can adapt to them can determine the projects success.

Go with the Flow

There were times during the project when it was necessary to slow down and let other team members lead particular parts of the project. While it can be hard step back, it is part of the natural cycle of the project — if you go with the flow, things will go much smoother.

CSS Accordions

Sun, 16 Feb 2014 00:00:00 +0000

The content accordion: a design pattern that is fairly ubiquitous on the modern web. Traditionally this sort of thing has relied on Javascript, but developers are increasingly able to use CSS for components such as these due to the introduction of advanced selectors, transitions and animations. If your target browsers support these advanced CSS properties, then you also have the option to rely entirely on CSS for this design pattern. The following is a deep-dive into the various techniques you can use when building a content accordion, as well as a few pros and cons associated with each approach.

CSS content accordions are not new but until recently they had to rely on the :target pseudo-class. This did the trick (to an extent) but came with numerous drawbacks, including the inability to have multiple expanded panels or the ability to toggle the same panel open and closed. Another nasty side-effect of this approach is that after interacting with the accordion and then hitting back button in the browser, it would toggle the last state in your accordion instead of navigating you to a previous page.

This is where the :checked pseudo-class comes in. By using the [:checked pseudo-class](:checked pseudo class” href="https://developer.mozilla.org/en-US/docs/Web/CSS/:checked) instead, these issues are no longer a problem. Browser support for this selector is not as deep, but non-supporting browsers such as Internet Explorer 8 are losing fans very, very fast. For Internet Explorer 9+ and all modern browsers this selector is fair game. So, let’s get started!

Technique 01: Radio Input Hack

The premise of this technique is to utilize a hidden radio input and a corresponding label tag. The label tags will serve as the headers for each panel within the accordion, and when clicked will give it’s hidden input a ‘:checked’ pseudo-class. Once an input has this class, we can use an adjacent sibling combinator to apply ‘conditional’ styles to the next element. In our case, this next element will be our accordion content.

We start with our markup which is made up of our parent container, and then each panel consisting of a radio input, a corresponding label tag, and then finally the content for that specific panel in the accordion. One important thing to note is that each panel in the accordion is wrapped in a div (it will become apparent why this is soon):

<div class="accordion">
<!-- Panel -->
<div>
<input type="radio" name="panel" id="panel-1">
<label for="panel-1">Panel 1</label>
<div class="accordion__content">
<h2 class="accordion__header">Header</h2>
<p class="accordion__body"></p>
</div>
</div>
<!-- Repeat for Additional Panels -->
<div>...</div>
</div>

Next up is to apply the CSS, which will enable the accordion behavior we want:

/* Basic Accordion Styles */
.accordion {
/*
 * Hide radio input
 */
input[name='panel'] {
display: none;
}
/*
 * Basic Label styling
 * 1. Apply relative positioning for absolute positioned toggle indicator
 * 2. Ensure cursor is a pointer
 */
label {
position: relative;
display: block;
cursor: pointer;
/*
 * Label toggle indicator: normal
 */
&:after {
content: '+';
position: absolute;
right: 1em;
}
}
/*
 * Label toggle indicator: toggled
 */
input:checked + label {
&:after {
content: '-';
}
}
/*
 * Basic panel content styling
 * 1. Hide content
 * 2. Apply relative positioning
 * 3. Apply transition property for smooth toggling
 */
.accordion__content {
overflow: hidden;
height: 0px;
position: relative;
transition: height $timing $ease;
}
}
input[name='panel']:checked ~ .accordion__content {
height: 150px;
}

This is the basic CSS that will enable the accordion to work properly. By adjusting the height on the panel content, we are able to animate that content open using the adjacent sibling selector on your hidden radio input. The div’s which wrap each panel will keep the any panel content outside of the one the user has toggled from opening. With some extra styling, you can quickly have a CSS-only content accordion:

Advantages:

An open panel will close when another has been opened, therefore keeping the amount of visible content limited.
Panel animations can be fully controlled.

Disadvantages:

The panel content must be set to a fixed height and must be maintained in order for content not to overflow the container.

Technique 02: Checkbox Hack

The checkbox hack technique is identical to the radio input technique above, but instead uses checkbox inputs as opposed to radio inputs. Therefore, the only difference in regards to code will be the markup:

<div class="accordion">
<!-- Panel -->
<div>
<input type="checkbox" name="panel" id="panel-1">
<label for="panel-1">Panel 1</label>
<div class="accordion__content">
<h2 class="accordion__header">Header</h2>
<p class="accordion__body"></p>
</div>
</div>
<!-- Repeat for Additional Panels -->
</div><!-- .accordion -->

Here is our more styled output:

Advantages:

The ability to toggle multiple panels open.
Panel animations can be fully controlled.

Disadvantages:

The panel content must be set to a fixed height and must be maintained in order for content not to overflow the container. * Note: The fixed height is still a problem here, but notice how I am using classes to set small, medium, and large sizes in the advanced example. This gives us a little more control over the fixed height issue.

Technique 03: Checkbox Hack Using Max-Height

By now, you are probably noticing a pattern here. You are also probably noticing that there is a weak point with CSS accordions, and that is in regards to the need to set fixed heights on the panel content. A fixed height is needed in order to animate the panel content open, but prevents the panel content container from expanding and shrinking to fit its content. One way around this is to control the height of this content using the max-height property instead. The following is the code which will change between this technique and technique 02:

/* Panel Content */
.accordion__content {
overflow: hidden;
max-height: 0em;
}
input[name='panel']:checked ~ .accordion__content {
max-height: 50em;
}

By setting the content’s max-height to a relative unit and then changing that once the label is clicked, we ensure that the content isn’t constricted to a fixed height. This makes it a more flexible solution, and the code is easier to maintain because we do not have to create additional classes to control various lengths of content. But there is a downside to this technique as well: when animating max-height or max-width, there is a slight delay in the animation as though the element was already that size you set to start with (in our example, 50em). I have also found it makes animations feel more linear, even if they were set in a more dramatic easing.

Advantages:

The ability to toggle multiple panels open.
Panels are not restricted to a fixed height, making them more flexible.

Disadvantages:

A slight delay in the animation occurs, which affects how the accordion feels overall.

Technique 04: Checkbox Hack Using Overflow: Auto

Our final technique is identical to those above, with the only difference being that the overflow property on our content container is set to ‘auto’. What this essentially does is allow for any content that extends beyond the fixed height of the containers to be scrollable. These scrollbars can be styled to fit the styling of your accordion and ensure a) animations occur as you expect, and b) content will not be limited to a fixed height.

Advantages:

The ability to toggle multiple panels open.
The ability to set fixed heights on panel contents containers while allowing overflowing content to scroll.
Panel animations can be fully controlled.

Disadvantages:

The addition of a scrollbar when content extends beyond the height of its fixed-height container.

And there we have it: a collection of CSS-only accordions techniques and how to use them.

Page Perception

Sun, 09 Feb 2014 00:00:00 +0000

The web has evolved. What began in 1989 as a means to share information automatically between scientists in universities and institutes around the world has transformed into a vast digital ecosystem rich in interactivity and immersive experience. The web has reshaped the way we communicate, work, innovate and live, and in the process grown more and more complex. With this complexity has come the need for designers to evolve their processes and tools beyond that fit for the printed page, and while doing so shift our perception of a web consisting of ‘pages’ to one comprised of components.

There was a time when designing web ‘pages’ made sense: not only were the capabilities of websites limited, but so too were the devices which could connect to the them (consisting primary of those with large screens). In other words, [] The Mobile Web](http://en.wikipedia.org/wiki/Mobile_Web) was non-existent and therefore designing more ‘adaptable’ websites was not a necessity. Graphic designers were able to apply their knowledge to this relatively new medium by approaching it similarly to one they would already be familiar with: the page. Along with this process came identical review methods: printed pages which would be analyzed in all of their static glory, one by one.

Now that the web has evolved and the capabilities of web sites has grown by leaps and bounds, the construct of the ‘page’ no longer applies. Web sites that take advantage of modern browser technology have nothing in common with the printed page: they are dynamic, fluid and most importantly, they are highly interactive. In other words, modern web sites are everything a print ad or magazine spread cannot be and therefore applying the construct of the ‘page’ to web design is fundamentally flawed.

Here is a few reasons why:

It Limits Thinking

By thinking of web sites in terms of pages, a designer is limiting the capabilities of what the web site can do. Web sites which take advantage of dynamic content loading and rich interactivity will always feel more fluid and natural to the user. Interactions which are not thought out and made integral to both the planning and design process will always feel like an afterthought.

Web ‘Pages’; Do Not Reflect the Nature of the Web

We must shift our perception of web sites consisting of a collection of pages to that of a collection of modules. As Stephen Hay said, “We’re not designing pages, we’re designing systems of components”. By doing so, we as designers can adapt to the changing device landscape by adjusting our workflow and embracing the fluid nature of the web.

It is simply naive to expect a web site to always resemble what a Photoshop document will create.

The ‘Ideal’ State is Non-Existent

When we design web ‘pages’, we are designing for an idealized state which simply will never exist. The web is full of unknowns: user’s bandwidth, device capability, device screen size, content, resolution — the list goes on. It is simply naive to expect a web site to always resemble what a Photoshop document will create. What makes more sense to to design a flexible system that can adapt to any variety of conditions and amount of content.

Web Sites Are Never Experienced As A Whole

As designers, we have a tendency to want to analyze our work as a whole. We will print it out and pour over details, but we often forget that web sites are never experienced in this manner. Web sites are experienced via ‘views’ which change as you interact and explore, not as top to bottom pages which are visible as a whole. It simply doesn’t make sense to review your web work in same way you would a print piece.

Finding an alternative workflow that is suitable to both your needs the needs of clients is quite the challenge: design teams have built processes around this perception, and clients have come to expect ‘pages’ when signing off on a web site design. Ultimately, breaking free of ‘page’ perception in the design process will allow for us to create better web sites that are more at home on the modern web. Therefore, I think its worth it to explore alternative workflows, and one day your clients will thank you for it.

Hiroshima

Fri, 07 Feb 2014 00:00:00 +0000

A CSS experiment which recreates the classic Hiroshima poster by Wim Crouwel.

Berlin-Layout

Thu, 06 Feb 2014 00:00:00 +0000

A CSS experiment which recreates the classic Berlin-Layout poster by Anton Stankowski.

Zurich Tonhalle

Tue, 04 Feb 2014 00:00:00 +0000

A CSS experiment which recreates the classic Zurich Tonhalle poster by Josef Müller-Brockmann.

Flexbox Media Object Pattern

Mon, 06 Jan 2014 00:00:00 +0000

The media object is a simple design pattern consisting of an image and adjacent text which has the flexibility to serve a multitude of purposes when laying out content for the web. Once it is abstracted into a reusable component, it has been said to “save hundreds of lines of code”, as well as being the poster-child for Object Orient CSS. The following is a pattern I’ve been using when harnessing the power of the media object which takes advantage of the Flexible Box Layout Module (Flexbox) with a table-based fallback for legacy browsers:

For the purposes of brevity, I have not included browser prefixes or legacy flexbox code. I strongly recommend Autoprefixer for such task.

I start with a clean markup pattern that differentiates the parent element from block elements contained by the parent element:

<div class="media">
<div class="media__item">
<img src="path/to/image.jpg"/>
</div>
<div class="media__body">
<h2>Heading</h2>
<p>Lorem ipsum...</p>
</div>
</div>

Next I enable flexbox on the parent element by setting display:flex, and vertically center the children elements with align-items:center. In addition to this I am setting some simple padding/margin.

/* Block */
.media {
display: flex;
align-items: center;
margin: 0 0 1em;
padding: 0 0 1em;
}

The next step is to create our block elements: the media item, which can be an image, video, icon or any other visual element, and our media body which is any textual content. I then apply flex:1 to the media body, which will establish the flexibility of the media body in relation to the media item; in this case, take up the remaining width of the container. I then apply some default padding to the media item, which will provide space between it and the media body.

/* Block Elements */
.media__item {
padding: 0 1em 0 0;
}
.media__body {
flex: 1;
}

There it is! We have a achieved a basic media object abstraction which can be reused, all with very little amounts of code. But, what if we want the text to align to the top or the bottom of the media item? We can create some simple modifier classes for this:

/* Block */
.media {
display: flex;
align-items: center;
margin: 0 0 1em;
padding: 0 0 1em;
/* Block Modifiers */
&.media--top {
align-items: flex-start;
}
&.media--bottom {
align-items: flex-end;
}
}

There could also be instances when you want to reverse the order of the block items in the markup so that the media body comes before the media item. The following addition to the media item CSS will allow for the proper spacing. You can then add the modifier classes to the parent element, and ensure that the padding around the media item is reversed.

.media__item {
padding: 0 1em 0 0;
.media--rev & {
padding: 0 0 0 1em;
}
}

Finally we create the fallback code for browsers that do not support flexbox. To test for flexbox support I use Modernizr, which will add a class of ‘no-flexbox’ class to the element if flexbox is not supported. Browsers that don’t understand flexbox will simply ignore the previous CSS, but will pick up on the following fallback classes:

/* Fallback */
.no-flexbox .media {
display: table;
width: 100%;
}
.no-flexbox .media__item,
.no-flexbox .media__body {
display: table-cell;
vertical-align: middle;
}
.no-flexbox .media--bottom .media__body,
.no-flexbox .media--bottom .media__item {
vertical-align: bottom;
}
.no-flexbox .media--top .media__body,
.no-flexbox .media--top .media__item {
vertical-align: top;
}

And we are done! The next step would be to add any styling you want to apply to media container and children elements, but you now have a simple abstraction to reuse anywhere. The code is lightweight and modifier classes can be added for conditional styling without fragmenting the code to accommodate single styling scenarios. The following is our completed code:

/* Block */
.media {
display: flex;
align-items: center;
margin: 0 0 1em;
padding: 0 0 1em;
/* Block Modifiers */
&.media--top {
align-items: flex-start;
}
&.media--bottom {
align-items: flex-end;
}
}
/* Block Elements */
.media__item {
padding: 0 1em 0 0;
.media--rev & {
padding: 0 0 0 1em;
}
}
.media__body {
flex: 1;
}
/* Fallback */
.no-flexbox .media {
display: table;
width: 100%;
}
.no-flexbox .media__item,
.no-flexbox .media__body {
display: table-cell;
vertical-align: middle;
}
.no-flexbox .media--bottom .media__body,
.no-flexbox .media--bottom .media__item {
vertical-align: bottom;
}
.no-flexbox .media--top .media__body,
.no-flexbox .media--top .media__item {
vertical-align: top;
}

A Business Case for Avoiding Burnout

Mon, 18 Nov 2013 00:00:00 +0000

Your studio/agency is on a winning streak and those grueling hours in the office are paying off— the future is looking great. Sure, the time away from family and impossibly tight deadlines are stressful, but it will all be worth it. Soon the agency will be doing award-winning work for some of the biggest names out there. Just one thing you might have forgotten: your employees are completely burnt out…

For a business that relies on creative solutions for clients, avoiding burnout is crucial. The chronic stress that leads to burnout is not only a creativity killer, but will eventually lead to disillusionment and the disruption of a healthy work/life balance. The goal should be to push employees creatively while protecting them from the factors that contribute to burnout.

Guidelines

The following are a few guidelines which can help to protect your creative department from burnout:

Avoid Excessive Hours

There are times when working late is a must, but this should never become a habit.

Prevent Stressful Deadlines

If tight turn-arounds are always being agreed to, then the client will come to expect this. The result will be chronic stress on your employees.

Encourage Self-Initiated Projects

Self-initiated projects are a great way to keep your team members engaged and their skills sharpened.

Invest In Your Employees

Sending your employees to conferences and providing ways for them to learn new skills will keep them current and engaged.

Protect Time Off

Time out of the office is important for recharging and maintaining a healthy work/life balance. No one should be made to feel guilty for requesting time off.

Ultimately, protecting employees from burnout is a business decision and should be taken seriously. [Long-hours are unsustainable, unhealthy](What Long Hours Really Mean” href="http://wearemammoth.com/2013/11/long-hours) and will eventually affect the productivity of your team.

CSS Animation Snags

Sat, 02 Nov 2013 00:00:00 +0000

I am addicted to CSS animations: they are lightweight, performant, and come in a very familiar syntax. Recently I have been experimenting with full-page animations and quickly realized that there are quick a few snags that can occur along the way. The following is what I learned.

One particular animation I was using would scale the page content up to mimic it ‘expanding’ into three dimensional space while simultaneously fading out. This animation was stored in a keyframe animation which was called via a CSS class, and applied to to the content area once the user clicks a specific element. This behaved exactly as you would expect, until I noticed that in Firefox it would trigger horizontal scrollbars!

The scrollbar was being caused by the animation, which in the course of scaling up the page content, would scale the content beyond the viewport. I remembered seeing this issue mentioned before, and quickly put into place a solution via CSS: 1) Apply 100% width and height, along with max-width and height to both the <HTML> and <body> tags. This is ensure that these elements extend the full width and height of the page. As a finishing touch, add in overflow: hidden, which will remove the scrollbars (both vertical and horizontal). 2) Next, wrap all of the page content in a wrapping element, which will receive absolute positioning, overflow: scroll (to add back in the ability to scroll the page content), and 100% width as well as height.

This did the trick, and I immediately saw that by triggering the page animation, no longer would I also trigger a horizontal scrollbar. Upon testing on mobile, the next snag reared it’s ugly head: the fix we put in place disabled momentum scrolling in mobile Safari. I have come to really enjoy this feature in Safari: not only does it make swiping through a web page on mobile feel very smooth, it also lends to a sense of perceived performance. Without it, scrolling the page on a touch device feels very rigid and forced. I had to find a solution to this!

After some research I discovered that this featured can be added in Android 3+ and iOS5+ via a new property called ‘overflow-scrolling’. To enable this, I simply had to add the following to the wrapping content element: -webkit-overflow-scrolling: touch. Upon applying this property, I immediately saw that page now had gained back momentum scrolling, but inherited some bugs in the meantime: the fixed header I had in place was now scrolling with the page, only to snap into place once scrolling has stopped. In addition to this I noticed that a new feature in iOS7 that minimized the browser when scrolling the page was now disabled.

After some research I discovered that this featured can be added in Android 3+ and iOS5+ via a new property called ‘overflow-scrolling’.

Ultimately, I decided to modify the page animation to no longer scale the content up, creating the illusion of it expanding towards the user, but instead scale down the content. By doing this, content would no longer extend beyond the viewport and therefore no longer trigger a horizontal scrollbar. This solution was a fair compromise as I still can have full-page animations while not losing the default behavior in cutting-edge mobile browsers.

Keeping It Constructive

Sun, 27 Oct 2013 00:00:00 +0000

I remember design critiques in art school: they were often brutal, sometimes enlightening, and always constructive. We were being taught to not only produce great design but to also articulate what we were doing in our work. Giving and receiving feedback during these critiques helped us all become better designers.

As I transitioned from academia to the professional world, I quickly realized that the sacred critique was not as ubiquitous. Feedback on work often came in the form of meetings in which many of those present had never taken part in the classic critique, and thus lacked the knowledge of the process or how to provide feedback that cultivated growth in the designer. It was during a recent meeting of this variety that I realized the feedback being provided was not only laced with personal bias and clumsily delivered, but just downright non-constructive.

Constructive Principles

The following are a few principles which had they been followed, would have that meeting much more constructive:

Avoid Personal Bias

Feedback should be directly in relation to the work and how effectively it delivers against the brief, not a laundry list of your personal taste or feelings. If you find yourself starting off a sentence during a critique with “I feel like”, please stop and rethink what it is your are trying to say in the context of the brief.

Always Provide Insight

It is never acceptable to simply say “I don’t think this works” without following up on why you don’t think it works. Feedback should be constructive and provide the designer with insight into why some aspect of the design in ineffective, not leave them guessing at why you had a hard time with a specific component.

Follow Up with Actionable Suggestions

After providing insight into why you don’t think a specific component of the design is working, follow up with some suggestions on how it might be improved. These suggestions are meant to get the designer thinking about creative solves, not guide them down a specific path, so feel free to suggest a few. It’s all about fluid problem solving.

Don’t Play Art Director

If you are not an art director or designer, please refrain from design-related suggestions unless your suggestion is in direct relation to the brief. The best design feedback that a designer will receive is from another designer.

Think About Delivery

Have you ever heard “it’s not what you say, but how you say it”? If the goal is to give feedback that will both develop the designer and improve the work, then deliver your feedback in a way that will be fully retained and efficient. Harsh criticism has it’s place, but it is not nearly effective—besides, no one likes an asshole.

The Hamburger Method

An effective way of providing feedback is to begin with a component of the design that is working, then point out what isn’t working and how it could be improved, and then conclude with another effective component of the design. This will not only put into context your feedback for the designer, but also provide a scale in which they can measure the components of the design moving forward. It also signifies that you are there to help the designer improve their work, not just to attack it.

More Copy Isn’t a Solution

More copy is rarely the solution, and suggesting the addition of copy probably will not help the design. If the work isn’t communicating what it needs to, try refining the copy that is there to be more succinct.

When In Doubt, Take It Out

A trusted colleague of mine gave a great piece of advice recently: “take out your best elements, and see if the design still works”. The key is reduction: an effective design doesn’t need flourishes. Suggesting that a designer distill their design down to the essentials is always good feedback— even if that means removing the aspect of the design you are most tied to.

Avoid the Culture of Fear

Most importantly, critiques should foster a sense of community and help those whom participate to grow. If a culture of fear is being developed around critiques, the work is no longer motivated for the right reasons. Everyone involved in a critique should be fully informed into what the project is about, specifics of the brief, and enter into the critique ready to provide constructive feedback that cultivates improvement within the team as a whole.

Page Content Animations

Thu, 10 Oct 2013 00:00:00 +0000

The following is a collection of experiments focused on applying CSS animations to content before leaving the page, and is intended as an easy reference for both myself and others.

Overview

The idea here is to set up your CSS keyframe animations and then call upon these animations with a single class. Javascript is then used to listen for an event (in this case a click event), and then add a specified animation class to the parent container.

Notes to Self

Fri, 20 Sep 2013 00:00:00 +0000

No play with only one act is any good.

Jim Rampton

The meaning you give work determines its difficulty.

Shane Parrish

You don’t run out of ideas if you don’t run out of questions.

Tim Brown

Work hard in silence. Let success be your noise.

Frank Ocean

The best way to anticipate the future is to design it.

Buckminster Fuller

If you want to build a ship, don’t drum up the men and women to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.

Antoine de Saint-Exupéry

Everytime you say yes you’re saying no to something else.

Anonymous

You have to spend as much time de-validating as you do validating.

Nate Valerio

The moment you become content is the moment you stop growing.

Anonymous

Until you make the unconscious conscious, it will direct your life and you will call it fate.

Carl Jung

The path of least resistance is rarely the path of wisdom.

Tim Cook

Beware the fallacies into which undisciplined thinkers most easily fall—they are the real distorting prisms of human nature.

Francis Bacon

Always design a thing by considering it in its next larger context - a chair in a room, a room in a house, a house in an environment, an environment in a city plan.

Eero Saarinen

Do not offer to handle aspects of a project in which you cannot control the quality and outcome.

Anonymous

It is a leader whom stays composed, even in a crisis.

Anonymous

Get comfortable with being uncomfortable.

Anonymous

When in doubt, take it out.

Eric Rak

Beauty is the purgation of superfluities.

Spencer Trierweiler by way of Michelangelo Buonarroti

Do work worthy of your name.

Matt Statman

Bring an extra shirt.

Ian Coyle

Be a scientist when you work, and a snake charmer when you present.

Mike Monteiro

Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.

Antoine de Saint-Exupery

Never mistake motion for action.

Ernest Hemingway

The opportunity lost by increasing the amount of blank space is gained back with enhanced attention on what remains. More white space means that less information is presented. In turn, proportionately more attention shall be paid to that which is made less available. When there is less, we appreciate everything much more.

John Maeda

The details are not the details. They make the design.

Charles Eames