Category: UX Design
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. .
Popular tags in this category: Usability, Design, User Experience, UI, Psychology, Process, E-Commerce, Content.
The first thing to understand about content strategy is that no two people understand it the same way. It’s a relatively new — and extremely broad — discipline with no single definitive definition. A highly informative Knol on content strategy defines it as follows: "Content strategy is an emerging field of practice encompassing every aspect of content, including its design, development, analysis, presentation, measurement, evaluation, production, management, and governance."
This definition is a great place to start. Although the discipline has clearly evolved, this breakdown of its scope makes perfect sense. The aspects of content strategy that matter most to Web designers in this definition are design (obviously!), development, presentation and production. In this article, we’ll concentrate on the relationship between content strategy and design in creating, organizing and displaying Web copy.
In this article, I’d like to reacquaint you with the humble workhorse of communication that is the paragraph. Paragraphs are everywhere. In fact, at the high risk of stating the obvious, you are reading one now. Despite their ubiquity, we frequently neglect their presentation. This is a mistake. Here, we’ll refer to some time-honored typesetting conventions, with an emphasis on readability, and offer guidance on adapting them effectively for devices and screens. We’ll see that the ability to embed fonts with
@font-face is not by itself a solution to all of our typographic challenges.
In 1992, Tim Berners-Lee circulated a document titled “HTML Tags,” which outlined just 20 tags, many of which are now obsolete or have taken other forms. The first surviving tag to be defined in the document, after the crucial anchor tag, is the paragraph tag. It wasn’t until 1993 that a discussion emerged on the proposed image tag.
Right there in the center of my boilerplate for design proposals is a section that I glare at with more resentment each time I complete it. It’s called “Deliverables,” and it’s there because clients expect it: a list of things I’ll deliver for the amount of money that I specify further down in the document. Essentially, it distills a design project down to a goods-and-services agreement: you pay me a bunch of money and I’ll give you this collection of stuff. But that isn’t what I signed up for as a designer. Frankly, I don’t give a damn about deliverables. And neither should you.
Case in point: for months now, I’ve worked consistently with a particular client for whom I do almost no work on actual design artifacts (wireframes, prototypes, etc.). Rather, I hold frequent calls with the main designer and developer to go over what they’ve done with the product (i.e. poke holes in it) and what they should do next (i.e. help prioritize). Some days, they hand me wireframes; sometimes, a set of comps; other days, live pages. Whatever the artifact, our purpose is always to assess what we have now versus where we need to get to.
Have you read Where the Wild Things Are? The storybook has fluidity of content and design figured out. It goes that one night, protagonist Max “wore his wolf suit and made mischief of one kind or another.” He hammers nails into walls, pesters a small dog. Author Maurice Sendak doesn’t explain these hijinks textually for the reader. The mischievous acts are illustrated on the right-hand pages. Readers make the narrative connections for themselves.
The words and pictures depend on each other for completeness. Web designers can employ the same complementary dependence of graphic and text in their own work. It encourages a sense of belonging and can create strong first impressions, which are often essential to effective Web design.
There are many ways to skin a redesign (I think that’s how the saying goes). On a philosophical level, I agree with those who advocate for realigning, not redesigning, but these are mere words when you’re staring a design problem in the face with no idea where to start. This article came out of my own questions about how to make the realignment philosophy practical and apply it to my day-to-day work — especially when what’s needed is more than a few tweaks to the website here and there.
I propose an approach to redesign through realignment, by using a framework adapted from Edward Tufte’s principles on the visual display of quantitative information. But first, a little context.
The country selector. It’s there when you create an account for a new Web service, check out of an e-commerce store or sign up for a conference. The normal design? A drop-down list with all of the available countries. However, when conducting a large session of user testing on check-out usability (which we wrote about here on Smashing Magazine back in April 2011), we consistently found usability issues with the massive country selector drop-downs.
Jakob Nielsen reported similar issues as far back as 2000 and 2007 when testing drop-downs with a large number of options, such as state and country lists. So, this past summer we set out to redesign the country selector. This article focuses on the four design iterations we went through before arriving at the solution (free jQuery plugin included).
Contrary to what you may read, peppering your form with nice buttons, color and typography and plenty of jQuery plugins will not make it usable. Indeed, in doing so, you would be addressing (in an unstructured way) only one third of what constitutes form usability.
In this article, we’ll provide practical guidelines that you can easily follow. These guidelines have been crafted from usability testing, field testing, website tracking, eye tracking, Web analytics and actual complaints made to customer support personnel by disgruntled users.
This is the final part in a three-part series on how to build and grow successful user experience teams in agile environments. It covers challenges related to organization, hiring and integration that plague UX teams in these situations. The perspective is that of a team leader, but the tactics described can be applied to multiple levels in an organization.
For many designers, coming into an agile environment feels like settling in a new country. There are different dialects and new rituals. Furthermore, design is treated very differently than they are used to. It is, in fact, through ritual that a UX designer is able to integrate in their agile team. In addition, it is incumbent on the designer to open up the design process for collaboration and critique from other members of the team. Together, these tactics have the potential to yield a successful agile team.
User experience design isn’t just about building wireframes and Photoshop mock-ups. It extends to areas that you wouldn’t necessarily think are part of the discipline.
For example, your customer service department can have a huge impact on your website’s overall user experience. Similarly, the design of your user experience could have an awfully big effect on your customer service department. Of course, not all of your users will interact with the customer service department, but for those who do, their experience can improve or destroy the customer relationship.