#UX101: Letting go and finishing

As important as iteration is when it comes to UX design, it’s also important to know when to stop. Too many times I have worked with designers who didn’t want to finish, who tweaked and changed and refined so much that (sometimes) the work had to be pulled away from them to be completed.

This is not the way to do it, for many reasons. First off, it makes you look indecisive and insecure… which does the whole UX discipline no favors, either. Second, it takes time away from the developers who have to execute your design, which is unfair to them.

Finally, any delay caused by excessive iteration endangers the project and could prevent ANY solution from reaching end users. The whole point of user experience design is to create solutions for people… to make their lives better. If nothing is ever “shipped”, then no one will get any benefit from what you have designed.

(This final point is especially important to me. I have worked on many projects in my time, and sometimes the project was halted before it was completed due to business decisions or budgetary reasons. Yes, the designs look good in my portfolio, but I’d rather the work benefit other people than just sit there unused.)

There’s a lot of reasons that some designers are like this… here’s some of them.

“Mr. Blue Sky”

Some of this excess iteration is driven by excessive optimism, where the designer is incredibly aspirational and wants to “change the world.” While I’m an incredibly optimistic person, I also have some perspective. The world is a very big place, and I’ve been involved in some design projects that did, indeed, make a big impact in the lives of a lot of people… but those are few and far between. We need to be realistic and temper our aspirations.

Designing for the next big thing

Lots of UX designers are, like me, fans of technology. Some of them are such fans that their designs aren’t feasible… yet. They design applications that would only work with “future tech” – advances that are being worked on in the lap, but are still months or years away from being released in the marketplace. This is not necessarily a bad thing, because we all need to dream big sometimes… but it’s not very practical if you are on a deadline-driven project. Doing this too often could also result in a reputation as having a “head in the clouds” and may impact opportunities and your career.

“Great artists ship”

This quote from Steve Jobs is one of my favorites, because it combines art and commerce in the most simple elegant way. User experience designers need to heed those worlds, and focus on results and outcomes rather than process. While I spent a lot of time in UX101 talking about process, I also tried to emphasize outcomes and deliverables as well. You have to finish, so that your visions and designs can become reality. Endless iteration means that you will never produce a final product, and that benefits no one.

“Perfect is the enemy of good”

This is another favorite quote of mine, an aphorism attributed to Voltaire. I have seen designers who iterate too much because they want everything to be perfect. Well, perfection will never be achieved, no matter how many times you tweak the details. Starting is hard… but for people with this attitude, finishing is even harder.

 

Conclusion

I’m sure if I spent more time writing I’d come up with lots more words to detail out the user experience domain… content that would (hopefully) explain more advanced techniques and information. But that would be #UX201, wouldn’t it? The point of this work is to provide foundational understanding and advice about UX to people who are new or interested in the domain. I think I’ve done that, and so I’m following my own advice: I’m letting go, and finishing.

(In fact, you can replace the words “user experience design” in the above section with “writing”, “painting”, “filmmaking” or any other creative endeavor, and most of the thoughts would still be appropriate and apt.)

This work was a labor of love – I don’t expect to get rich off of it, and in fact will be giving it away as much as selling it. The reason I did it, my “mission statement,” was to educate and inform, to hopefully get more people into the UX discipline… More practitioners mean more ideas, and more ideas means better ideas. Ideas that can raise the bar, making the quality level of the software and hardware we use better… resulting better experiences for all.

Will this happen? As noted above, I’m a practical man and I know my place in a (very big) world. Any impact will be minimal… but if this work helps even one person get into UX, or get better at their craft, then it will have been worth it.

If you have read this far, thanks! It’s up to you, now. Take these ideas, use them, and hone your skills. Design that cool UI or application that will make people’s lives better.

In the words of one of my favorite starship captains: Make it so.

#UX101: Bringing UX to your organization

You’re passionate about UX, you’ve “drank the Kool-aid” and you know how much value user experience design can bring to your company. Now what? How do you promote UX to decision makers and stakeholders? here’s some thoughts and advice as to how to work within your organization to get UX more attraction and interest.

Know your organization’s “UX Maturity”

Johnny Holland published a great “UX Maturity” chart, that measures the levels of understanding and application of UX in an organization. It goes from Level 1 (“Unrecognized”) to Level 6 (”Embedded”). Knowing where your company is in this continuum will help you know the level of discourse and education you need to have, so you can speak to the value of UX at the proper level to the right people.

