Look at feature requests as a request for a new or improved workflow, not a new feature
1. Listen to client feedback with an interpretive ear, and don’t be afraid to dig deeper to identify underlying problems
2. Sometimes feature requests are actually usability issues in disguise
3. Sometimes the product features clients request are actually new product offerings in disguise
4. Focus your energy on hearing the users’ needs, not the users’ wants
5. More features do not equal a better product
Read more from the source: InVision Blog
User experience begins with strategy and requires layers of feature scope, site structure, site skeleton, and “surface” or the graphic interface
In a post adapted from a short talk Mike Atherton gave at the SODA Social meetup in London on May 14th, 2015 he writes:
In UX there’s no ‘one-size-fits-all’ design pattern for a given situation. Despite what clients ask, there’s no more a ‘best practice from a UX perspective’ than there is a ‘best recipe from a cookery perspective’.
“Give me six hours to chop down a tree and I’ll spend the first four sharpening the axe.” – Abraham Lincoln
It’s about research, understanding, and evaluation. Figuring out the right problem to solve, before dipping into our toolbag of methods and patterns to solve it.
Read the post at Medium
Ramjet makes it looks as though one DOM element is capable of transforming into another, no matter where the two elements sit in the DOM tree.
It does so by making copies of the two elements (and all their children), setting a fixed position on each, then using CSS transforms to morph the two elements in sync.
View the demo at rich-harris.co.uk
I gave this UI measurement tool a whirl and I was really impressed
Pixel Winch is a screen measurement app with a unique approach. Rather than overlaying complicated controls on top of your existing workflow, it combines aspects of a traditional image editor with the quick access of a modal interface (similar to OS X’s Launchpad or Dashboard).
Read more from the source: ricciadams.com
Before you choose icons for your UI, have a look at real-world cases of what works and what doesn’t
Thomas Byttebier is a freelance web designer creating minimalist and easy to use websites and user interfaces. Thomas lives and works in Gent, Belgium.
He writes: Of course I can see why icons grew popular in user interfaces. Firstly, they make the UI more graphically pleasing. And when done right, they can certainly give your app visual personality. That’s two good things.
Moreover, an icon can often replace a long descriptive group of words. As screens get smaller, this is much welcomed. But herein lies the design trap, because most icons are unclear. They make people think. What good has a beautiful interface if it’s unclear? Hence it’s simple: only use an icon if its message is a 100% clear to everyone. Never give in.
Read more from the source: thomasbyttebier.be
A must read: Jeff Atwood researches and explains how to make your sign in and register process a smooth user experience
Jeff Atwood of Coding Horror writes:
And one of the coolest things my college professor Mr. Pausch ever taught me was to ask this question:
What’s the God algorithm for this?
Well, when sorting a list, obviously God wouldn’t bother with a stupid Bubble Sort or Quick Sort or Shell Sort like us mere mortals, God would just immediately place the items in the correct order. Bam. One step. The ultimate lower bound on computation, O(1). Not just fixed time, either, but literally one instantaneous step, because you’re freakin’ God.
This kind of blew my mind at the time.
So when we set out to build a login dialog for Discourse, I went back to what I learned in my Algorithms class and asked myself:
How would God build this login dialog?
Read more from the source: blog.codinghorror.com