Blog

Good Design is Reductive

· Michael Angeles

The essence of a product

If you’re a product designer, you’ve likely come across the following quote about perfection, attributed to Antoine de Saint-Exupéry.

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

Designers love the adage. While simple to state, however, the idea can be a bit difficult to apply. The last part of the sentence is what sticks for me, because it centers on using reduction to find this state of perfection—the attributes that define a product’s essence. This is the crux of simplifying a design.

Reductive design is about removing what’s unnecessary and simplifying the product. It’s a philosophy in the spirit of Modern architect Ludwig Mies van der Rohe’s aphorism, “Less is more,” and Dieter Rams’ principle, “Good design is as little design as possible. Less but better.”

Chuck Pearson wrote a great article on reductive design for products. Ideas like these are axiomatic in design. Find what’s essential. Remove the parts that aren’t needed. I’ve been thinking about whether or not we are doing that in our product design work on every project. And once we ship, are we revisiting our designs over time to look at them through the lens of reductive design, and comparing that to the idea of what’s essential to the product?

Reduction in product design

I’ve read a lot about minimalism and essentialism, and as I mature as a designer, I think about the application these ideas might have to product design. Products that appear to be simple, are most likely that way because their creators pushed hard against expansion to keep the product focused on providing the most important features for the task. Deciding what to leave out is equally as important as what to put in, and I would argue can sometimes be much more difficult.

When you generate design ideas, you’re looking for the sweet spot of just enough UI and just enough features to make the user effective and efficient at accomplishing their goals or completing tasks. That sweet spot can be hard to find. I would guess that the product teams that are relentless and unforgiving in this pursuit of the essential are those that deliver those products that I love that do one thing really well.

One of the ways that we try to find that sweet spot is to hold an idea in mind that the process and output of wireframing often represents version 2. During the initial exploration of a solution, we often consider many possibilities pretty exhaustively. Then we start the hard work of making calls about what parts of the design needs to ship now—what’s essential—and look for ways to edit down and remove elements through each critique and iteration. Often times that’s where we find the optimal and most efficient ways for users to complete tasks.

I’ve also been thinking about what reductive design means for products as they mature. It’s inevitable that a product’s feature set will evolve and grow over time, particularly as you acquire more types of users. Finding the sweet spot and delivering a successful product, doesn’t mean your job is done when you first ship it. With the accretion of features, you’ll have to re-evaluate how far away the product has moved from that sweet spot.

Side note: As an expert user of the product I work on, I have found it very difficult to resist the urge to express the desire for more features over the years, but have learned to “slow my roll” in favor of remembering the product’s core, it’s target user, and its mission.

Peldi recently wrote about starting our product team on a paring down theme as we begin a new phase of the product. It’s been eye-opening and refreshing. You can spend a lot of time growing with user needs, but somewhere in the life of the product, the essence of what made it successful—it’s character and personality—may morph into something else. Added features and UI could look like more power to some, but to others it might feel like unnecessary complexity.

I think what makes our product still resonate with users is its singular focus on remaining easy to use. To those who have ideas and a need to easily get them out, we offer something of value—a way that feels as accessible as using a whiteboard or assembling building blocks like Legos or refrigerator magnet poetry. But to be sure, we’ve had to re-evaluate what’s become of the user experience over time.

How do you apply the ideas of reductive design over the lifetime of the product, as it evolves to meet the needs of more customers? I think the answer lies in capturing the essence of your product, whether it be in a mission statement, manifesto, or some other expression of the core purpose of the product. Then continually revisit that statement and use reduction to keep that core character alive.

Reduction doesn’t only mean removal

Another thought that occurs to me is that reduction doesn’t only mean removing features. Reduction also applies to reducing complexity. It could mean re-envisioning the form or behavior of a feature so that it works more efficiently, uses fewer steps.

