Personas are a flexible and powerful tool for user researchers. They’re also one of the most misunderstood. When done well, they ensure the team focuses on the needs and delights of their users.
View original here:
The Essence of a Successful Persona Project
Right now, in a far off cubicle, someone is designing an e-commerce checkout application. It’s not unusual. There are thousands of existing e-commerce sites with their own checkout applications. And I can bet in the future there will be thousands more.
Excerpt from:
Web Apps: Where Business Needs and User Needs Collide
It had been going so well. The shopper, a grandmother looking for a holiday gift for her two grandsons, had decided to buy a Wii video game the boys really wanted: The Beatles: Rock Band.
In Google’s search box, she typed “wii beatles rock band”, following the instructions the boys’ dad had given her, which produced many promising results. Being a loyal Kmart shopper, she was excited when Kmart’s site showed up in the sponsored listings and clicked on the link without any hesitation.
That’s where the problem started.
View original here:
Three Perils with Search Landing Pages
Jimmy is looking for a law school. For the last 10 years, he’s been an electronics engineer at a very innovative company. He’s realized he enjoys working with his company lawyer to file new patents and thinks he could be a good patent lawyer himself, especially with his high-tech engineering background.
Jimmy was excited about exploring schools. With us peering over his shoulder, he started searching Google for a local school, finding one that he recognized as having a great reputation.
Reaching the landing page of the school’s site, he told us he had three questions he needed answered: Does the school go into enough depth on intellectual property law, especially patents, to make Jimmy happy? Would Jimmy find the school affordable? What does it take to complete a law degree through evening courses?
Unfortunately, the site didn’t help him with his questions.
Somewhere, right now, there’s a team creating a new design with some amazing, never-before-seen functionality. And to take advantage of that awesome, groundbreaking functionality work, their users will need to login.
Login functionality isn’t new. It’s not awesome. It’s not very challenging to develop. Teams are designing this functionality as if it’s never been built before.
But it has been built before. Teams, all over the world, have built login functionality into their applications about a million times. And yet, here we are, doing it all over again.
All this re-creation and re-invention isn’t just inefficient, it leaves the team open to problems. Because it’s not the sexy part of their project, it’s likely to get less attention, resulting in an unusable and frustrating experience.
This is where the Re-use Trinity — Patterns, Components, and Interaction Design Frameworks — comes in.
Here is the original:
Components, Patterns and Frameworks! Oh My!