Nothing succeeds like success

The easiest way to get attention to UX is to be successful applying UX to a project. After you succeed, you then have a story to tell people and this case study can help increase interest in applying more UX principles. If you are not in a position to apply UX to a paying project, do it on an internal effort – solve some process problems or improve deliverables. Even if you can’t make a big impact, the key is to build your case and have a story to tell – as noted earlier, we are hard-wired to respond to stories and this makes things easier.

Don’t try and do it all 

Take baby steps, and use only one or two UX techniques to solve problems. This way you can be more focused and won’t be “swinging for the fences” on your first at bat. Build your skills, and successes,one step at a time.

Understand how things are being done now

Spend some time learning current processes to get a good sense of potential “insertion points” where UX can add value or save time. This will show management you know what you are talking about, and therefore increase your credibility when you propose changes.

Get an executive “cheerleader”

If you have the buy-in of an executive, that is worth its weight in gold. Executive support can get you funding, break down barriers, and help you in many many ways. I have seen just how important such support is first-hand… when I had it, and when I didn’t. Reach out to an executive to make your case and get that support if you can.

Apply UX in the early stages of a project

If you are working on projects, bring UX practices into the early part of projects instead of later. When you are in a project’s early days, the tolerance for failure is higher and deadlines are (usually) not as aggressive… so if the UX practice you apply doesn’t work, there is less chance the application of same will blow up in your face and give UX a bad reputation to management.

Don’t be discouraged 

Organizations large and small are established in their ways, and many organizations are reluctant to change. When you try and “rock the boat” and do things differently, you will see first-hand that hesitancy. Sometimes you will think you are banging your head against a brick wall… don’t let it get to you. Keep trying to make UX a priority at your company, and be positive as much as you can.

#UX101: Producing Design Documentation

How much design documentation do you need to produce? Do you make pixel-perfect wireframes that detail every single interaction and behavior? Or do you create mid-level documentation and leave the details to the development team? The answer, of course… depends.

I know many designers who feel they HAVE to flesh out every single aspect of the experience, and so they spend hours and hours making sure everything is spelled out and documented. They produce hundreds of pages of design specifications, which are then handed over to the development team to execute from (and the QA team to test with). This reflects the classic “don’t make them think” attitude that some UX professionals have towards developers – and, to be fair, many developers have the same attitude. This extreme level of specificity, though… I think its overkill. It ends up increasing the design lifecycle as well as increasing development and QA time.

On the opposite end of the spectrum, I know some designers who do a cursory job of design documentation and do only the bare minimum. It’s not that they are lazy, they just don’t like doing design documentation (full disclosure: I’m not a fan of design documentation, either). When this design documentation is delivered, developers often have many questions about use cases or exception handling that is not detailed out. Just like documentation overkill has issues, “underkill” like this produces lots of problems.

To me, the best design documentation is like the best design: It aligns to the needs of the users and solves problems for them. For developers and QA team members, this means getting to know them, understanding their process, and aligning with what they need. This means having a certain degree of flexibility about how you do things (and there may be some negotiation). Basically, document the design as much as you need to in order support your team and ensure the vision of the design is properly executed.

Additionally, there are some design documentation “best practices” I have identified over the years, and hopefully these will help you in your work:

Document standards instead of create documentation

I’m big into efficiency, and one approach that helps you be productive is to define design standards that should be followed throughout what is being designed. These overarching rules can be used to answer any questions and resolve any ambiguity. Try and make these standards specific enough that they aren’t platitudes, and are practical and actionable. Look up examples from Google, Microsoft, Amazon, and more to help come up with your standards.

Build (or leverage) a pattern library

Once of the great principles of development is the goal of “write once, use everywhere.” This means coding or leveraging standard libraries that save time and effort. You can do the same thing with design documentation by leveraging existing pattern libraries and/or creating your own. This way, you will be documenting a UI element once… instead of every time it appears on a screen.

Produce design documentation that is used and useful

Don’t create design documentation that you think is what is needed, based on what you have done before… Make documentation that aligns with what the team will actually use. Don’t spend hours building out a complicated sitemap that will look really nice framed on the wall that no one will ever apply. Make documentation that matters, and apply user-centered design techniques to ensure that what you produce is usable for the recipients.

Don’t replace communication with documentation

