Valuable Coupon Offer

Free

Web-based job tracking, invoicing, reporting & project management software for the part-time independent contractor.

Get Your FREE Side Job Track Account Today!

Early Quora Design Notes

essays - 0 Comments

Jan. 21, 2010

Recently the startup I've been working at for 6 or so months launched its first product. Quora is a continually improving collection of questions and answers -- a place where you can find the best source for a wide range of information online; from local hotspots to esoteric Harry Potter trivia, it's all there.

A lot of thought went into the Quora product design and even at this early stage many details have been revisited multiple times. So, I thought I'd share a few of the decisions and principles that went into the first major version of the beta product.

Key Product Design Decisions
Really early on I decided to focus only on the product design and would forgo any time spent on things like visual design and, to some extent, branding. I didn't really know how that would play out at the time but I knew I wanted to get as much built as possible and as quickly as possible and hoped this artificial constraint would pay other, as yet unknown dividends. In hindsight, this turned out to be a good call because it really focused the product design and avoided common distractions. So, the scant visual elements are carefully added to provide utility and help guide the user to the most important behaviors we wish to encourage.

As a consequence of that strategy, color is largely used for signaling hierarchy or interactions. So, the blue buttons are meant to reflect the blue links. Green buttons are for simple inline interactions. Grey buttons are for the least important and ancillary items. (The application of these rules isn't entirely consistent because of constant, rapid iteration.) Red is used for the logo in order to help it to really stand out from the other surrounding elements. It is also used to highlight the start of the main column and give the eye an easy reference point for where the most important content starts.

Another interesting change from focusing singularly on the product was how that impacted my choice in tools. Normally I'd fire up Photoshop and start painting out a vision and maybe after a few days I'd work in the browser for a bit, jumping back and forth the entire time. With Quora, however, I did something totally different which was to only work in the browser. My tools were limited whatever the current state of the back-end component system was at the time and the browser. This meant relying on properties like border-radius, background and color to communicate as much as possible.

Once I had the general strategy formed, the next big question was where to start? Picking a starting point is important because it will be the axis the rest of the design revolves around -- but it's tricky and not always the first page in the flow. Ideally, you should start with the page that serves the most significant goals of the product. Our early product conversations about long term strategy led me to focus in on the question page. It was really the hub of every main goal we have and critical to creating what we hope will be the best source for any given question on the internet. Probably my first three months at Quora were spent designing and undesigning only the question page, building a set of standard components along the way. When I'd get stuck there, I'd fill in some information on the topic page or user profile but I'd always use the question page as the point from where I'd create important interaction cues.

The First Quora.com Question Page
The First Quora.com Question Page

Another important decision was to be totally ruthless and make real design decisions. All too often in the past I'd find myself falling for some piece of UI and nurture it at the expense of the surrounding elements. Or worse, I'd try to appease someone who was giving feedback or pushing for specific agendas versus trying to create the best UI. This time, however, I was careful to form as few emotional bonds as necessary and really work on rational arguments for everything I designed. By eliminating all but the most important pieces, those that remained always have some concrete purpose. This ruthlessness has helped me become really comfortable with pages that seem only a quarter of the way finished -- so much so that now I use that as my metric for a successful UI. A lot of decent features have been dropped or hidden or otherwise cut in order to pursue this goal but it's helped ensure that only the most important information is on any given page. And with fewer elements comes fewer decisions a user has to make as they interact with the interface.

Moreover, by making real decisions we can really guide the user to whatever behaviors will ensure they have a great experience. If there are only a few options on the page and of those options they do 80% of what you're looking for, we can still capture that intent and use it to help make the product better for everyone. A lot of products fail to make strong decisions because each one they make clearly defines a product into a confined space, but when you provide too much choice another, far worse problem is created: you don't do anything at all.

Each of these main decisions really fell out of a single principle of keeping things as minimal as possible. It's not enough that the product is simple, but even the values and strategy underpinning it should be simple and straightforward.

A Practical Example
I could go on and on about the various decisions, principles and values that make Quora's product design but a great example of focusing on the product, using the question page as the axis of the design and being ruthless with design decisions can be found in the evolution of the site's navigation.

Keeping things minimal was terrific idea in the abstract but once we got rolling building new features, reality started to get in the way. As a result, the header was put under tremendous stress as huge chunks of the product started to take shape. At one point the header design had something like 10 components -- each a seemingly reasonable addition in isolation:

Old Quora Header
Old Quora Header

There's the obligatory logo link, home, user name, logout, and settings links but also the search bar, search button, add question button, recent changes and notifications links. Many products have these types of links in their headers and, with the explosion of social applications, many more are on the way. After using this header for a while, however, I began to notice that it was getting in the way on the question page. Not only did the user have to parse what can grow into vast bodies of text, but before she even got to the question she had to traverse this daunting set of standard controls. The nav was even visually noisy with lines and boxes and text everywhere.

So, I started to digest each component and extract whatever essence was most useful and apply that back to the navigation. Even taking those steps ultimately I kept ending up at the same point and instead of designing the navigation, I was rearranging it -- shuffling components from left to right, top to bottom. The last straw was the inclusion of the Inbox link and something had to be done. But it wasn't until things got ruthless that any progress was made. This meant cutting. The notifications link, the recent changes link and dropping the search button were the first things to go, but they didn't go quietly.

Notifications are a critical channel for a user's experience, so it's no small feat to remove a prominent link to the page and care must be taken to ensure a user is alerted to new notifications. Another issue was that the existing notifications link was useful as a navigation point but also as an anchor for an alert -- like a count bubble. But when thinking about it, the weight of notifications importance actually provided for another option and carving out room on the homepage to display notifications inline seemed like an appropriate way to access that information. Once the main location for accessing notifications became the homepage, adding the new notifications count bubble to the Home link made sense.

Notifications
Notifications

Recent changes was another tricky area because that was a channel for power users to help police a flood of content and maintain a standard of quality critical to the site's success. Removing it meant that an important feature would be less prominent. There was also this remainder left over from removing the Notifications link -- once new notifications were cleared, how did you get back to the full list of older notifications? So a simple sub-navigation was developed to easy flip between a user's feed, all recent changes, inbox, notifications and invites that is only available on those pages and unnecessary elsewhere.

Finally, the search button was moved to the typeahead results list. This design -- like everything else -- still needs further refinement but overall it is poised to only show exactly what is needed and only when it's needed. Eventually that link will only show when there are more results than those visible in the typeahead.

Quora Question Page
Quora Question Page, For Now

The end result was a navigation that fit into a single line and is clear and easy to read. You may not understand every single element instantaneously, but it's easy to learn if you are the least bit invested in the site and out of the way if you're trying get an answer to a question.

Conclusion
A user interface is the product of a design. A design is a set of decisions about a particular product. Those decisions represent the product's goals and ambitions. There is a struggle balancing the philosophical and the practical -- a constant shifting of priority and intention -- and as new ideas come up something that was once great is now totally inappropriate, yesterday's terrible idea is made brilliant. There are trade-offs, to be sure, and some decisions probably don't map to yours but the important thing is that they were made and continually improved.

Jobs at Quora
So far I've designed quora.com by myself but pretty soon I'll need some help. If you're interested in working at Quora, can build what you design (not kidding about this requirement!) and are interested in learning more, send a link of your portfolio to jobs@quora.com.

(Cal)Training.

artypapers - 0 Comments

Feb. 22, 2009

At the end of October '08, I set out to design a little app to make the CalTrain schedule more useful. My goal was pretty simple: Create an iPhone-friendly webapp that could show the number of minutes until the next train. I chose a webapp over an iPhone app because I wanted to get something up quickly that could be accessed anywhere.

At the time I started to sketch the first version of the design, I was watching a lot of TV, primarily home improvement and design-related reality programs. This led to a fascination with hardwood flooring, baseboards and wallpaper. I'd seen an interesting digital representation of the last two elements in the beautiful Facebook application called Pixels. Using that as inspiration, I created the first iteration of the app:



This version lasted for a few weeks but I quickly discovered a lot of problems with the design. First, it was slow. Downloading the hardwood floor over the Edge network was painful. Second, it was amazingly difficult to read. The stop names were so small, I'd often forget to flip between stops when making a return journey. Third, the information available was mostly useless. I had a feature in this version where you could click into the later trains for more detail but even that felt like too much work. Finally, there wasn't a way to get to older train information. So, if trains were delayed, there wasn't an easy way to look back for the numbers to ensure that train included your stop.



The second major iteration was the result of a couple things. The first was a desire to remedy the usability issues of the first version and the second was a new fascination: Wall-e. Namely, the controls available on the Axiom for things like setting the position of the sun or providing status information to the captain. A lot of details critical to pulling off a successful interpretation of that style were very difficult given the constraints of a simple, lightweight web page. So instead of an extension of that style, I settled for something in its spirit with big chunky type, huge North/South control and the menu is meant to reflect lit retro buttons.

In terms of practical goals there were some clear wins. Speed was improved by using fewer images, readability was improved with more contrast on important data, more useful data was available and exposed through a new menu navigation and schedule view.

This version was available for many weeks but it too presented interesting problems. To start, there is a technical limitation with mobile Safari's implementation of the viewport. So, to accomplish something like a menu system pegged at the bottom you have two options: a div with an overflow scroll that requires a two fingers to operate or a bucket of scripts to fake a viewport. I went with the two finger scroll but soon realized the downfall of that choice: coffee. See, I'm a coffee junkie and everyday I pour a togo mug and walk that to the station. It is extremely difficult to hold an iPhone, a cup of coffee and two finger scroll your way through a full schedule of trains.

That interaction was so cumbersome I had totally stopped using it and other critical features! The entire app was limited by a singular yet huge shortcoming. So, I decided to consider making a native iPhone application again.

By the time I started to think about correcting the challenges posed by the latest set of features, it was clear that some things were plain unnecessary. Refactoring the IA was step one, iPhone app or no, and a few simple sketches illustrated the core elements and important workflows. What you needed was to set your stops, see the next train, see the direction you are traveling, how to change that direction and how to access the full schedule if the next three trains don't provide you with enough information. Boom. Done.



Stylistically, instead of aping someone else's style, I went with my own. Using colors from an abandoned Artypapers redesign, elements from the prior two designs that worked the best, and attempting to speak to the roots of the app by aligning towards a more European transit style the latest version is really close to something simple, useful and beautiful. The only element that fell flat were all my attempts to design a map icon. So, for now, I've recreated the brilliant map icon from the beautiful and elegant Everyblock.

If you live in the Bay Area and have a chance to use the CalTrain app, I'm interested in your feedback in terms of bugs (it's very much still in beta) and the UI.

