The weblog of Amrinder Sandhu: a web and interaction designer from India;
who runs a small design studio.
Interesting read with proven examples how focusing on real problem makes a product successful.
The problems people encounter in their lives rarely change from generation to generation. The products they hire to solve these problems change all the time.
Great advice on setting type for headings.
When designing a full set of headlines like this, it’s a great idea to start with the smallest headline and work your way up like we did today. While you’re at it, make sure you design how bolds and italics look in a paragraph, as well as lists, blockquotes, and all the common styles that will show up in a page. We call this a “General Styles” page. You can include tables, images, captions, and even form elements. Planning ahead for the styles you might need in the future helps you build a more complete typographic system and avoid any surprises.
Jeff Patton explains how Kano model is applied while adding features to a product:
The Kano Method separates product features into general categories. The three big ones are “must haves,” like: brakes on a car (we need those); “one-dimensional” items like gas mileage on a car (higher mileage is better); and attractive quality or “delighters” (leather seats in my German car are a delighter). The idea is that your product should have all the must haves, maximize the one-dimensionals, and toss in some delighters.
A common problem with most softwares and products, in general:
In software development, more features is often considered better. Since we’re consumed with the quantity of features, we often forget the quality of the software as a whole unit.
How to fix this problem:
- In a small group, brainstorm the major features of your product.
- Independently for each feature write your “grade” for the quality of the feature. Answer the following questions: Do you like the feature?; Do you like using it?; and Is it a valuable part of the product? Let your answers help you grade the feature with an A, B, C, or D, or fail it with an F.
- When done, discuss your grades with those in your group. Agree on a grade that best represents the group’s opinion of the quality of that feature.
User Interface designers should write, and write well.
Aesthetics are debatable, but writing is essential. Peel away the layers of styling and you’ll be left with words. Writing is the meat of a design, and it’s one of the hardest things to get right.
Ryan Singer — product designer at Basecamp — explains a simple yet effective process of Product design.
Problems with product and feature design often trace back to the initial approach. Either the problem wasn’t well defined, the concept wasn’t well defined, or – in the case of beginners and newcomers to a platform – your bag of tricks wasn’t adequate to address the problem. Questioning each of these areas can open up new insight and unblock you.
UI has been widely mixed with UX recently. Erik Flowers has clearly explained the difference between two saying:
UX is an acronym for “user experience.” It is almost always followed by the word “design.” By the nature of the term, people who perform the work become “UX designers.” But these designers aren’t designing things in the same sense as a visual or interface designer. UX is the intangible design of a strategy that brings us to a solution.
He’s put together a list of UX roles. Glad I’m involved in more than half of these at Unmetric:
- Field research
Face to face interviewing
- Creation and administering of tests
- Gathering, organizing, and presenting statistics
- Documentation of personas and findings
- Product design
Feature writing Requirement writing
- Graphic arts
- Interaction design
- Information Architecture
- Interface layout
- Interface design
- Visual design
Taxonomy creation Terminology creation
- Copy writing
- Presentation and speaking
- Working tightly with programmers
Brainstorm coordination Company culture evangelism
- Communication to stakeholders
From above list there are few roles that I’m not involved in (struck-through) or we, at Unmetric, are not practicing yet. Hope these’ll get added down the road. Apart form that I’m also handling front-end development and pushing production-ready code. Wow! So much stuff to work on, but I’m lovin it.
Billy Whited explains the importance and characteristics of a great typeface in UI.
Good typesetting is an exercise in subtlety, and a demonstration of skill and sensitivity—to context, form, and user needs. As UI designers, it’s important to remember that our goal is not to distract users with superfluous details, but to ease the burden of their work and help them get stuff done.
My favorites 4 are:
- Lucida Grande (used by Facebook)
- Open Sans (Dropbox)
- Source Sans Pro (Digg) and
- FF Scala (Readmill and A Way Back)
I love diagrams since the day I know them.
Treat your diagrams as a design tool. They can help you break a bad case of writers’ block, clear up your thinking, and communicate your great idea. Best of all, when you lead with a diagram, you bring your audience along your line of thinking so that your final design is not just successful, it appears inevitable.
Ryan Singer – product designer at 37 Signals – explains what is that needs more of UI designers attention, and it’s not pixel perfect design, it’s making a user capable to performing intended task.
It’s easy to get overwhelmed with details when you’re designing a UI. That’s why I try to keep hold of which things “really matter” and continually come back to them. In a software tool, the important things are the capabilities you give your users.
Designing with capability in mind helps us focus on the problem we are trying to sovle:
When it comes to design, thinking about the capability you are affording can help you refocus when you’re lost in details. Designing isn’t just pushing pixels around and playing with type. Ask yourself: does this change affect whether a user can discover the feature? Does it clarify how to operate it? What am I helping them do right now?
I value prototyping a lot. My tools of trade are Invisionapp, Keynote, Balsamiq and HTML/CSS (sometimes), but that’s are not the most important part of prototyping (though they matter). Jared Spool tells about where to focus while prototyping as to avoid the traps that reduce the effectiveness of prototyping efforts.
Prototyping is rendering ideas to understand them better. It’s a way for the team to dive deep into the process of design and their understanding of the problem to solve. It’s an effective way to show progress throughout the project cycle, not only by having something substantive to display, but by creating a vehicle to talk about the decisions the team is working through.
While re-reading Universal Principles of Design yesterday I came across Cognitive Dissonance and how it can be applied in web design to increase engagement and conversions. Though I was not familiar with the term Cognitive Dissonance but somehow we were already implementing this principles at Unmetric’s marketing site by saying: “Is your brand social enough?” and “Top brands stay on top using Unmetric. You can too.” Couple of in-depth articles explaining (with examples) more about this design principle.
- Steven Bradley explains what the term actually means along with some examples from history:
Cognitive dissonance is a state of mental discomfort that occurs when a person’s attitudes, thoughts, ideas or beliefs conflict. For example you may believe it’s important to diet in order to lose weight yet have the desire to order cheesecake for dessert. Eating the cheesecake would conflict with your attitude about dieting, which causes discomfort that needs to be resolved.
- Tad Fry’s article on Smashing Magazine gives modern day examples in context of web design.
Some really useful and in-depth concepts about human perception and cognition, and its implications for designing better UI.
Steve Jobs once said:
“You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying ‘no’ to 1,000 things.”
Jared Spool reminds me above quote with his latest post.
Read the article
Along with a decent idea and great execution there’s more to the success of a web app. It’s not the features list but the simplicity and details of an app that matters. Here’s a talk by Des Traynor where he emphasizes the role of good content strategy in the success of a web app.
Being a designer who knows HTML/CSS quite well helps me to make thoughtful decisions about how my designs will perform. Front-end plays a great part in overall performance of an website/webapp. Lara Swanson emphasizes the point in her recent article at A List Apart.
Adding half a second to a search results page can decrease traffic and ad revenues by 20 percent, according to a Google study. The same article reports Amazon found that every additional 100 milliseconds of load time decreased sales by 1 percent. Users expect pages to load in two seconds—and after three seconds, up to 40 percent will simply leave.
“Most people make the mistake of thinking design is what it looks like. That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.” said Steve Jobs and I remember this by heart and try to follow it always.
These days there’s been a trend of using big heavy images and multiple web fonts which highly affect performance of a website, especially on mobile devices.
Brad Frost emphasizes on performance saying:
The road towards better performance doesn’t start with developers or technology stacks. It begins with a shared interest on everyone’s part in making a product that’s lightning fast.
I have said “NO” to few great opportunities from Google, AOL, Intel, Groupon and few others because of my interests and priorities in life.
Learn to say “NO” from my favorite designer – Jason Santa Maria. He talks about when and why to say NO, and whom to say NO.
There are principles, rules and best practices for everything we do. Last week while working on revising colors for graphs of Unmetric, I wanted to refresh myself and learn more about using colors in graphs. Luckily I found a brief but useful articles by Stephen Few, author of Information Dashboard Design which I read last year while working with Intel.
Here are 9 rules by Stephen about using colors in charts and graphs:
- If you want different objects of the same color in a table or graph to look the same, make sure that the background—the color that surrounds them—is consistent.
- If you want objects in a table or graph to be easily seen, use a background color that contrasts sufﬁciently with the object.
- Use color only when needed to serve a particular communication goal.
- Use different colors only when they correspond to differences of meaning in the data.
- Use soft, natural colors to display most information and bright and/or dark colors to highlight information that requires greater attention.
- When using color to encode a sequential range of quantitative values, stick with a single hue (or a small set of closely related hues) and vary intensity from pale colors for low values to increasingly darker and brighter colors for high values.
- Non-data components of tables and graphs should be displayed just visibly enough to perform their role, but no more so, for excessive salience could cause them to distract attention from the data.
- To guarantee that most people who are colorblind can distinguish groups of data that are color coded, avoid using a combination of red and green in the same display.
- Avoid using visual effects in graphs.
Read the article [pdf]
I’ve done both and totally agree that Prototyping wins over Wireframing. I use Keynote for former and Fireworks for latter. However, Prototyping consumes more time thus needs more budget, which is worth it.
Leisa Reichelt lists 11 points why prototyping beats wireframing. Here are top 3:
- You’re making, not documenting. You can feel the thing you’re making.
- You’ve got a thing you can start testing, in all kinds of ways, almost immediately. Prototyping is more like experimenting than describing your grand design.
- Prototypes create the impression of real progress—of something actually happening—in a way that wire framing never does.
I’ve read a few books and good articles about baseline grid and how to use it for the Web. But over the time I’ve found it difficult to fit it in my usual design process. Jason Santa Maria share his problems with baseline grids on the web and other technical issues.
It’s incredibly difficult to maintain a baseline grid in a medium as inconsistent and fluid as a web page. Images, form elements, rendering differences between browsers and platforms: these can all throw a baseline grid out of phase. This only gets worse when you’re setting up a design for someone else to implement or maintain, as we often do in client work. In other words, if you’re not intimately familiar with the intricacies of a given grid system, it’s incredibly easy to mess it up.
P.S. I still religiously use vertical grid :)