Don’t throw design documentation “over the wall” and hope that documentation will be enough – walk through the design with the team and explain how it is supposed to work. If you are in an Agile team, this is a constant process and it results in a better design. If you are doing “waterfall”, you will have to set aside the time to do these walkthroughs… Do it as soon as you can, to understand both the level of documentation needed as well as to get feedback on the design that can you can apply to make the work better.

Focus on design, not on documentation 

While you should always put aside and plan for sufficient time to document what you have designed, understand that your focus and most of your time should be sped designing solutions and focusing on user needs. Spending all your time documenting instead of designing will result in a false sense of accomplishment – you may have a big pile of documents at the end of the day, but if the design spelled out in those documents don’t help people accomplish their tasks and do things faster and better… well, it’s a hollow victory.

#UX101: Best practices for gesture interaction

Gestural interaction has been around for a while now. Inspired by movies such as Minority Report, engineers and designers have made the ideas seen in that film a reality for millions of users. From the simplest “shake to play another random track” to complicated game-based gestures, the way we engage with technology has advanced greatly from the traditional keyboard and mouse. The release of the Leap Motion controller in July 2013 has brought incredibly advanced and sensitive motion control tech into homes for less than $90, and the Xbox One game system promises an additional “leap” in the commercial application of this new way of doing things.

As this “new way of doing” looks to not be going away anytime soon, here’s some “best practices” on how to do gestural design for your application.

Decide how and when gesture control should be used… and choose wisely

One of my favorite pieces of movie dialogue is from Jurassic Park, when Malcolm (played by Jeff Goldblum) questions the whole premise of the theme park:  “You realized you could do it, you never thought if you should.” Applying gestural control is a great example of technology that could be applied… but should it? Don’t just decide to do gesture control because you can, apply and use it in thoughtful ways… Make it align with what you have designed and don’t make it a “bolt-on.”

Keep gestures simple

I’ve seen some examples of gesture control that, well… are too cute and complicated to work. People don’t want to look foolish, even if/when they are alone. Don’t have users doing the “chicken dance” from Arrested Development in order to accomplish a simple task. Be thoughtful and keep things simple and straightforward.

Gestures have to make sense

Don’t do a gesture that doesn’t align with how people do things in real life. An example: If you are paging through “cards” in a UI, use a swipe to the right to dismiss the top card on the stack. This is like dealing playing cards, and this gesture will align perfectly with how people do things in the real world. If you do the opposite (swiping to the left), it will be unnatural to people and will reduce the “learnability” of the app using such a gesture. Remember: The more natural and obvious the gesture, the easier the application that has these gestures is to use.

Use common gestural “affordances”

Pull, push, swipe, twist: we all use our hands every day to do things with gestures like these. This follows through on the point made above: Leverage how people do things to make the gestures make sense to users. Watch how people use their hands and then reflect that understanding in the gestures you apply in your designs. Don’t try and be “creative” when you have the right answer staring you in the face: Align with what people already do, and you will be successful.

People are lazy

I spoke about future UI concepts and gestural computing at a conference several months ago, and as part of that speech I asked everyone to raise their arm above their head and keep it raised until I said so. Within one minute many of the people in the audience were getting fatigues, and for good reason: Most of us are not fit enough to maintain a gesture for more than a few seconds.

In fact, when Tom Cruise was filming his gestural sequences for Minority Report, he was dripping with sweat within an hour of shooting the scenes… and he’s in a lot better shape than most people (like me). Good gestural computing design aligns with the ergonomics and limits of its users, and understands that people usually need “restful” moments where they are not gesticulating. I labeled this section “people are lazy” but that’s not really true – they are human. Understand and align to their human limitations.

 

#UX101: Tools of the Trade

There are quite a few tools that you can use to create designs and then test said designs with users, and in my many many years as a UX professional I’ve tried out most of them. First, let’s cover design and prototyping tools:

Adobe Creative Suite

My “go-to” design tool, the Adobe Creative Suite is a “must-have” tool for design professionals for a reason – it lets you do everything, from print and web design to interactive and sound editing. If it only had Photoshop, Illustrator and InDesign… it would be indispensible. It’s a lot more than that. Depending on what “set” you buy, it’s either expensive or VERY expensive, but it’s worth it.

(Adobe has recently gone to a “subscription” model – which I don’t like. I recommend buying the packaged software, which should still be available through services like Amazon, etc.)

Axure RP

Axure is one of my personal favorite design tools, because it allows you to do many things at once: You can create and document the UI design and also add interactive elements to make a functional prototype (which is rendered in HTML). It’s available for both the Mac and the PC, and is fairly easy to use and learn. It’s not cheap, but for what you get from the tool it’s worth it.