Consider this description of reductive art as a style that “emphasizes clarity, simplification, reduced means, reduction of form, streamlined composition, primary shapes, and restricted color. … It is also characterized by the use of plain-spoken materials, precise craftsmanship and intellectual rigor.”

The idea is consistent with minimalism in art. Applying the concept to products, however, must also consider how those attributes affect use and usability. And that’s where reduction becomes a powerful tool—aesthetic choices can have an impact on the user in terms of clarity and efficiency. The surface, when designed in a way that balances ease of use with these ideas, provides an experience worthy of the user’s time.

In “The Art of Reductive Design,” Chuck Pearson writes about how reductive design becomes a factor for their web design work.

“[W]e have to analyze and assess exactly what the goals of the site are and then get rid of everything that competes with or stands in the way of those goals. As users, we have limited attention. We can only focus on one thing at a time. Every time an extra element is added into a website or app, whether it’s additional navigational elements, bold colors, motion, sound, etc., it pulls the user’s attention away from something else.”

Having a streamlined product is a differentiating factor in a market flooded with complex and complicated competitors.

Here’s a very interesting example of reductive design in an industrial design context. The Ford Maverick is a very different pickup truck. It lives in a space between SUVs like the Ford Bronco and large body-on-frame work trucks like the F150. It’s targeted at a market that probably will use it for outdoor recreation and everyday chores more than for heavy-duty hauling and construction.

They talk about reductive design as guiding principle for shaping the truck’s interior. There’s an emphasis on sustainability and savings to customer. But there’s also thought put into studying how drivers want to use their vehicle and designing the interior features. Take for instance their design of the door handle and door storage space to hold variable sizes of water bottles (32 oz. Nalgene owners rejoice!) rather than only doing the industry’s default sizing—cup holders suitable for to go cups and disposable water bottles. This is using reduction as a guiding principle by crafting a differently shaped handle that exposes hardware, considers real-world use, and does more with less.

This is really cool, but Ford goes beyond this one example by making their product hackable for DIYers. One example of this is with their “fit slot” that allows owners to 3D print custom items that slot into the back of the console system. No doubt, most users won’t take advantage of this, but the idea of the slot is a clever way to add possibility for the power users without requiring it for the default experience. Another example is to that they provide a QR code that links to recipes to DIY different solutions for the truck bed.

Staying vigilant

The ideas wrapped up in reductive design demonstrate the timelessness of the truisms from Mies van der Rohe (less is more), Buckminster Fuller (do more with less), Dieter Rams (less, but better), Kelly Johnson and maybe your dad (keep it simple, stupid). So many great products have reduction, and the delivery of what’s essential to user goals as a core attribute and contributor to their success. It’s a difficult principle to live by, particularly as your product becomes successful and you are met with demands for it to do more.

If I can leave you with one thought about reduction in product design, it’s this. Remember that there is a core or essence to your product—a state where your product has all of essential attributes to help users solve a problem. Invest time in discovering this core and use reduction to find it. Iteratively evaluate your product against this idea of it’s essence. And once you’ve found it, remember to stay vigilant in keeping true to it.

The Power of 100

· Michael Angeles

Josh Spector’s article, “Only Do It If You’re Willing To Do It 100 Times,” explains why committing to doing something 100 times furthers your efforts towards accomplishing a goal. He writes that the 100x method gives you a way to use a seemingly arbitrary structure to discipline you through the challenge of working towards a goal that may seem large at the onset. That structure also serves to push you forward through what Seth Godin refers to in The Dip — that point in the project where you’re unsure whether to go on or quit.

At the end of the day, it’s not what you choose to do 100 times that matters most — it’s the act of committing up front to do something in volume that helps you make things happen.

For some work that we do, we naturally reach 100 times because it’s the work we’re given. Other times, the work could be to acquire a new skill, or to become knowledgeable in a new subject area. At the onset the challenge can seem daunting.

Having completed 100 days this past year on a creative side project and starting another, I believe the power of committing to doing something 100 times is that it forces you to do the work every day. Simple as that.

