Design 2.0: Minimalism, Transparency, and You

Today happens to be the four month anniversary of eHub Interviews, a series of email questions and answers with the creators and companies behind many of the new web 2.0 services and applications that we’ve been witnessing and using online. According to many of you who write in, the interviews are “one of your favorite parts… it puts a human face to all of these projects. It really adds a valuable dimension to the web review sites.” I’m glad to hear it. Among many of the self-appointed roles that I have at/as eHub, the interviews are one of my favorite activities.

One of the questions asked in each interview is “What is your design philosophy?”

In reading the current sixty interview responses, there’s a clear trend towards several key words that continue to appear in people’s answers:
simple
fast
intuitive
social
minimal
choice
useful
fun

There’s also the echo of key actions:
listen
iterate
release early
experience
discover

While some of these would have been considered in early generations of web, it’s significant that we’re hearing these repeated with such frequency. It’s taken a while to free web and UI design from the bonds of graphic design emulation (early 1990’s) or the web as self-contained animation (late 1990’s flash). Blogs, CSS, web standards, content management systems, and the cry of “usability!” finally put a stake in these paradigms (early 2000’s), but they also introduced something else that could have been just as blasé – the template. Luckily, user experience, long accepted in other industries, came into the web scene and gave design decisions a social and anthropological basis for understanding how subtle shifts could help or hinder a user. Both designers, developers, and decision makers could break away from a generic view of the amorphous “user” with mental mapping, personas, and frequent user testing. This gave us live results and clues into how our users think so that we could provide alternate design solutions. But, the challenge still remained. Making these changes a technical reality could mean more customization to a proprietary system, or hacking an open source solution, or purchasing additional software, or bringing in more programming resources. Development or user testing costs often prevented a truly iterative design process.

It hasn’t been until recently that social norms online and technological changes in agile development have finally matured to give web designers and developers the ability to finally design for the fluid, nonlinear, social medium that is the web.

Designing for new web services and applications is less about page, surface, and singular action, and more about process, structure, and the collective story. If B-Schools are looking to D-Schools to teach business how to think like designers, designers and developers are now thinking more akin to cultural anthropologists, conceptual artists and architects.

Why Minimalism?

“The most important thing is to figure out what features to keep out, not what features to add.” – BlinkList

Perhaps it’s the success of Google’s search page, or our collective reaction against the flashing banner ads and intrusive popups of the last decade, or the Jonathan Ives effect, but it’s as though web users, designers, and developers alike have all agreed to a new de facto standard of Mies van der Rohe’s “less is more.”

In the arts, minimalism can be defined as “reducing the concept or idea to its simplest form.” Minimalism strips away our concerns for the superfluous and let’s us focus on what’s important. It also let’s us imagine the possibilities by giving us the environmental freedom to feel in control and comfortable – a psychological state that makes it easy to explore and to create. Minimalism in design allows patterns to emerge because people are comfortable with the experience.

In an O’Reilly interview with Yukihiro Matsumoto (aka “Matz”) from 2001, Matz was asked if he had a guiding philosophy when he designed the programming language Ruby.

He replied, “yes, it’s called the ‘principle of least surprise.’ I believe people want to express themselves when they program. They don’t want to fight with the language. Programming languages must feel natural to programmers. I tried to make people enjoy programming and concentrate on the fun and creative part of programming when they use Ruby.”

Natural. Expressive. It sounds simple, almost elementary, but how do you achieve an experience that’s both intuitive and exploratory to your audience, particularly when all of us have such subjective and unique perspectives? First, by focusing on designing experiences and then, by providing areas for people to express themselves.

Transparency and Speed

“My design philosophy is based on openness. I hope that almost everything I do will be open for everyone to see–my decisions, my work, success, etc.” – Openomy

There was a time not that long ago when design decisions were made in closed-door meetings, with a creative director pitching the concepts and execution to a team of stakeholders. While it may be hard for some of you Web 2.0 users to believe, that still happens today in most industries and instances. The corporate or institutional brand is mostly legislated and while you can certainly send your thoughts through a web form to the corporate customer service office, there’s usually no reply or assurance that anyone took your thoughts seriously.

“… Answer every user question you get asked. Users, users, users!” – Writely
“Design around an experience, deploy, get feedback, redesign” – goowy

In today’s world of new web services and applications, we expect that our feedback is read, considered, and acted upon, just as we expect a company to encourage conversation with us through a blog or forum. This level of transparency applies to design decisions as well: instant feedback on new feature rollouts or changes to the user interface, and even community voting on user-contributed logos. And, we expect things to happen quickly, or else we move on.