Omnigraffle

A mac-only design tool, Omnigraffle allows you to design user flows and journey maps as well as user interfaces. The ability to add interactivity is limited, and only when you export the design to a PDF. It, too, is pricey but incredibly versatile.

PowerPoint and Keynote

Yes, you can create interactive prototypes in presentation programs such as PowerPoint and Keynote. It won’t be as engaging or as interactive as some of the prototypes you can create in Axure but if you are designing a simple kiosk-like UI then these tools can definitely help you build out something to test with.

Irise

An extensive suite of functionality in iRise allows you to make a very interactive prototype. That deep feature set comes with a price, however: A steep learning curve and a high price. I’ve worked a little bit with the tool, and it’s not a bad product… it’s just too pricey for me.

Expression Blend

Now a part of Visual Studio 2012, Expression Blend is a great tool for mocking up screens if you are designing Windows Apps. It also allows you to work with versioning and developers to execute that design. It’s got a learning curve, but if you have experience developing it may be the right solution for you.

Balsamiq Mockups

Balsamiq Mockups has got a lot of fans in the UX community, and rightly so: it’s a simple easy to use design tool that allows you to quickly mockup wireframes and, because the default design looks like a sketch, stakeholders don’t get fixated with visual design elements. It’s also inexpensive and well worth trying out.

Usability Testing Software and Services

Morae

My favorite tool for usability testing, Morae allows you to capture the desktop of the computer and an additional video source (either the built-in webcam or an external camera) and the tool will transmit the video and audio of the test session in almost-real-time to another computer on the local area network. The software allows for remote note taking and “tagging”, so that you can have a log of perceived usability issues to analyze later (with some great built-in analysis tools). It’s a great suite from TechSmith, and a great alternative to an expensive usability lab.

Silverback

This is the OS X equivalent of Morae, sans most of its features. It allows you to record the webcam and desktop from a computer and that’s about it. Please note it is also MUCH cheaper than Morae, so you get the core functionality both share at a lower price.

Usabilla

Usabilla is an on-line “remote” usability testing tool that allows you to have three active tests at a time. The $89 a month fee does not include participant recruiting and incentives, so you’ll need to pay those additional costs. It’s a fairly simple service, but it may align with your needs better than…

UserTesting.com

UserTesting.com costs $39 per participant, and that cost includes recruiting AND compensation, so it’s a flat rate for everything. The drawbacks are you will have to host the design you are testing on your own server and they only offer limited screening capability. Once the participant tests your designs, you will have access to the video of their feedback to review afterwards. It’s the best solution for the “budget-minded” design team.

Loop11

If cost is no object, then Loop11 is the best remote testing solution for you. It costs $350 per project, or $9,900 for an unlimited license. It offers much more interactive and richer user testing, and allows you to host your designs on their servers. Be aware that, like Usabilla, you will have to pay for your own recruiting and participant compensation.

Ethnio

Ethnio is an online recruiting tool that pays participants Amazon Gift Cards. The service costs $49 a month and allows you to post a link to screening questionnaire from Twitter or other social media sites. You can recruit up to 250 participants a month for the one flat rate. The best thing about the service is you can integrate with Usabilla, Optimal or UserTesting.com to redirect participants directly to the tests you are housing through those services. It’s a great alternative to paying an outside agency for participant recruiting.

 

There you have it, some of the many design tools available for you as a user experience professional. As I have said before, there is no “right” tool… use the tools that work for you and best aligns with your needs. And no tool will make you a better designer – only talent, practice, and time will do that.

#UX101: How to analyze user research data (and produce results)

Once you have gathered your user data, through either user interviews or usability testing, you need to analyze it. While some may consider this a daunting task, it’s not: it is, however, an activity that requires focus and objectivity. In order to make sure that you are not unconsciously letting your preconceived notions taint your analysis and final findings, do the analysis activity with at least one other person – preferably two or three. This way everyone can “check” each other’s interpretation of the data and mitigate the chance that the results will contain fallacies or mistakes.

The most important thing about analysis is this: Don’t reach any conclusions before you start analysis! When you do you will (unconsciously) try to make the data fit your premise and you will (unintentionally) distort the data to fit that preconceived notion. Always remember: the data doesn’t care if you’re right or wrong, its just data. I have repeatedly been pleasantly surprised and delighted in research analysis sessions when the data revealed insights and understanding that were totally unexpected and cool – and we would never have identified those insights if we had come to the data with “blinders” on.

