Why early wireframes need to look hand-drawn
There are many kinds of mockups to show users and stakeholders. Different levels of fidelity will elicit a variety of feedback. In UX, we generally assume that the lower the fidelity, the more we're looking at feedback on interaction, organization of pages in a structure, and page to page flow. Higher fidelity mockups are better for feedback on layout, colors, content wording and overall design aesthetic.
Given the availability of high-resolution bootstrap PSDs, it's easy to quickly build a few screens in a high-fidelity and think that these will suffice for getting feedback on basic organization and flow issues. Don't make this mistake. If it's early in the process, and your organization is still trying to understand the problem or the proposed solution, use low-fi mockups in the hand-drawn style.
Mockups that looks 'rough' or hand-drawn prevent people from getting caught up in the details, and help them focus on one thing at a time. You get better feedback on the high-level idea on what you're trying to accomplish, rather than the details of layout, color etc. But why is it so problematic to present hi-fi mockups early on in the design process?
Pay attention to psychology
Giving someone a high-resolution mockup and then asking them 'not to pay attention to details' violates some shop-worn principles of human psychology. People want to talk about things they know. And many people, especially non-visual people, will want to comment on the details (technical accuracy of content etc) you are presenting. This isn't their fault, they're simply applying their knowledge to what they see. Actually, it's your fault as a designer for presenting them with something you should know won't elicit the kind of feedback you are looking for.
Most people aren't good at juggling multiple things in their imagination: we're horrible multi-taskers. Simultaneously giving feedback and imaging how the design 'should be' is simply too much. Give stakeholders one thing to comment on, and make sure the details are obscured - by using wireframes in the hand-drawn style. I don't mean inaccurate or sloppy. I mean mockups that look hand-drawn - here's a style guide.
Understand all your users
Being a UX designer means understanding your users - ALL your users. Stakeholders and peers consuming your wireframes are your users too, and you need understand their needs, mental modals and problems.
People looking at your wire-frames want to:
- Give feedback (they want to talk)
- Know they were heard
- Know their comments made an impact on the product
Getting better feedback on mockups is a win-win. The product will be better, and trenchant comments will make it into the final product design. People will feel heard and appreciated. Help this process by giving your peers a wireframe that makes it clear that you're early in the process; and that you're still struggling to understand the problem and solution. You'll drive a more productive conversation, get better feedback, get a better product, and win points by listening and integrating feedback into the end product.
Designing an iPhone app? Ditch the wireframes
You don't need extensive wireframes for iPhone apps. Get a solid site map and page flows together, and jump straight into design, you'll be OK (I promise)
Since phones have a pretty limited UI palette, it makes more sense to start with the end. Design your high-res button elements, fonts, icons and menu bars. Then just start throwing it together, you'll find all you need to know in the process of actually designing something that looks close(r) to the final product. Read more
Media Queries for Business apps
While media queries are typically used to handle a site's transition between different devices and screen sizes, they can also be used to enhance the desktop experience.
Why use media queries?
Many enterprise users have wider monitors, so as designers we should take advantage of this horizontal screen real estate to deliver a stellar user experience - and use media queries to deliver additional tools on wider monitors.
Property management applications underutilize the right-hand side of the screen. Property managers live by inquiries - travelers emailing them regarding property availability etc. Most companies find that the faster they respond, the higher % conversion rate the inquiries have (they convert from inquiries into bookings). So delivering a new inquiry instantly to a property manager is of paramount importance to their bottom line.Read more
Build a better dashboard
Every product starts out as something great, and at some point, some percentage invariably end up as a single-page dashboard.
Despite their ubiquity in cars, (single-page) dashboards are useless everywhere else. When you're driving, you need to see one metric: the speed you are traveling. Yes other data needs to bubble up - particularly alerts about simple problems that are easy to fix and catastrophic if they are let go (low oil, low coolant) but everything else is either beyond the purview of a dashboard (tire pressure) or simply not important. How this metaphor got carried over to software I have no idea, but it has to stop.
In a business you have multiple metrics that you need access to immediately, and no one piece of information will give you the overview of your business that makers of dashboards hope it will. You have incoming emails from internal and external sources, you have financial statements, you have business transactions (at one or more points per day), you have projects that need managing - and on and on into the minutiae of the particular business. Read more
Let users design your product
(They'll do a better job than you)
All the objections are true: users don't have design experience; Steve Jobs said never to ask users what they want; users don't really understand the tech space; they can't know what everyone needs, because they are too embedded in their own workflows.
And let's be clear - I don't mean literally let them sketch it out, design it and develop it.
But it's important to be able to lead a group of your users in a requirements gathering session. This is much more important than sitting down with a bunch of people in your company and trying to imagine what your business clients might need. Read more