For me, saying that you’re going to do a thing 100 times is like establishing a contract. In the past year I’ve learned that this kind of agreement made with oneself can really help you to avoid quitting, because the dip will come, some of your output will suck (particularly in the beginning), and you won’t be happy with everything you produce. But the more you show up and produce, the more chance you give yourself to make something worth the effort, something to be proud of.

Showing up is hard when the output is mediocre. Being gentle with yourself and setting reasonable expectations and pace is everything. This is something that I learned after several weeks into the project, but I coincidentally learned it from running.

The past few years I started to run as a form of self care, despite previously hating running. I set a goal of doing my first running event, the SF half marathon. In the months that I trained to finish the event, I started to understand that sometimes you really have to take it slow to go fast. What I mean is that ultimately, when I set my effort and pace reasonably for the distance I was hoping to go, I found myself finishing at a better pace than when I was trying to go longer distances running fast. I know I’ve read this before, but it didn’t make sense until it started happening.

The idea of pace and commitment go hand in hand when you’re trying something new or setting a larger goal. Finding a way to show up every day and do the work is why the 100x idea helps. I just embarked on another 100x project and today was my day 1, so it’s fortuitous to have found Josh’s article. And with that I gotta get to work. See you in 100 days!

Rule 7

· Michael Angeles

I keep Sister Corita Kent’s 10 Art Department Rules on my personal workspace wall. It’s also the wallpaper I have on my Mac Desktop.

If you need the reminder to “do the work,” whatever that means to you, you can download one of the wallpapers below:

Sketch Zine

· Michael Angeles

This is a little zine I made from my Sketch talk.

I’m putting these in the package when people buy a sketchbook. I’ll be sending one out soon to everyone who already purchased a book. Still working on setting up international shipping. :)

A little zine has been something I’ve always wanted to make. This is a zine in the traditional, DIY photocopy sense. It’s not an art piece, as so many beautiful zines are these days. But maybe I’ll make something more refined in the future.

shop.konigi.com

Skillshare Course on Rapid Wireframing

· Michael Angeles

I published a free course for Balsamiq users on Skillshare. The course, Rapid Wireframing: Finding the Right Product Design, is designed for those new to Balsamiq, but also features some demonstration of new features like Quick Draw (using the mouse to block out wireframe zones) and Alternates (creating alternate versions of screens). If you’re a veteran user, you may be interested in checking that out, and updating to the latest version to take advantage of these useful new ways of working on projects.

You’ll learn how to successfully create wireframes for early stage product design as I show how to use Balsamiq Mockups to design interfaces with product teams, using the example requirements from UX Apprentice.

In the 51 minute course, you’ll see how concept selection can be tackled with low-fidelity wireframes, learn to create rough sketches to explore ideas, and then transform them into interaction design solutions that can be refined quickly, and polished for presentation.

The class is perfect for product managers, developers, and those new to designing with wireframes. No prior knowledge or experience with interface design is required. By the end, you’ll be able to present wireframes for a finished product idea and demonstrate a clickable prototype.

Start taking the free course at Skillshare now!

5.25 Inch Floppy Sketchbook Is Back

· Michael Angeles

Remember these? From 2009-2010 I these sketchbooks for a while, using a 5.25” floppy disk as a notebook cover. I kind of missed them, so I made a limited number in blank and grid paper.

It’s a wirebound 5.25 inch square sketchbook with about 120-130 pages (60-65 sheets) of 70 pound white vellum paper, hand-crafted by me in my home North of the SF Bay. You can buy a book with blank sheets or one printed with 1cm grid in warm gray ink. Inside you’ll find a floppy disk pocket, and a disk label. Hope you like them! They’re a head turner. :)

Get yours at the shop while they last! Shipping inside the US only this time around. http://shop.konigi.com

Creating Polished Wireframes in Balsamiq

· Michael Angeles

