This category features quality articles on usability, information architecture, interaction design and other user experience (UX) related topics – for digital (Web, mobile, applications, software) and physical products. Through these articles, experts and professionals share with you their valuable ideas, practical tips, useful guidelines, recommended best practices and great case studies. Curated by Chui Chui Tan. Subscribe to the RSS-Feed.
User testing is hard. In the world of agile software development, there's a constant pressure to iterate, iterate, iterate. It's difficult enough to find time to design, let alone get regular feedback from real users.
For many of us, the idea of doing formal user testing, is a formidable challenge. There are many reasons why: you don't have enough lead time; you can't find enough participants, or the right type of participant; you can't convince your boss to spend the money.
Information architecture (IA) is one of those buzzwords you’ve probably heard before. It refers to the organization of the information on your website and how it all fits together. When planning your IA, involve users of your website in the process as soon as you can.
In this article, we’ll discuss card sorting, a tried and true technique for doing just that. We’ll go through some practical tips for running a card-sorting session, and also cover some examples.
Designer Paul Rand once said, “An understanding of man's intrinsic needs, and of the necessity to search for a climate in which those needs could be realized, is fundamental to the education of the designer.” Prototyping helps us to unveil and explore these human needs, opening the door to insightful interaction and more empathetic design solutions.
Low-fidelity prototypes, in particular, are rough representations of concepts that help us to validate those concepts early on in the design process. Throughout this article, we will look at some of the features that make low-fidelity prototyping a unique tool to radically improve your work and to build an environment in which users’ needs can be truly realized.
As mobile designers, we have a stark decision to make: do we spend time learning new tools and changing our design processes to create our own transitional interfaces, or are the tools that we've been using good enough? There's an old writing adage that advises writers, whenever possible, to “show, don't tell” when bringing characters to life. The goal is to reveal the story through the character’s experiences instead of the author’s.
When designing mobile products, we share a similar burden. Dammed up inside our heads are creative waterfalls of fresh interactions, transitions, and animations. But how are we supposed to communicate them to our teams, our developers? How do we get them out of our heads? Through a game of charades?
Having addressed the information architecture and the various systems of navigation in the first two articles of this series, the last step is to efficiently simplify the navigation experience — specifically, by carefully designing interaction with the navigation menu.
When designing interaction with any type of navigation menu, we have to consider symbols, target areas, interaction event, layout, levels, functional context. It is possible to design these aspects in different ways. Designers often experiment with new techniques to create a more exciting navigation experience. And looking for new, more engaging solutions is a very good thing.
To you, modal windows might be a blessing of additional screen real estate, providing a way to deliver contextual information, notifications and other actions relevant to the current screen. On the other hand, modals might feel like a hack that you’ve been forced to commit in order to cram extra content on the screen. These are the extreme ends of the spectrum, and users are caught in the middle. Depending on how a user browses the Internet, modal windows can be downright confusing.
Modals quickly shift visual focus from one part of a website or application to another area of (hopefully related) content. The action is usually not jarring if initiated by the user, but it can be annoying and disorienting if it occurs automatically, as happens with the modal window’s evil cousins, the “nag screen” and the “interstitial.”
Many of today’s hottest technology companies, both large and small, are increasingly using the concept of the minimum viable product (MVP) as way to iteratively learn about their customers and develop their product ideas. This two-part series, looks into the product design process of Dropbox’s Carousel.
Part 1 covered the core user, their needs and Dropbox’s business needs, and broke down existing photo and video apps. This second part is about Carousel’s primary requirements, the end product, its performance and key learnings since the launch.
Aspiring to beauty in our designs is admirable. But it doesn’t guarantee usability, nor is it a product or marketing strategy. Like “simple” and “easy” before it, “beautiful” says very little about the product. How many people, fed up with PowerPoint, cry out in frustration, “If only it were more beautiful”?
Many of today’s hottest technology companies, both large and small, are increasingly using the concept of the minimum viable product (MVP) as way to iteratively learn about their customers and develop their product ideas. By focusing on an integral set of core functionality and corresponding features for product development, these companies can efficiently launch and build on new products.
While the concepts are relatively easy to grasp, the many trade-offs considered and decisions made in execution are seldom easy and are often highly debated. This two-part series, looks into the product design process of Dropbox’s Carousel and the product team at UXPin shares our way of thinking about product design, whether you’re in a meeting, whiteboarding, sketching, writing down requirements, or wireframing and prototyping.
High school. I won’t lie: I did not have the highest grades in my graduating class. Some classes and lessons were so poorly designed and delivered that I would frequently become frustrated and fatigued and would ultimately shut down. The contents of the lessons would just wash over me. The experience wasn’t pleasant, and the results were obvious from my transcripts.
But I did well in a few classes. The major difference was the teaching style. Currently, I am a user experience (UX) and user interface (UI) designer of mobile and web applications. In a way, like a teacher, I need to present information in an easily understandable way to new visitors. I need to consider how my students (end users) consume the information that I provide. So, reflection on my high-school experience serves a purpose (aside from painful fashion memories).