“We keep our technologies simple, easy to use, scalable and state-of-the-art, and we implement it in a way that is based on the feedbacks of hundreds of prototype testers. We improve the system every day.” – Codase

Just a couple of years ago, I reviewed a university client RFP that described its goals for development across a five year plan. Year one called for a redesign of parts of the public site (top level, admissions, academics) that had been around since 2000. Year two called for the expansion of its alumni site but without a redesign to incorporate the main public site brand, and year three called for a redesign of the alumni web portal. By the end of the five years, the university would have a completely overhauled web presence. In today’s web 2.0 climate, three months is a long time. Five years to roll out new features is incomprehensible.

You Matter

“We build what our users want.” – last.fm

The success of Flickr proved that your user base can be your most valuable asset, and more recently, Meebo and last.fm wowed us with their numbers as well. While marketing can be considered hype if the product doesn’t stand up to its claims, a large and active user base is a sure sign that you’re doing something right. Whether this is a direct reflection of the success of your design is another matter. Examples abound of sites with poor design and millions of users. But in this era of choice, it’s only a matter of time before a competitor with design innovation steals your market share. Making design a priority and a core part of your philosophy can mean the difference between success or failure.

“User experience is our no.1, no.2 and no.3 design objective.” – Protopage

As both a designer and a user, I like to toggle my view of user experience from both sides of the lens. I’m often asked how you achieve the right mix between communicating your company’s image and allowing your audience to communicate their own image within your product. Experience online is just like that in the physical world – the more personal or sensory the experience, the more we remember it. Self-expression is our natural instinct anyway, and we’ll do it in a way that moves us, whether that’s words, images, sound, movement, action, or contemplation. If a design allows for the dual pathways of experiencing and expressing, we’ll keep coming back for more.

To see what the creators of web 2.0 services and applications thought, please read below. To read the full interviews, visit eHub Interviews. New interviews will be launching continuously, featuring insights from more than sixty other creators and companies. To automatically stay up to date with interviews, subscribe to the eHub and EmilyChang.com RSS feeds.

eHub: What is your design philosophy?

Userplane: Easy, simple, useful: ergonomic. Our product and design philosophy start well before our applications are actually “launched.” We want our offering to be obvious and compelling right when you hit our site, and for sign-up to be effortless. Finally, using our applications should be like playing with a great toy – fun out of the box and enjoyable to learn.

GiveMeaning: We err on the side of utilitarian and simple in our design approach. We recognize that our demographic will range from 5 to 80 years old, will come from all walks of life, and will have varying levels of web experience. Thus, our focus is on helping these people, all of whom are in giving mode, to find the cause that resonates best with them, and then let them do what they want to do there – quickly and easily.

Wink: Build well designed, scaleable systems, iterate quickly, reuse code.

Prodigem: Code, release, improve, repeat. Like most in the Web 2.0 space, I am a big believer in releasing early and often.

PixPulse: Clean and simple wins when it comes to consumer services. We’re focused on our members and turning their feedback into helpful features.

NetworthIQ: Simple. Social. Fun.

Delineate: If I need/want it, someone else does too.

Fotolia: The fotolia websites expresses how we see a web service should be, very simple and sober as Google or eHub for example and at the same time colourful (look at our homepage).

gOffice: We are building a site which is simple to use for every level of user while also robust enough to host very serious work. We feel that for the web paradigm to be adopted on a very large scale, web firms need to host activities which are accessible and useful for a mass audience. The guys at Google famously say, “do one thing well.” We want to do communication well.

Feedmarker: I like things to be easy.

vSocial: In a nutshell, we believe that people “hire” products/services to perform a “job” that satisfies specific outcomes that they desire to achieve while reconciling the constraints that they face. Needless to say, ease of use and existing usage patterns drives a lot of this for consumers… It sounds trite, but at the end of the day, our user base tells us how well we are doing mostly by their actions, but also by their words so we watch, measure and listen. You can’t improve what you don’t track, and you can’t hear if you don’t really have a need to know.

Yoono: All functions should be accessible in 1 click.

SuprGlu: Design should be functional and simple. And we also try to be original and hopefully make people smile…the Sagmeister way.

Judy’s Book: Keep it easy and fast and get out of the way.

People who visit our site may be there to write reviews, discover information, find new customers or meet people. This community grows every day, as does the amount of information our members publish. We know that we have to provide a fast and easy platform for all these audiences. Our internal catchphrase for this is “molasses removal”, and it’s an ongoing discipline of looking at every process in the app – whether that’s signing up, or adding a new review, or posting a comment – and figuring out how we can remove steps and do things in the background to make it as frictionless as possible.

