The product team should research two iterations ahead, design one iteration ahead, and review the previous iteration. — attributed to Cennydd Bowles, Design Manager at Twitter
There’s a lot of mantra in discussing mobile, such as ‘keep it simple’, ‘feature rich, user poor’, and ‘remember the 80/20 rule’. With such competition, i’m hard pressed to think of a new catch phrase to describe the process of mobile design.
I suppose if i was using mobile to type my mantra, it would come out in the form of a short text character burst: ‘delight them with simplicity and efficiency’.
Ok, so I guess I just wrote my mantra.
Well, now that i’ve written it, i have to consider how to advise accomplishing it. One thing that can’t be omitted – so we might as well start there – is knowing our users.
Of course, it’s easier to know our users if we already have an existing product. Then again, it’s easy to assume we know our users because we have an existing product – and the tried and true response to assume is don’t assume, or you make an ass out of u and me.
So how do we really get to know our users? *User interviews is irrefutably the best way. However, analytics helps too. For those with an existing product, examining the analytics to see which 20% of our features are being used on mobile devices is a primo place to start.
Then there’s the startups with a unique idea – they don’t have users yet. Therein lies the benefit of not having to edit somebody else’s work, i.e., you can start from scratch. Have you ever been handed a document that’s been authored by others, and that you have to edit? The task can be overwhelming. It’s like inheriting a code base developed over several years – versus creating the whole application from scratch. Or a piece of furniture from Ikea – and being told to add onto it, but make sure it matches.
My advice? Go Japanese – design, design, design – add layer upon layer upon layer – then start taking away, stripping down, removing, re-shuffling – heck, throw it away, breathe, then start from scratch. Ultimately, you’ll enjoy the process because you’ll be constantly problem solving – and you’ll wind up with something so simple – and efficient – that it delights. The quality will surface in your work, while the waste will get siphoned down the drain.
This Japanese design process i’m referring to applies to whether you’re re-writing an inherited design; or starting from scratch with a new one. In the case of a code base, Git Hub is our hero – and in the case of a tech spec, I simply duplicate my document and keep a series of sequential revisions in Google Docs. (For you Ikea builders, you’re on your own).
In summary, when designing for mobile, in order to ‘delight them with simplicity and efficiency’, we have to understand our users through user interviews and analytics – and we have to iterate by building and tearing down, forgetting and rebuilding – over and over again. As a result of our design process, we’ll understand our product so intuitively that we’ll be able to serve up it’s good parts and omit the rest. In return, our users will feel delight for the efficiency in our design and (hopefully) fall in love with our creation.
*note: in that we can’t user test without user interviewing, I’m bundling user interviews and user testing into the one term user interviews
Often times, search doesn’t work well. It is not uncommon to get a Search Results page with a message reading “no results found for [your search term]”. That’s why it’s important to not rely on Search; rather, to have it be supplemental to navigation. Thus, when weighing the relationship between search vs navigation, it is key that navigation educates and leads users to find the essential content in a web site or application; and search is a bonus treat for power users that know what they are looking for.
Let’s take a look at how Amazon.com educates their users using meticulous navigation. The search filters in the Category Landing Page in the example below show us that the products come in a ‘waterproof version’ and an ‘800 yard’ version.
A user who knows exactly what they want to buy will type into search ‘waterproof rangefinder’. However, a person whom is browsing for rangefinders might land on this page, and then realize that they exist in a waterproof model. That kind of discovery is great UX because it leaves the user feeling empowered – they have gained knowledge, and thus feel smarter. And it’s better for business too, because an educated user is one that’s more likely to revisit t the product for future purchases – and/or make the current purchase they are contemplating.
If it’s not negotiable it’s not agile. — Anonymous, at allaboutagile.com
Product Management is not democracy; but it requires diplomacy … by the end, it’s not my plan, but it’s our plan. — Bruce McCarthy
One way this ux tool UserVoice can be used is to quickly install a forum in your company’s website to get feedback from colleagues while iterating on a Product Roadmap. Thus, everybody has buy-in while components of the Roadmap are being developed. Your colleagues can submit and up-vote/down-vote ideas.*
From the UserVoice website:
What is UserVoice?
UserVoice is a software-as-a-service provider of customer support tools that include:
- Feedback forums to understand the ideas users care about most.
- A support ticket system to track and respond to customer support requests.
- A knowledge base to answer common questions and help users find the information they need when they need it.
*additional info: Bruce McCarthy, Lean Roadmapping: Where Product Management & UX Meet. Video. UIE.com
I recently had a startup ask me to brainstorm solutions to their current product. After a 1.5 hr session, they wanted to turn it into a 1-day project. But my reply was “no way – you can’t fix a product in 1 day”. Since then, I’ve been thinking more and more about what quantifies as Lean – and does it mean UXers should be able to create 1-day bite size projects?
My answer is still “no way”, however, there are steps we can take in a 1-week sprint that I find helpful. These are based on the theories of C. Todd Lombardo; and explained by Bruce McCarthy in his talk titled: Lean Roadmapping: Where Product Management & UX Meet.
Here are Lombardo’s steps toward a 1 week Design Sprint:
1) Interviews on Monday
2) Compare notes on Tuesday
3) Brainstorm what you want to prototype on Wednesday
4) Build the prototype on Thursday
5) Show it to Monday’s interviewees for feedback/validation on Friday
Of course, to hold interviews on Day 1, there has to be a considerable amount of planning on Pre-Day 1 in order to: get those interviews set up; UX and stakeholders assembled; and the re-visit on Friday with the Day 1 attendees. So, theoretically, a 5-Day Design Sprint works; but don’t expect to accomplish it in 5 days.
There is a legendary tale of the famed UX Designer Jared Spool asking his retailer client to change a part of their checkout flow.
The client (a $25 billion retailer), had a button requiring users to create an account or fill in their account information before entering their credit card.
Through user testing, Jared’s team found that new users did not want to create an account for a 1x purchase; and returning users whom had forgotten their login credentials did not complete the purchase 75% of the time.
The UX Solution was: They removed the Register button and replaced it with a Continue button and simple message stating that the user did not need to register to purchase on the site. Revenue that month increased by $15 million, adding up to $300,000,000 over the course of the year.
Read the full article at UIE.com
The double-D rule is simply: Differences are Difficult
When designing interfaces, it’s important to remember that inconsistencies create challenges for users. If our users have already used a feature in our application, such as a left side navigation, don’t suddenly move the navigation to the right side of the page. It’s one more point of cognitive load the user will have to absorb – even if it’s the exact same menu, just shifted, it’s still forcing the user to think – and thus taking up some useful processing that would be best applied to newer/different concepts. Conclusively, don’t create differences; rather, be consistent.
The best way to predict the future is to invent it. — Alan Kay