The second thing to be mindful of is “pattern recognition.” We are wired to make connections… sometimes when no connections exist. Analysis involves interpreting data to form insights and findings, and a lot of that involves identifying patterns and trends in the data… but don’t make false connections that aren’t there just because you want to find such things. Again, having more than one person helps to mitigate any such “incorrect” pattern recognition.

Analysis methods

When you are looking at data from user research or testing, there are multiple techniques you can use to analyze the data. No matter what technique you use, there will always be common activities you will always have to do. You will always need to review the notes and audio/video of the session to get a sense of the person and their responses. Spends some time identifying any pain-points or frustrations that were captured and the root cause of the frustration – was it the software or process being used or was it an underlying issue the person has outside of that? Finally, when you are looking at usability test data, be fair and objective – you need to identify what worked and what didn’t in order to produce accurate findings.

Use one or more of the following data analysis, and be aware there are pros and cons to all of them:

Affinity diagrams (aka Card Sorting)

Card sorting allows you to write down individual data points on sticky notes and then put them on the wall. This allows you to start looking at the data in isolation, without any preconceived notions. This is a good way to identify patterns and works especially well when you are building an information architecture or creating personas based on attributes of interview subjects.

Another benefit of this technique is that you can bring in other people to look at the data and let them organize it for and with you. This is called an open card sort, when participants are asked to sort cards with no pre-established groupings. The groups they create reflect how they think of the data and after they are done they are asked to group the cards and describe the groups they created.  (A closed card sort is when participants are asked to sort cards into groups provided to them).

Data-crunching

This is using tools like Excel to look at the data to identify patterns. When doing usability testing, I like to use a standard spreadsheet template that has columns that list the task being tested, an area for notes, a drop-list that allows the notetaker to classify the note as they are typing (“usability issue”, “participant question”, etc.) and a “flag” for whether or the person was successful in the task. This allows me to reconcile all the notes from the sessions to quickly analyze what worked, what didn’t, and what issues the participant encountered.

When you are looking at notes from user interviews, you will have to spend some time “retyping” the handwritten notes into excel, so this approach has some extra effort baked in. However, this lets you have a permanent electronic effort of all the interview notes, so this is a benefit over card sorting. Another benefit is you can produce nice charts and graphs from the data and many stakeholders like that kind of thing…

Mind Mapping 

Doing a mind-map allows you to create a visual map of the information that you gathered through your research, and this “picture” allows you and your analysis team an opportunity to look at things differently. You can use a software-tool or, if you are artistically inclined, you can create a mind-map on a whiteboard or on large sheets of paper. Visualizing the information helps identify patterns and informs insights that may not be understood otherwise (remember: many people are visual learners, and this exercise works extremely well for those type of people).

Dimensions

“Dimensions” is a good tool for identifying patterns to inform personas. You look at the data you have gathered from all the user interviews and you define key characteristics that came out of these conversations. Some examples are “Tech savviness”, “Confidence”, “Extrovert/Introvert” and “Charitable giving”. You then identify the two ends of the dimension and you place all the interview subjects on the line where they fall. This allows you to see where there are similarities and where there are differences, and this informs the creation of more accurate representative personas. Other than persona creation, however, it has limited application for other design or research activities.

Forming results and making recommendations 

After you spend the proper amount of due diligence analyzing the data and forming results (you’ll know you’re done when your fingers are numb and your eyes feel like they are bleeding) you will need to package your results and define your recommendations. In the past I’ve written detailed and lengthy word documents as well as large PowerPoint presentations… and I’ve found PowerPoint (or Keynote if you use OS X) works best.

Business stakeholders like to see presentations and many of them have looked at my lengthy word documents with a reaction bordering on contempt. “I have no time to read that,” they say, “give me a 10-page summary.” Do not take offense at such a reaction – most senior folks like this are like Jack Webb on Dragnet: They want “just the facts.”

You may be working on a project with an aggressive timelines, and may be tempted to just send the results in a quick e-mail to the key players and the rest of the team. Don’t do it. Spend the time pulling together a formal, professional document, because if you don’t odds are a stakeholder at some point will question the budget line item for user experience research or testing and ask, “Why are we doing this? What are we getting out of this spend?” Having results documented from all your testing will allow you to best respond to this type of question. It will also add to your portfolio, and so it’s worth doing and doing well.