RawSugar: The customer is always right and will tell you what choices to make if you listen carefully.

Word of Blog: Keep things simple, focus heavily on the problem we’re trying to solve, and execute as perfectly as possible on that one specific aspect.

MapBuilder: Keep users satisfied with the MapBuilder service.

Yellowikis: We use the same MediaWiki software that powers Wikipedia. So our system design and user interface is pretty much fixed. Philosophically we see Wikipedia as the best design too.

AirSet: The primary insight that drives our design is that our lives revolve around a small number of important groups: our immediate family, our work/school colleagues, and a handful of social groups–sports teams, faith groups, and volunteer organizations. Our goal with AirSet is to create a web application suite that is rich enough to manage all of these groups. By offering it for free we lower the barriers to adoption so our users can get as many of the important groups in their lives as possible to adopt the service. Just as Microsoft Office is a horizontal integrated productivity suite for desktops, we are looking to build the best horizontal integrated group management suite available on the web.

2ndSite: Our philosophy is simple: Build something useful. Make it easy to use. Roll it out. Get some feedback and get it right.

LinkPut: Put information first, make it easy to access and make it controllable by the user. I try to understand my data and how it affects site users and site owners, especially with this new way of developing on the web. Gathering data, even the smallest detail, on a user, without invading privacy, is going to open all kinds of doors for me and others. One man’s API is another man’s treasure; this is what I find myself thinking about most while developing.

SWiK: Our design philosophy is release early and release often and see what people make of it, we’re very user-activity oriented. We also strive to be very open, supporting open standards and publishing content under creative commons and via xml.

MOG: MillionsofGames is something of a venture into the unknown so we minimised the risks by re-using as much of our existing codebase as possible. This foundation meant that the code didn’t have any opportunities to draw our attention away from the main purpose of the website. In that sense, our design philosophy is focussed on evolution and re-use.

Orangoo: Speed, simplicity and reliability. I think that’s why Google is so popular. Google search helps you solve your problem very fast, and it’s simple to use – and reliable!

Fundable: Keep it as clear and simple as possible.

LibraryThing: There’s a lot to say here, but others have said it better. I am an ardent fan of Paul Graham’s Hackers and Painters. Graham did not so much overturn my ideas about computers and software development as validate them–the margins of my copy are full of “yes!” and “damn right!” I read him now for inspiration. I should also mention Jason Fried’s recent talk “Lessons Learned while building Basecamp.” Although I came across it only last week, I agree with most of what he says: building half an application, managing debt, building from the UI, learning from users, keeping it simple, feature food.

Dmitry Kuchin: Usefulness, usability and instant gratification.

Atiki: Well… as you may have noticed I’m not so good at this. I try to keep it simple and fast, that’s all.

Campaign Monitor: We focus on simplicity and the little details. What label should I give that input field? How can we reduce the steps to complete that task? We put a lot of thought into every single screen in Campaign Monitor and only ever add features that are truly needed.

CommonMedia: I try to build cool features that are fun or useful and have a relatively simple, straightforward design. It would be great to have more design resources, we just don’t.

Slawesome: “From early on, we wanted a product that would seem so natural and so inevitable and so simple, you almost wouldn’t think of it as having been designed.” – Jonathan Ive, Apple VP of Industrial Design, on the iPod

Mappr: “Stamen thinks by doing.” We are a very hands-on kind of shop, and we like to design as we build. What this means is that we can avoid situations where “the technology won’t work with the design” – we never have problems where the comps don’t work, because the design and the implementation go hand in hand. We like to make things that exploit the inherent properties of the medium we’re working in, that stay true to the materials we’re using. It can take a little bit longer to work this way – but a relationship built on trust in the working process allows for changes that can come up midway through the act of making, and the result in work that feels right.

last.fm: feature-driven, we build what our users want

Findory: Keep it simple. Launch early and often, always learning, always improving.

Tom Evslin: 1. Give the reader as many choices of format as possible. Different people want to read in different ways. We already have blog format, RSS and email feeds, PDFs. A hard cover is scheduled for the beginning of the year. 2. Take advantage of being online. It’s not convenient to take an online edition of the book to the beach. But links in it can be live. The company website and even company store are further examples of making the most out of being online. 3. Keep learning from user feedback and make small changes rapidly.