CSS Help Pile

Latest CSS News & Information

01/30/09CSS Showcase SitesDesignAwardsGallery.com CSS inspiration gallery

01/21/09CSS Showcase Sitesminimalsites | minimal design css gallery

01/25/08Web Reference101 CSS Techniques Of All Time- Part 1

12/09/07Web-Related ArticlesDigital Web Magazine - Better Web Forms: Redesigning eBay's Registration

12/09/07Simple Tips & How ToVitamin Features: Creating Sexy Stylesheets

05/26/07Simple Tips & How ToStyling the Button Element with Sliding Doors

05/15/07Assorted GoodnessCSS Hacks and Issues

Get an RSS feed, dig into the archives & find more resources at the CSS Help Pile.

More, Please.

The name "Artypapers" arose after combining random words while discussing potential domain names at a local bookstore one day.

Learn more about Artypapers and its creator R. Marie Cox.

Member Login Join!

Please read the information below carefully.

By accessing Artypapers you are agreeing to its terms of service.

By using this service, you acknowledge you are at least 14 years old.

Privacy Policy

Artypapers will never sell any information associated with your account. Server logs are maintained for hit-tracking purposes and your IP address will be recorded.

Terms

The use of this site and/or application is at your own risk and NO guarantee is provided should there be any error, data loss or any other event causing any malfunction whatsoever. It is up to the user to back-up any information input into the Artypapers application and service may stop without prior warning. Any account may be removed at any time for any reason.

Neither R. Marie Cox nor Artypapers is responsible for the opinions expressed within the ap.log or CSS Help Pile and any post/comment is subject to possible deletion.