While reading an article about the shift to responsive design, ‘View Full Site’ must die by Jared Spool I came across a reference to Brad Frost’s Atomic Design system. In Atomic Design a site is made up of Atoms (buttons, fields, images), molecules (combinations of atoms), Organisms (combination of molecules), Templates (groups of organisms forming pages and displaying layout) and Pages (specific instances of a template). A very clear way to break down the components of a site with a chemistry twist. I particularly like how each higher level builds on interactions with the previous level. Atoms by themselves aren’t that interesting but molecules…there’s something working together.
I highly suggest a read if you aren’t familiar with it!
Here is a quick example of some clever touches that makes me (as a user) really appreciate the care taken in the creation of this site. It is rather surprising to say this, but it’s built in a way that lets me know that the designers of this site actually do USE it, not just build it. I’ll give two quick examples which made me far more happy than you think it would. (Perhaps it’s because I feel as if they read my mind and gave me exactly what I needed without asking?)
Here we have a screenshot snippet of a list of games that are on sale from GOG.com.
And here at the bottom of the list we have…a list of the games I already own! It still wants me to know that those games are on sale, but doesn’t want me to waste my time sorting through my library. Brilliant and efficient!
I’ve only just begun exploring this website but I’ll leave you with one more example that made me happy. An English version of their legal user agreement.
My wish for you: May your user agreements always have “English” versions.
Having just gone through the MVP process for the next version of the application I work on, I found this article “The Experience Makes the Product, Not the Features” from Lee Dale particularly apt. The article discusses how to have a focused MVP, reduced to it’s most important, most critical function of your application.
But my experience seems to be a little different. The most frustrating thing, for me, isn’t a bloated MVP. It’s a cut to the bone, “Seriously, this is the smallest amount we can develop and still call it that feature,” version with that graveyard of enhancements that sit out to side hopefully awaiting a “just in case” scenario. Too often the cuts are small things that would increase the user’s experience in a big way. While new features are the meat and bread of an application, it is the subtle things, the A1 and cinnamon butter sprinkled on top, that really make the user raise their eyebrows in surprise. (Delighted surprise. I don’t know if there is any other form of surprise that you ever want your users to feel. Unless you work on a horror themed product.)
For example, your application decides to add a search feature. Highlighting the relevant matches/text in a search feature is such a small thing respective to the work it takes to code the search, but this could be considered a “Nice to have” and not a critical function. But for one, users tend to expect this behavior having been ‘trained’ by other applications that use this and for another thing it makes it easier to see how something matches to the search criteria. Highlighting improves the speed and accuracy of the user searching for something. So yes, the essential functionality is the “search” function, but the highlighting allows the user to use search more efficiently.
There is a happy ending, at least for this highlighting in search example. I fought for (and got) the highlighting but compromised by agreeing highlighting dates brought a larger level of complexity and risk to the code. There’s always a next version… 😉
My wish for you: May your product management’s definition of “essential” always line up with yours.
Here is something to keep in mind when analyzing or planning any data collection. As I am analyzing data for my thesis, this is particularly apt. Credit goes to LOR from Online Behavior.
I’ve been reading through some of UX Mastery’s links on their twitter feed @uxmastery. I found this article delightful and present for your reading enjoyment, “10 Lessons The Blues Brothers Can Teach Us About UX” by Matthew Magain.
In particular I found number seven to be applicable to any situation. Be prepared for collateral damage. Not everyone is going to like what you do/design. The question remains, does it work? Can it be improved? Are the complaints reasonable? Don’t be afraid to reassess at any time. Designers aren’t gods, they can make errors in judgement. At the same time, don’t be afraid to stand your ground when it is merited. If it works, it works, regardless of how people feel about it. Like all things though, its all about balance. But remember, sometimes people complain just to complain or just because its something new. This is when you smile, nod your head and say you will take a look at their complaint. Take a look, nod your head if you’re right, shake your head if you’re wrong and fix it and move on. The world is full of opinions and yours, with your experience and skills, is one them.
A lot of the time we forget that usability goes hand in hand with accessibility. There is no point to creating an awesome website or product if someone can access it. But what do I mean by accessibility? According to Usability.gov, “About eight percent of the user population has a disability that may make the traditional use of a Web site very difficult or impossible. About four percent have vision-related disabilities, two percent have movement-related issues, one percent have hearing-related disabilities, and less than one percent have learning-related disabilities.” In short, they have a disability that makes traditional ‘viewing’ of a website difficult or impossible. And so, as a usability designer, it is also your job to make certain that they can both access and use your designs.
While in the grand scheme of things eight percent doesn’t seem like much, its very easy to accommodate your designs for less the usual needs. And, like most things, once you remember to keep the standards in mind and design around them a couple times, you’ll forget that you ever had to learn accessibility standards!
The website Section508 centers around the document which outlines the standards. I recommend you read through it, but if you want to get to the actual guidelines, they are located under Subpart B- Technical Standards. This is where you get the, “do this” part of the document. Several of things outline would naturally occur to a designer. But it is very easy to forget how others may have to interact with a device. For example, what if your device has an instructional video and the person viewing it is deaf? They need subtitles or a text option. Also, those users that are low vision or blind need the ability for a screen reader to read to them what is on the page, which requires that your code is ‘legible’ to the screen reader. (For example, naming your photos on a site. It needs a descriptor so the person with low vision can have the description of the photo read to them)
What about those users that are color blind? Does your design use color in a way that if you weren’t able to distinguish between colors, you would get lost? Like so much dealing with usability, accessibility is all about empathy. Put yourself in their shoes and design for them.
There are many things to consider about accessibility but there are plenty of resources. In particular, I’d like to direct your attention to W3.org’s section on accessibility which can help you put yourself in their shoes as well as Usability.gov‘s entire site. Here’s a list collected by Microsoft about the types of assistive technology available that you should keep in mind when designing and here’s an interesting page by Google on how to use the accessibility features on several of their products. (So you can try them out yourself)