eyeOS: Design in eyeOS has been thought since the beginning to be a very intuitive design, without menus or text in desktop, based on clear colors, always with the words “minimalism” and “eye-candy” in mind. And regarding the code design we try to keep it as clean and clear as we can so everyone can modify or improve eyeOS to fulfill their needs.

voo2do: Everything should be as simple, automatic, fast, and pleasant as possible. The problem with to-do lists and productivity methodologies is that it’s way too easy to let them slide and get off track. If its colors are warm and welcoming, and if the UI is packed with little wonders, that can be the little push that keeps you going. Conversely, if the application is slow or broken or ugly, it can be the little stumble that kills the whole process.

PageBites: I am not sure that we have an official philosophy. We try different things out, and if something sticks then we spend time improving it. A lot of the things we do are a result of user feedback. User input is key to developing a useful product.

fileNice: The only design philosophy employed in fileNice was to make sure it did its job as quickly, easily and intuitively as possible. To build a server application that simple to install, it has to be something anyone can use without needing a manual. The goal was to make it not even need an F.A.Q. although I eventually did have to make one for the more technical questions.

MapStats: Our focus has always been two-fold: usability (we use all our products ourselves, including MapStats and Pinger) and scalability. For usability, we always test on our mothers and our non-techie friends (rest assured, no animals were hurt!). There are numerous ways we go about testing scability. The one question we do ask ourselves – could we survive a slashdotting?

ColorBlender: In short; “less is more”. To ellaborate a little more, I like things to be clean, attractive and “spacey”. A rule of thumb that I really like is; “remove any element that does not add any value to the final result”.

elfURL: Get it to work fast first, then make it look nice and give it away.

goowy: “Continuous improvement versus delayed perfection”. Design around an experience, deploy, get feedback, redesign, etc.

CafeSpot: My goal is to capture the meaning or intent of a design without adding unnecessary frills. I like open space and successful use of highlighting techniques to draw the viewer’s attention.

BlinkList: Less is more , keep it simple. The most important thing is to figure out what features to keep out, not what features to add. Be very responsive and community driven.

Codase: We keep our technologies to be simple, easy to use, scalable and state-of-the-art, and we implement it in a way that is based on the feedbacks of hundreds of prototype testers. We improve the system every day.

Openomy: My design philosophy is based on openness. I hope that almost everything I do will be open for everyone to see–my decisions, my work, success, etc. Plus, developers are the key to Openomy and freeing and opening up data is integral to the success of the service.

CiteULike: I maintain that people who have been enraged by certain shoddy aspects of how computers work always write the best software…Find something (or even some company) which really annoys you. Do something about it, preferably something which involves solving the problem in a radically different way. Chances are that if it was annoying you in the first place, then the accepted way of doing it was wrong. Your alternative has a much better chance of being right.

Plazes: Build, release early, listen to your supersmart audience, throw away, build again,…

Kiko: Our meta-design philosophy is not to get trapped in any one design philosophy. We aren’t afraid to change our user interface if we think we made mistakes or find a better, more intuitive way to do something. That being said, what we have right now has been created with the goal of making something that feels more like a desktop app, lets you do most things from a single page, and allows users to do more actions by clicking things and dragging things (pretty standard AJAX fare).

Netvibes: Provide a service that makes things to work simpler, faster and better.

CentralDesktop: Action instead of Talk. Go with your gut. Create and Ship instead of Process and Document. Customer needs drive the road-map. Don’t be afraid of change. Listen, listen, listen, listen.

Protopage: User experience is our no.1, no.2 and no.3 design objective.

CommunityWalk: Keep it simple and stick to themes. I try to be very focused on the user’s experience with CommunityWalk and in general try to avoid featuritis. Instead I focus on making the basic functionality as robust as possible. As I get more feedback from users I start to expand my horizons into the few more advanced enhancements that I think will benefit the user community the most.

Writely: Keep it simple and iterate constantly. Don’t put it in unless someone asks for it. Go as fast as you can, answer every user question you get asked. Users, users, users!

Pageflakes: Keep it simple for the occasional user. Offer advanced users the features they need without succumbing to “featurities”. Make it simple to get started, but offer opportunities to discover more over time.

To read the full interviews, visit eHub Interviews. New interviews will be launching continuously, featuring insights from more than sixty other creators and companies. To automatically stay up to date with interviews, subscribe to the eHub and EmilyChang.com RSS feeds. A big thanks to everyone who’s participated!

Update: I’ve co-authored another post on this topic, titled The Agile Web Design Manifesto, An Introduction.