Defending your design decisions
Something no one ever tells you about working as a product designer is that you are constantly defending your decisions. As soon as you start designing wire frames, you'll be questioned about your choices. This process is consistent throughout the development and launch of the product. It's a back-and-forth, and involves as much problem-solving as defense of ideas. There should be a healthy mix of collaboration and disagreement in deciding on a workable solution.
It's all just pixels until it's in code
Then comes post-launch, and the gathering of feedback from users in the form of emails, customer service calls and analytics data. This part is tough. You'll be called to defend decisions many months after you actually made them. You went on with your life, but the business and your customers are stuck with the outcomes of your choices that made it into the product.
If you've kept a decent journal, then you'll have at least some reference for the context around what were probably difficult choices. Once it's in code, you'll get a chance to use it and with the benefit of distance have a fair gauge of how your gut instincts and company process are leading towards (or away from) good design.
Revising post-launch
In an iterative design organization, it's OK to revise based on seeing live code, it's just not ideal. It means that other projects will have to be pushed back, deadlines missed, etc. Obviously, it's something to avoid if you can. So to avoid this, you want to be able to: 1) make good decisions; and 2) defend your good decisions.
Making good decisions (a non-exhaustive list)
- Include relevant people in decision-making meetings and conversations
- (Know who relevant people are)
- Note exceptions. If your product manager gets his or her way with something you disagree with, make a note of it in your work journal
- (Keep a work journal)
- Research patterns and existing solutions - be informed of what's come before
- Design in the right order - start on a whiteboard or paper, then move to hand-drawn wire frames, then to hi-fi mockups
- Make your mockups clickable, and share these with the team and potential users
So you've made what you feel are well-informed 'good' decisions. Now it's months later, and someone is calling you out in a meeting for a decision they disagree with. What do you do?
Mounting a spirited defense
- Stay calm
- Remind anyone questioning the results that you went through a process to get there (you did go through a robust process, right?)
- Recall all the work, feedback and rounds of iterations that went into the current design being called into question
- Challenge the challenger; if there's no user base and bank of statistics about use, then all questioning is speculative.
- I repeat: in the absence of data, all questioning is speculative
- Cite analytic data. Cite feedback, or lack thereof.
- Story wins. Tell a compelling story about the problem you were trying to solve, the research you did to understand how others have solved this problem.
- In the face of contrary proof of success or failure, don't be afraid to change your mind in a strong, sure way. Nothing diffuses attack like agreement
If worst comes to worst, ask that your design be shown to actual users in order to gather data about how they use it. Leaders are often wrong, but they stick to their guns given the information they have at hand. If the information changes (as in solid data from users) then don't be afraid to change your mind.
And remember that this back and forth is part of being a professional designer. Professionals have been on the extreme end of both sides. If you're right or if you're wrong, remember that people respect an even demeanor.
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.
How to Hire Awesome UX Designers
This article first appeared on LinkedIn Pulse, LinkedIn's effort to get its users to write and create LinkedIn content for free. I have mixed feelings about publishing on this platform. Gaining simple 'exposure' seems oddly close to working a job to have a 'great portfolio piece'. Realizing that my website will get even fewer views than LinkedIn, it made sense to try out my writing in different venues.
Hiring a good User Experience (UX) designer is tough - no question. Hiring managers find many candidates who are long on talk and short on verifiable certifications, degrees or experience. But separating valuable candidates from the inexperienced or under-qualified isn’t as daunting as it seems, even if you don’t have much experience hiring for this kind of position.
When hiring a UX designer, look mainly at deliverables – what the person has produced as part of his past work. A valuable UX designer will have a portfolio full of clickable prototypes. They should produce these without writing too much code or spending too much time (or money). The deliverable (in the form of a click-through mockup) helps product teams understand what they'll deliver to users, get feedback, and decide if it’s the best course of action. Click-through mockups also help developers determine the scope of what they'll be making and how that application should function through animations, messaging and other interactions.
A word of warning: if a candidate shows only static layouts or wireframes, chances are high that he won't be valuable to your organization as a UX designer. Deliverables such as written requirements, user personas etc. are ultimately not of high value either, for the simple fact that very few people in your organization will take the time to read these. Advertisers have it right; the simple and the visual always trumps the complex and the written.
Your next valuable UX hire will show in the interview some combination of static images produced on Illustrator/Photoshop, strung together into clickable prototypes using HTML or one of the popular prototyping apps like InVision (and there are many others). She could also show a variety of deliverables using ScreenFlow, After Effects, Vimeo, PowerPoint or Keynote.
She’ll also demonstrate a keen understanding of the user and what problems need to be solved. Understanding and empathizing with the user, however, is not enough. To provide true value to an organization, a UX designer needs to take that user empathy and show the solution visually to managers, developers and product management.
If you focus on candidates who produce these kinds of deliverables, then you’ll have a higher chance of adding value to your company by hiring a ‘true’ UX designer. Look for deliverables that mimic the way users actually interact in the world of screens (of all sizes). Suddenly, you don't need to rely on titles, degrees, prior experience or a candidate's bold pronouncements. You can look at his work and know what kind of deliverables makes someone a valuable UX designer.
Make better infographics
Let's face it; we're living in an age of total data overwhelm. We need to be able to quickly understand what's going on in a set of data. We need the story, or at least powerful tools to help us get the data that helps us visualize trends, movements and comparisons. So how do we do this better?
It's about story, not information
Having graphics and charts with no rhyme or reason is a terrible user experience - here's a typically awful example (click view demo). In this example, I'm unsure about what I am looking at. I have zero context, zero reason for consuming these charts, and thus no reason to engage or interact. Stories give us context. Stories are memorable. Stories help us better understand the complex world around us. They tie together the loose and chaotic threads of the world's events. If we're using charts and graphs, we're visual communicators. But what are we saying? Is it visual clutter, mere gibberish - or are we delivering something understandable, consumable, relatable? Big data may be the band wagon that everyone is on, but the bedrock of visual communication remains actually having something interesting to say or show. And that will be the true differentiator between products in the marketplace.
To that end, here's one of my favorite data visualizations in the last few weeks - the depth of the ocean vs. trying to find the sunken Malaysian Airlines, via the Washington Post. I love that it uses the long scroll, a semi-unpleasant user experience, to illustrate the depth of the ocean in the area of the downed aircraft - and thus the difficulty of the search. Absolutely brilliant.
Good infographics are based on clean, reliable data
This is less obvious, I know. Less obvious to the person making the chart, graph or infographic. And less obvious to the audience, who implicitly trusts what's being presented. (Aside: If you want to really get people to trust you, have a picture of an MRI or brain scan - doesn't matter what or why - just the presence of that image makes reader trust skyrocket)
Here's the truth - when you build a building, you better build a damn good foundation. Similarly, if you are presenting a chart or graphic, you take responsibility for the numbers behind it. People probably won't notice immediately, but if they get into an argument and use your data, and they get called out, you better believe that experience will stick with them. The shame of being wrong will override any sense of wow or interest that they had in the story. And the shattered trust won't (and shouldn't be) easily repaired. By presenting information in a visual way, you are relying on the audience's good will and trust. Don't disappoint them.
Good infographics are attractive and easy to read
This is a basic rule of good design, but I see it violated all over the place, even on infographics that are featured on 'best infographic' sites. Eliminate clutter, and make it easy for me to make my own conclusions about the data - remember, it's about story, NOT about information.
Enterprise dashboards
I've written before about dashboard and how they're typically awful even when the design seems nice and modern. The problem is known as 'the portal problem' and it's been well documented - see this article on boxes and arrows.
Here's an example of a dashboard that looks great, but that may or may not function well. Since it's a template for generic business X, my guess would be that this will not function well when it's implemented.
The problem is that dashboards are typically built for a general user that ends up serving 10-20% of everyone's needs, and no one's needs fully. Dashboards are typically built as if all users had the same needs when the reality is much, much different. Even users with similar needs end up wanting to view it and consume the information in a way that suits their particular style - and why shouldn't they? The promise of technology isn't that it's a one-size fits-all solution that will frustrate 80% of the needs of users - it's that it's malleable and useful for the user - who happens to be a human. Humans process information in all sorts of different ways, and dashboards have to account for this if they're going to be more than an update of the skeuomorphism of the vehicle-dashboard metaphor that was popular in the 90s and 2000s. The problem of course is that they rarely do and so in my opinion end up failing in most cases to deliver an optimal experience - or even a minimally useful experience.
I found an incredible article proposing a better way to design a dashboard. Unfortunately it's long and filled with in-jargon that makes it difficult to understand (I had to read it twice to figure out what was being said, never a good sign).
To that end I'll be linking to the article(s) and attempting to reduce 6 overly-long articles in one concise statement about building a better dashboard.
Make the views user-configurable
This has two aspects - first, allow the users to hide or show larger blocks of content. Do they want to see a KPI or don't they? Second, allow them to configure existing blocks of information. If they want to see the KPI, then over what time period do they want to see it? What kind of chart would they like to view it as? Etc. We all process information differently and we shouldn't assume that one view of data will work for everyone. Let the user customize and save their settings.
Let it be emailed, printed, etc
Sharing capabilities extends the usefulness of metrics. If we're saying that a view of data is important enough to see everytime you log in (as in a dashboard view) then why not be able to save, email, and share that metric easily? Not everyone knows how to take a screenshot (seriously) so make it easy on people - a share functionality could also include attaching an excel spreadsheet with the information contained in the chart, graph etc.
Give the user context around the info being presented
How do users know if the numbers being shown are real and relevant? They might trust the numbers, but they might need to know more in order to make a decision. So give them the tools to investigate the data and let them deep-dive to help them feel confidence in what they're being shown.
Let the user's input be a signal about usefulness (and pivot based on that information)
Let users make notes on information. This could be one signal about it's usefulness, and may or may not be useful to other users. Build in logic to recognize the frequency of an information block being consistently hidden or shown - this will be a signal about the usefulness of a given block. Basically treat the user as the end-all of product usefulness. If they aren't using something often, then re-consider the value your organization is putting on maintaining that chart, graph or block of information.
How users consume data should inform the role/look/content of the dashboard
Typically dashboards are build on data that users want access to. There's two ways to get at this kind of information - in the mockups phase, you can do card categorization tests with potential users and customers, to help you find out what kinds of data they feel is useful. Once the product is built, you can actually track their consumption of the data and verify that what they want (where they end up in the system) is actually what you're delivering them in the dashboard.
Relationship visualizations
Given how opaque and overwhelming data can be, it's incredibly important to distill all those numbers into a coherent, emotional story - particularly when presenting those numbers in a visual format. In the case of visualizing relationships, not only is it important to show the connections between groups, but also show different ways individuals can connect, the strength of those connections, and different ways of organizing various groups.
Visualizing connections between people
In researching data visualizations within social networks, I've found a standard way for displaying these relationships - circular or profile picture-based nodes, connecting lines representing relationships and all nodes more or less being the same size. This works well when the only data point is people and connections, but it seems to wither when we're looking at other metrics - people connected by locations, phone numbers etc. Here's the common way to visualize relationships within a network (from Vizster, a product whose name sounds like a parody of itself):
This 2-D graph is prevalent in the data visualization world and I'm going to assume that the constellation visual is the best way to represent this kind of information. But I'm wondering if there's not a better way of breaking down the data to have it display intra-networks - networks within networks.
Anyone who's looking to analyze a network isn't looking to view the whole network at a 1,000-mile view - they're going to want specific, actionable information about sub-groups within networks. For instance, what are sub-groups within this network that are most closely aligned? Who are the connectors between large numbers of individuals? Who holds the power in this network?
Think of these as a visual way of doing the classic 'filter' functionality.
In this example, I'm still able to keep the original data set in mind, but I'm also able to view a filtered set of information. This kind of information helps users make decisions and conclusions based on a limited data set.
In the following examples, each graph node is always of the same type - we're always comparing one thing. But what if we want to view nodes of different types on a 2-D surface?
Comparing different types of connections
Instead of viewing the connections between people only, what if I wanted to see how people were connected via a physical location (like a school)? A graph like this might consist of users, phone numbers, email addresses, physical locations, usernames, shared spaces (such as a school or work place) etc. Graphs of these types allow the user to view more information, but using the standard 'constellation view' risks equating nodes that are not actually equal, or delivering a messy UI. As an example of this:
Even though the nodes are all differentiated by color, it's difficult to understand what's going on. With no distinction being made by color saturation, size etc., it's tough to make any kind of quick judgments about what I'm seeing. A better view might be sizing the nodes differently, giving relative weight to human actors in this relationship graph.
Above, it's difficult at first glance to determine what nodes are shared between users (since the nodes all have equal color saturation and the sizing difference doesn't seem to matter much - people have a notoriously hard time distinguishing the relative sizes of circles).
Here, it's much easier to see the human actors at the middle of this connection (and this could be done for any kind of node on the graph).
Above I've made the connection point the largest. This kind of sizing, color and saturation treatment could be done for many different aspects of a social connection graph. Using just a few visual treatments we're able to tell a myriad of stories about the ways people connect, where they're connected, etc. With applications for work, social networking, law enforcement and espionage, you can bet that not only will this kind of data visualization become sought after, but it will become an important tool in understanding and shaping the world we live in.
Bring UX interactions to life with video mockups
Don't let stakeholders bumble through the mockup of your cool new feature. Control the narrative of your UX designs by switching your deliverables to videos (yes, videos).
Any mockup is basically a quick way to tell a narrative about a feature, a flow, or an experience. We can use static images, and they're inadequate; they lack context unless we're with the person while they're looking at them (rare). In a pinch they work, for quick projects they're fine, but for a flow or story...? Not so much.
Click-through mockups are inadequate
Click-through mockups have always been associated with UX, but they're a strange deliverable. It's an image, with one tiny part that's clickable. Which is completely unlike the product you are trying to build for, and pretty far removed from the experience of any end user. The designer can't control the way the user (in this case a Product Manager or Developer) moves through the mockups (maybe they can't find a link, or think the flow is finished).
Give the gift of a short (2-3) minute video
Videos are extremely effective at telling a story to a wide-range of viewers. Many people looking at images won't have the full context. And since user experience is all about context, it's critical to making judgements about how a story is told. With a narrated video, the designer can give the viewer a detailed context; act a a guide; point out features; and most importantly, control the narrative.
Why the narrative matters
The narrative is all you have. As a UX designer. As a designer selling a vision or feature for a product. The narrative is the emotional core of what you're proposing. The emotional experience being one of ease and improvement. Life is better with this new feature. And if your Product Manager can't find the $^#% link then guess what happens to your tidy story of ease and betterment? Guess what happens to that cool new feature you dreamed up on Sunday at the park, and all that work that you did after work because you believed in what you were doing - that right, it goes nowhere, like your career if you don't start upping your game and following my sounds and reasonable advice to make videos as deliverables.
Example
Here's a video I made to help sell a new feature I dreamed up, designed and implemented in CSS media queries
PM-Dashboard-Newsfeed from Jonathan Simmons on Vimeo.
Designers who code
I wanted to examine the origins of my knowledge, how it's served me, and whether designers should learn to code.
Since there's no degree or independent way to verify my skills, I'll let you judge for yourself - here's a portfolio I set up on Behance for visual design and I generally point people to my Vimeo account to explain my UX and coding work. I consider visual design to be my main proficiency, with a strong secondary ability in code, namely javascript and Jquery. Read more
Turn off the computer (!) and sketch early in the product design process
Sketching with pencil and paper in the early stages of product design connects us to a familiar, tactile process that unlocks our creativity and gives us a better understanding of the problem we're trying to solve.
Drawing is simple, simple, simple. And while computers allow us to go further, they color and constrain our thinking in ways that are detrimental to the early phases of product design.
Most of us have been using pencil and paper in some form since we were old enough to speak - the sensation of touching paper, of feeling the weight of a pencil, the smell of the eraser - let's not discount these familiar, reassuring signals to our brain simply because we can't quantify them. We're deeply trained and infinitely comfortable in this mode. This kind of safety and comfort is like gasoline for the creative fire. If you don't believe that safety and comfort make for better performance, notice the difference next time you tell a story to your closest friend, and how it feels to tell that same story in a group. Unless you are a great public speaker or well-versed, your performance suffers. Safety reinforces creativity.Read more
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