For Balsamiq users or anyone that bemoans handwritten fonts and sketchy wireframes, I wrote an article to show how to create polished wireframes in Balsamiq on our UX blog. It shows how to use the wireframe skin with a few base controls, and techniques to achieve a minimalist aesthetic. It’s meant for those who need to create client-ready deliverables, or for when the sketchy-skin gets in the way of communicating your ideas. You can keep generating screens fast, but polish the details when you need to.

Read the article at the Balsamiq blog.

Jim Kalbach on Jazz as a Model for the Way Businesses Work

· Michael Angeles

Jim Kalbach talks about the improvisational model of Jazz as a metaphor for the way some businesses approach collaboration today. What was probably seen a few years ago as a radical way of structuring companies to organize around the work rather than using inflexible business units as boundaries, is now more commonplace.

To demonstrate what happens in the teamwork of a group of jazz performers, Kalbach assembled a group of musicians to perform a song they hadn’t played together before, and described how jazz performances “work” as a type of collaboration. These are the characteristics we can learn from.

Empathy: Everyone brings something unique to the performance, but it’s only when the individuals come together that great music happens. So while Jazz performers allows for individuality to shine through, it’s in the listening and working with each musician’s solo that the whole emerges.

Embracing uncertainty: The idea of approaching each performance with an expectation that what may unfold is unknown means that performers can experiment and improvise.

Lastly, improvisation in a team doesn’t mean doing as you please. Without some rules or guidelines, it’d be easier to make a mess than music worth listening to. It could be a set of patterns, guidelines, and principles that set the stage for the work to be done. In jazz it can mean using song structure like working within the AABA song pattern so that the musicians have queues for how the individual moments can be framed. It can also mean having principles that the players have a common understanding of, so they can work with how the others’ use them.

These three points can be easily applied to how businesses organize and do work. I like the chart he shows, giving a snapshot of how Spotify’s organic Guild structure (PDF) has allowed their Agile teams to make do with a fast growing company. It’s a great example showing how a business organizes teams into organic groups around projects. This makes it possible to flex with the constantly changing organization and business goals in order to get things done. This way of working is the antithesis of what Kalbach refers to as the command and control model of work from the Drucker age of business management for information work. The work becomes more important as does embracing the uncertainty of flatter and continuously morphing teams.

Where I work, a lot of our inspiration comes from the same examples of companies that Kalbach references like Gore and Valve—companies that have created flatter, work-oriented teams where the focus on how the company works is as important as the products. Our founder Peldi’s greatest achievement in many of our opinions is not the product, but the company he’s created. Our most interesting meetings have been discussion focussed on continuous improvement, rather than anything related to technology.

This is an inspiring presentation, and I love the connection made with Jazz performance. You can see more talks from Jim at his blog Experiencing Information.

Hat tip to @jboogie

Hello Hugo: Konigi is now a Static Site

· Michael Angeles

After many years of being a Drupal user, from version 2 when I started iaslash.org to version 6 on this site, I’ve made the move from PHP/MySQL blog to full on static site. Here’s why and how I did it.

Choosing Static Site Generators

In the past few years, I’ve taken a few sites backwards from Drupal and WordPress into the age of static sites. In many ways, it feels like going back to the beginning of my career, when I used Perl and Shell scripts to generate sites in my first job, and later to more sophisticated site generation using MovableType as a middle man.

As each of the small personal projects I’ve worked on became bigger, I started to miss how simple things used to be, and loathe how much I had to babysit my site or pay a lot for better cloud MySQL instances. In my day job, we also had to deal with the regular security patches on WP and Drupal, and it became a drag.

I started our first experiment by moving a site to Hammer, then shortly after moved it to become a grunt generated site. Those sites are happily chugging along, maintained by a team that generates the pages with grunt. Our main site at balsamiq.com is one of them.

After that year or so of being happy with how simple those site are to maintain, I started looking at more powerful static site generators and finally migrated this site content off of Drupal so it can be used by a static generator. I now use Hugo to generate the few thousand pages of this site in a few seconds and sync it to AWS S3 using their static site hosting options.

Hugo is a generator written in the Go programming language. I chose Hugo over a few of the other great options out there like Jekkyl and Octopress because of its speed, support for taxonomies, and markdown support. I’m no programmer, so my implementation of Hugo is very simple and I put together my theme using only the examples in the docs, and a couple of questions to the discussion forum.

I still haven’t gotten my head around how to do more complex things yet, and I don’t want to be the newb that inundates the forum with dense questions. If you happen to find yourself in that forum you’ll see how little I understand, despite reading docs. But for now, after a few weeks of work with only a few days of template building, it’s doing nearly everything I did in Drupal, with none of the overhead.

Migrating Content Off Drupal

To get started, I created a modified version of my Drupal theme that exports all of my content to text files. I removed all the views and only exported the actual node contents. Each node includes Hugo’s “front matter” at the top of each page. This is the metadata that describes title, tags, permalink slug, and publish date. I pared down my taxonomy use on this site to one tag taxonomy for the time being to simplify things. I had taxonomies for people, company, color, etc.

After testing to see that what I output was formatted to properly get read by Hugo, I then used httrack to download all of the nodes of content to my machine. Each file was downloaded into a subfolder for the corresponding sections used by the global nav and the url paths on the site. I ran the files all through a file renamer to add .md (markdown) extensions. I use Name Mangler on the Mac for renaming.

These articles helped with figuring out the export part of the process.

Building it in Hugo

Next step was to install Hugo and generate a basic Hugo site with the .md files I downloaded. The Hugo docs show you how to create a Hugo site and install a theme. I did this first to test out the content. Then I started learning how templates work and built my own straight from the docs, looking at a few examples to figure out how to create taxonomy views. I started with a skeleton template that just spits out a nav and bodies, then made some section views.

Next was CSS/JS asset management. I copied over my SASS files and JS. I also decided to switch from the Bootstrap grid to Foundation, so I stripped down a lot of styles and the layout. After years of changing layout ideas, it’s nice to trim the SASS layout files down to nothing.

To manage the pre-processing, minifying and building of JS and SASS/CSS I had to set up a task manager. I decided to learn how Gulp handles this compared to Grunt, and I like how simple and clean my Gulpfile.js is. It works about the same as Grunt, so there was little to learn there. This post on getting started with gulp is good if all you’re interested in is processing Sass. There’s plenty of StackOverflow articles on processing JS. I only run gulp whenever I make a change to JS or SASS which is rare, and the minified files get included with the Hugo build command.

My process for writing new content now is to start up Atom, create a new .md file in the appropriate directory, then run “hugo server —watch” to test it. When I’m happy with my writing, I run “hugo” to build files into my /public directory and I’m ready to deploy.

The last step is a command that uses s3cmd to sync only the changed pages to the generated public directory, removing deletions. See the options in the docs for doing this. There are many blog posts with different suggestions for how to deploy, but I found all I needed in this one on Programblings.

That’s what I’ve done to date and it’s working well. My next steps are to get my content, which is on Git, hooked up to a middleman that will automate the deploy part of the process. If you’re interested in seeing how I created this site, you can look at my theme templates. The entire site is publicly viewable on Github.

So far I’m very happy, and after a few years of trying different tools, this set feels right… until the next change. The older I get, however, the less I want to waste time on stuff like this, so it feels like a keeper. Huge thanks to Steve Francia for creating Hugo and to everyone who contribute to it. If a simple-minded UX designer like me can use it, that’s saying a lot.

Code.org Program for K-5

· Michael Angeles

Code.org now has an elementary school program (Kindergarden - 5th grade), and Code Studio for the program looks like its modeled after the free MIT Scratch app, a visual tool that we used with our first son to introduce computer science fundamentals a few years ago. Good stuff.