Several Nerds will enjoy what’s become a traditional Memorial Day weekend at Soundset this Sunday, but for the first time there’s an app for that fine festival – and that’s because we built it for our friends at Rhymesayers. Read more
The UX Files
Maybe you have had a similar dream that goes something like this… You have a very important meeting ahead of you. You are about to meet a brand new client and you’ve practiced your pitch to a tee. Your mind has been racing for hours if not days and your meeting objectives have been looping in your head. Naturally you want to do great and you want the meeting to be a success. A lot is at stake and you don’t want to mess up. Instead it turns out more like this…
You walk into the room of executives, you shake hands with them but none of them make eye contact with you and some even ignore you. Some don’t even notice you at all and others stare at you uncomfortably. You look for your teammates for help and assurance but they don’t notice you at all either. Next, the meeting starts and it’s your turn to speak. You move your mouth but no words come out. You become more and more uncomfortable, you start to sweat and even panic. You’ve missed your chance to speak and the meeting moves on. You didn’t get to contribute and even worse you fear that you’ve made an awful impression on the client and your peers. You did. You wake up panicked and infuriated. Thankfully it was just a dream.
Only this is not a dream but a reality of what a typical remote meeting can be like for you. You walk in into the meeting with a focus on the agenda only to find that you get taken off course by technical and engagement difficulties. Common occurrences like video disruptions, microphone echoes, and phone static all come in the way of effective and natural conversation. This can make remote participants feel invisible and awkward at best. It’s easy to feel disconnected and left out without the physical presence of the room and the people in it.
Unfortunately that is the reality more often than not. If your job is for the most part not task-execution focused in nature you will have to make up for the lack of rich human interaction that happens naturally between people who share a physical location. Digital tools such as video conferencing, IMs and constant emailing filter the rich human qualities that are critical in fields like UX, where the success and quality of a project is driven on collaboration and frequent brainstorming.
Know the Limitations of Digital Communication Tools
Armed with talented WFH (work from home) staff and distributed offices we – at The Nerdery – work remotely a lot and here are a few takeaways from our experiences. We give technologies (eg. Google hangout, Skype, jabber) too much credit. In theory you would expect to hop on Google Hangout or Skype and to have a near flawless, normal human interaction. That is an ideal user expectation which at this point in time – from our experience – is still a theory. We like to believe that currently-used remote communication methods are as reliable as we expect them to be, but be prepared to deal with common issues. Video interruptions, audio cutting out, microphone feedback and echoing, and loss of visual are all the little things that will ultimately throw you off and limit your effectiveness.
An unavoidable side effect of remote meetings (formal and informal) is miscommunication, which ranges anywhere from mishearing or not hearing at all what is said, to not seeing people in the room causing inability to pick up nonverbal body language. Some people are very verbal whereas others understand the world more by observing and perceiving their environment. For those people, collaborating and running meetings remotely is excruciatingly painful as the essence of the environment is filtered through the digital tool. It becomes essential to have a game plan when working remotely.
Implement a Strategy to Increase Efficiency and Effectiveness
Anticipating issues and implementing strategies is winning half the battle when it comes to remote communication. The first rule is to set expectations early on with both your team and/or the client. If there is not an established standard at your company when it comes to remote interactions, create your own set of expectations based on what has worked for you and share it with your team. The list should include essentials of what you need to be effective in order for the project to be a success. This can include meeting five minutes before a meeting to ensure all tech is working properly and to go over the agenda.
Another example would be to call in after a client meeting to debrief as a lot of conversations happen “offline” and if you are working remotely it is critical that you create opportunities to be part of informal post meetings. What works is to schedule an internal, post-meeting 5-10 minute debrief. There is still no effective way to make up for the spontaneous conversations that happen naturally, so to ensure that you are not disconnected from what is going on, ask the project manager or lead for recaps or status updates that are made available first thing in the AM and or PM. Depending on the project those may happen once daily or a few times per week but it is essential that they do.
Remote clients, distributed teams, and remote offices are here to stay. Communicating remotely at this point in time is not perfect but it is essential and should be embraced.
Hopefully in the near future technology will advance enough to allow remote participants to have a more rich remote presence that will not strip us of our human essence. In the meantime it is essential for any company to have standards in place and an etiquette that strives to have better remote communication best practices. It is imperative to have a set of ground rules to work from that will make up for the lack of rich communication between distributed (non-collocated, remote) teams.
Stay tuned for a series of follow up posts where practical remote communication techniques and tools will be presented in more detail.
The beginning of The Nerdery’s UX process can feel strange and unfamiliar to clients who have previously engaged in projects with similar vendors. Why? Because we ask a lot of questions. Questions that dig into the roots of the company; operations, reasons behind decisions, internal systems and tools, long-term goals. Although, these topics may seem unrelated to the project at hand, they are the foundation and initial step in applying our holistic approach to a design project. Afterall, design is about everything. The Nerdery UX department has validated over time that its success is based on understanding its partners’ business (and their users). It is essential to develop this understanding because project success is reliant on taking into account the whole of the business.
When solving a UX problem holistically, the designer is looking for the sweet spot of success. In simple terms, the sweet spot is the solution in which business goals and user needs overlap. At a high level, failure to find the sweet spot exists in two main forms, genius design and admin affliction.
The risk in immediately jumping into a project without finding the sweet spot is that the solution only focuses on business goals and does not consider the end-user in the design process. This disconnect in the process is what we typically refer to as genius-design. Genius design is when a designer or engineer focuses on the business and existing design patterns, but users are not incorporated into the design process. A lack of user research and understanding quickly causes a project to be in high risk of missing user needs altogether, creating a product with no users and therefore no revenue. Note: Genius design is a well covered topic by previous Nerdery UX blog posts. For more information about the risks of ignoring your users, please refer to The Science of UX.
Projects are at risk of failure from the internal side even if user needs are well defined. A project that does not properly define a set of focused business goals and outline how the design will affect business operations is something I like to call “admin affliction.” Outcomes that result in admin affliction have negative effects on the company and can take a variety of forms, but ultimately end in project failure. It is more than knowing about goals, it is about having a holistic view of the company to take all its aspects into account.
All stakeholders should be aware of the potential risks in overlooking the important questions that arise during the discovery process. To mitigate admin affliction, our UX team believes strongly in engaging project stakeholders to define the company, its needs, and operations. For the remainder of this article, we will be focusing on a few of the risks and forms of admin affliction that can arise from the lack of communication and clarity between any design vendor and their clients.
Admin Affliction through Internal Tools and Systems
Your company uses a variety of tools and systems to accomplish everyday tasks. These systems and their functions have impact on the design and development of your digital project and vice versa. While the systems may never touch, it is important for us to identify what other tools accomplish to avoid duplicity and maintenance.
To illustrate, let’s use a hypothetical. During our project engagement with Company A, we have identified the client login as a major area for sales rep and client engagement. The design opportunity addresses the company’s goal to augment the client relationship.
It turns out that Company A has spent years creating a custom CRM that logs detailed information about the interactions each sales rep has with their client – each purchase and each opportunity. Imagine the project comes to completion without the opportunity to look at and ask questions about the CRM. The project is at great risk of creating more work and maintenance internally, and duplicating functionality that already exists in the robust tool used by the company. Do you really want your employees cursing the day the website caused them to maintain data in two places?
Admin Affliction through Internal Processes
Whether or not you are aware of internal process within your company, they exist for almost everything. They’re not always good, but they exist. Say, for example, you want to publish content to your website. Who writes it? Who approves it? Who puts it up there? Or what happens when a customer places an order over the phone? Is it entered into a system? Who fulfills the order? How do you know it has been fulfilled?
When doing a redesign, it is important to investigate the processes that exist internally that the system may touch or change. Imagine that your project involves changing your current IT services system. In this scenario, target users of the design would be employees of your company. Logically, one would research the issues and needs of the employees, but something that may be forgotten is how the change will affect how the IT employees will receive and fulfill these requests. They, no doubt, have developed a process around internal systems, from custom ticket-tracking fields in call-support software, to documentation and training materials. By investigating that process, we can accommodate their needs and maintain efficiencies while addressing pain-points on their side of the system. Conversely, by ignoring processes on the IT side, a redesign of the service system may result in a mass amount of IT requests that aren’t actionable because a key piece of information was not collected.
Admin Affliction through Company Culture & Branding
During stakeholder interviews and project kickoffs, we often ask about a company’s origin story, culture, values and their vision for the future. While this may seem odd, imagine if we went through the entire project without understanding how a company sees itself. The outcome would potentially be a solution that doesn’t represent who they are. Suddenly, their website might feel like a limb of the company that doesn’t belong to them!
Additionally, if we didn’t know how the company wants to grow, we could potentially be suggesting a platform or design that cuts an opportunity off at the knees causing the need to start from scratch when the company is ready to level-up.
While this is just a short list of the types of admin affliction that can occur in any digital project, they illustrate a key point. Design is about users, but it also has a whole lot to do with a company. If we don’t understand who the stakeholders are, what the company does and where the business is going, we are setting the company up for failure. Fortunately, The Nerdery’s UX discovery process is designed to mitigate the risks that arise as a result of admin affliction. My teachers always told me that smart kids ask questions and that’s what we do (until we’re blue in the face) to set a project up for success.
Using UX tools to serve all your users. Yip, even the plush aliens.
By Emily Schmittler and Christopher Stephan, Senior UX Designers
As UX designers, we always want people to understand, benefit from and even enjoy the designed interfaces and experiences we’ve shaped for them. The clients and companies we work with feel the same way; however, where we often differ in approach is in how we do the work to get there. To many UX professionals the appropriate process involves engaging with and talking to members of the target-user population. Many companies assume the UX professionals they hire have built-in knowledge about their audience and don’t think spending time with users is necessary.
This thought – that we in UX have users “all worked out” – is a frequent cause for concern. Sure, we can perform expert reviews and analysis, we have principles like Fitt’s Law and “7 (+ or – 2),” and an often involuntary strong gut reaction to interfaces that are not as clear as possible. However, no set of models, rules, guidelines or physical reactions can ever effectively approximate a single human being, let alone any group of them. Humans are unpredictable, frustrating, willful and sometimes hilarious. In short, your users are Yip Yips.
How are Yips Yips like users?
You’re likely wondering what comparison we can make between your customers, subscribers, visitors and contributors to bug-eyed, plush alien rags with a lot of mouth that sound like ⅓ of every corporate teleconference you’ve likely ever witnessed. For that you’ll have to journey with us beyond the puppets to the puppets’ behavior. Lets take a closer look at Yip Yips.
They’re not from around here
Yip Yips are aliens from a different planet. They are not like you and they do not respond how you might expect. Users don’t come from planet YourOrganization. And just because you think your instructions are straight-forward and your meanings plain, they might not mean anything to a creature from outside your intellectual ecosystem.
Their background and understanding is not like yours
Yip Yips don’t have your frame of reference, your cultural history, your idioms, jargon or catch-phrases. This means they cannot be expected to perceive your world in the same way as you, talk about it using the same words, or approach things in the same way.
They are smart and learn from their experiences
The Yip Yips are examining our world and forming reasonable intelligent opinions based on their experiences. This means that they are not passively consuming what they see and hear. They’re finding ways to understand and engage. Users are also going to – consciously or not – try to understand your offering and message. They will make connections and meaning that are sensible and relevant to themselves.
They have goals and came for a reason
While not trying to actively conquer earth – so far as we know – the Yip Yips do seem to be here to learn. They are driven by curiosity and the need to learn and understand. Your users are going to have goals, too. Like the Yip Yips, we can’t be certain what caused them to visit or engage.
5 Things Yip Yips Teach Us
(In their own special way)
Some of what you are about to see you may have seen before. Not on PBS, but in the behavior of your users. While most of your users are likely not covered in colorful plush fur and have fewer antennae, they still do what can seem to be strange, random and unpredictable things.
Yip Yips Discover Earth
While the Yip Yips didn’t find Earth – their intended target – right away, they did learn a few new things during their exploration.
Lesson 1: A user’s experience is about the journey as well as the destination
In the process of looking for Earth, each new discovery was exciting and educational, making their experience an overall positive one. Users may not always know exactly what they are looking for, so it is important to identify what they find valuable, useful and entertaining to make sure that their journey is always positive. While you might have your main navigation nailed to perfection, users may need more to engage them and keep them returning to your site or application.
Your Project: The user who doesn’t know what they are looking for is just as important to the success of your design as the one who does. User research and an understanding of their behaviors can help determine how to support exploration and playfulness in these less-directed individuals.
Lesson 2: It’s good to be challenged, in some cases
Not everything has to be easy. Again, pointing to the fact that the Yip Yips enjoy their journey to finding Earth even though it isn’t successful immediately demonstrates the joy individuals often find in being challenged. Commonly, clients misconstrue UX to be about making things “easy to use.” Au contraire! A challenge can make experiences more enjoyable than something that is perceived as easy. Consider the design of a game. Are easy games fun? Not really. Therefore, UX plays a very important role in determining level of challenge that proves engaging. In these cases, it is essential to determine an adequate level to ensure the offering isn’t so difficult that it’s frustrating – or so easy it gets quickly discarded as boring by consulting users via testing.
Your Project: It’s okay to make things harder for a good reason. Just not too hard. Usability testing is a great way to test concepts that need the appropriate amount of difficulty.
Yip Yips Discover a Clock
Lesson 3: Even a detail can scare people away
Another common misconception about user research is that it’s nothing more than asking users what they want. In this example, the Yip Yips are presented with a clock. The clock has all the attributes they were expecting; however, it still scares them away resulting in an overall negative experience. While user research may seem aimed at discovering what users want, it more importantly uncovers why they want it – allowing the designer to make educated decisions on whether the requested feature is appropriate – and what would make the experience useful. Therefore, we employ research methods to get at the core of what users are experiencing so we can address the problem instead of offering temporary relief of the symptoms. Further, we test those ideas with those users to ensure that the intended outcome is met.
Your Project: Don’t focus discussions with users on what they want, instead talk about the problems they are facing to understand their viewpoint. Use the problem space to inform design decisions, then test for success.
Yip Yips Discover a Radio
Lesson 4: Users might not want what you’d expect
In this case, you could make the common-sense assumption that people have preferences for certain genres of music, but overall the experience of music is pleasant. The Yip Yips prove that a general understanding – or a common sense approach – is not enough to design an experience that is inherently pleasant. What if – like the Yip Yips – your users have totally different preferences than you would expect [and would rather listen to static]? This is a more common occurrence than you might expect.
Your Project: It is extremely important – especially with new product concepts – to research and test ideas with real users before making a large investment to develop an idea. By involving users, you can more easily determine worthwhile features more quickly. There are many ways to involve users in the design process that go beyond asking what they want. Consider collaborative design sessions with your users, or methods that look at the problem space in a broader sense, like observation.
Yip Yips Discover a Fan
Lesson 5: Engagement doesn’t mean positive experience
Ever look at your site analytics and think, “Wow! People are spending a lot of time on our site. That’s great!” Unfortunately, you may be misreading your data; however, there is no way to prove it without diving deeper. In this video, the Yip Yips demonstrate how a user can be (or appear to be) engaged, but have a totally negative experience anyway in that they are blown across the room… twice!
Consider that sometimes users are obligated to use a system. Signing up for insurance, using a website for work, doing taxes are all examples where a user has a task that they must complete; therefore, they are likely to spend more time painstakingly interacting with a system they may have otherwise ditched when the unpleasantness began. In these cases, the analytics may look as if a user is engaged, but that’s not necessarily the whole story.
Your Project: Even if you have really robust analytics data that suggests positive or negative experiences, it is really important to dive deeper using qualitative research methods to ensure a successful redesign.
An Ecosystem Full of Yip Yips
So if users are like Yip Yips, what does that mean for how we think about users? It proves that we should be watching them a little closer, and trying to understand their motives or support their interests. Luckily, UX designers come primed with tools and methods to help you build that understanding and define where the overlap between business goals and user needs lie. And, you don’t necessarily need to spend a fortune to do it. We can help you to better know your Yip Yips in a variety of ways within your budget.
Now that we’ve told you why you need to think of your users as Yips Yips, stay tuned for some ideas about how to do research with your users, and how to test the designs that your research has informed. Watch blog.nerdery.com for part-two of the Yip Yip adventure!
Have you watched the show BarRescue? It resonated with me since I was a former bartender and now user experience designer. There are so many comparisons to be drawn when creating customer experiences in a bar and digital user experiences.
Bar Rescue features the boisterous and successful bar consultant Jon Taffer and his team of top chefs, mixologists, interior designers and other experts The premise of the show is to renovate and transform failing bars into successful bars. They do this by diagnosing problems and using methods and tactics similar to the user experience process.
In this article, we will cover these similarities in three phases—Discovery, Definition and Design.
Jon would begin his operation by agreeing with the business owner to install hidden surveillance cameras in the bar to document the problems with operations, behavioral problems or delays with customer service.
Frequently, user experience designers also discover business problems through a variety of research methods including contextual inquiry or other observational methods.
Jon and his team would then tour the facilities finding things like unsanitary kitchens, health code violations, unappealing food or beverages and other things that were detrimental to the business.
UX designers can also document knownproblems, as well as uncover problems that the business may not be aware of. It’s also common to perform a heuristic evaluation to identify problems and determine how an existing digital experience might be improved.
When evaluating businesses, Jon’s team would sometimes weigh liquor bottles before and after a work shift to determine the amount of over pouring occurring. He also used bacteria devices to measure the amount of bacteria on kitchen surfaces.
It’s also a common practice to evaluate website and app analytics to understand and optimize usage. Analytics can lend insights into key performance indicators including volume of sales, conversion rates and other metrics.
Jon and his team would always meet business owners and staff to review his findings and discuss the challenges they need to solve.
It’s critical that business stakeholders also meet with user experience designers to discuss pain points and ultimately determine how to solve and prioritize the business problems.
Jon would frequently review customer reviews of the bars through Yelp or other review sites to get documented, honest feedback. Jon would also send in individuals to each bar to document and verify their customer experience. In other cases, Jon provided mobile apps to customers to provide their ratings on the service, food and beverages. This customer feedback was reviewed prior to the bar makeover and after to help measure the results.
It’s a best practice to communicate with the end users by performing user interviews, providing surveys, or performing other user research methods to learn more from the end-users before and after product deployment.
A primary part of Jon’s customer research is to understand the demographics, interests, desires and income of the people from the surrounding neighborhoods. It was common for failing bars to alienate their audiences or not market to the primary audiences. Even small changes to the business had a great impact for new customers.
A critical part of designing your digital experience is to perform user research. This research helps define all of the different types of users, their unique goals, needs, behaviors, reservations, desires and how and when they will use your digital product.
In order to further solve their problems, Jon identifies the competitive bars and restaurants in the neighborhood to determine how the business can develop a P.O.D. (Point of Difference) to have a competitive edge.
In user experience, a competitive analysis can identify competitors, their offerings and understand how your business can highlight your competitive advantages.
Jon would also create floor plans to develop structure and help maximize the potential for each room.
User experience designers also create sitemaps to provide high-level visualization of the hierarchy and the relationship between content.
As a part of his blueprints, Jon considers the “flow pattern” of every room. This flow can increase customer interaction, increase efficiency and ultimately boost sales.
User experience designers also create user flows and process flows to further document how users will use a digital product within the system and how it may interface with other non-digital experiences.
Food and beverages are the heart of the restaurant and bar experience. In most cases, the struggling bars didn’t cater to their audiences or the menu items were bland. Sometimes drinks were limited and unappealing. Customers also had to wait long periods of time for servers and bartenders.
With your app or website, your content is what people consume. Users want quality content that quickly serves their needs and desires. If it’s a struggle to find content – just like it is difficult to find your waiter – then people will not hesitate to leave and never come back.
According to Bar Rescue, when customers read a menu for longer than 109 seconds, they become fatigued and order less.
Some restaurants used gimmicks that were counter-productive. For example:
• An unused mechanical bull was an eye sore.
• A lobster claw machine offended customers.
• A golf simulator was unused by customers since they came to a bar to relax.
• A punching bag boxing game even left a customer with abloody hand and a business lawsuit.
All of these things initially sounded like fun, but they took up valuable space and ended up costing businesses big money.
It’s common for clients to request website redesigns to make it more “engaging” or “interactive.” However, interactivity alone doesn’t solve problems. The interactions and tactics must be useful, valuable, and help support user goals. See my article Trends May Not Be Your Friends for more insight on a strategies first approach.
Jon’s team also had customers evaluate menu effectiveness with retinal eye tracking software and hardware. In one episode, customers’ eyes went to the least profitable items on the menu, causing lower profitability.
A part of usability testing may include eye-tracking to help determine if users are successfully using an application or if they were fixated or distracted. Other research methods may be more appropriate depending on the project. The fact is that the science of usability and research matters to the quality of your product.
Once Jon and his team helped the business make adjustments to the menu and properly train the staff, they conducted a “stress test” to determine how the staff would perform and then make further adjustments.
In user experience we create prototypes, perform usability testing, QA testing and other testing before launching an app or website. These tests help collect valuable information and help determine adjustments to be implemented prior to launch.
Many of the struggling bars had unappealing, dated décor, worn booths or had themes that alienated customers. One restaurant looked like an auto shop from the outside, which confused customers or made them ignore it entirely. Jon’s signage and interior design teams helped businesses create signage with images of foods with bold text to clearly and quickly communicate with customers.
Websites and apps also must be visually appealing and appropriate for the audience. It’s important to quickly communicate your company services and products within seconds. Users may quickly abandon your app or website if it doesn’t communicate or look professionally designed. Your digital experience should consider all aesthetic aspects including the branding, content, subject matter, typography, photography, iconography, animation, transitions, spacing and other visual considerations that improve the experience.
At the end of every episode of Bar Rescue, the restaurants had been transformed, customers were happier and they revealed the business results. Results included statistics like “Food sales were up 30%” or other measurements that impacted the business bottom line.
It’s also critical to measure the success of your digital product. It’s important to not just measure the number of click-throughs or time spent on a website, but to track key performance indicators and metrics that impact the business. Did sales increase? Did the product help manage costs? Did the software create greater efficiency and less time spent performing the same activities? If you focus on business measurement as a goal, you are more likely to reach that goal.
Success doesn’t just happen by mistake. It happens from planning, communication, developing strategies, discovery, testing, tracking and other factors to create direction and ultimately success for users and the business. If it’s good enough for a bar or restaurant, it’s hopefully good enough for improving your digital product.
Usability is nothing new to IT, software, or design. It is one of the fundamental building blocks of the UX practice, and is the grandfather of evaluative UX methods which help us to judge the effectiveness of the solution we are constructing. Despite its history, recent usage has given it a layer of tarnish, making it a hard to sell and hard to include where it could do some good.
In previous installments I have re-introduced you to usability as a part of the user experience process and practice, dusted off the value and offered it to you both plated in gold and on the cheap. Also I have explored how poor use and understanding blackened its name, and told you what lies in wait if you leave it out. Last time I told you not only how you can use it but also when. Finally, in part four, I’ll show you how it could change what we presently think of as QA.
When you want to get everything right
I’ve said previously that usability sometimes coincides with and is then presumed to be a QA function. I have also said that this perception is primarily the result of the timing with which it is frequently applied, and the time and budget available to fix things. Based on what I’ve said in previous posts, you might expect me to repeat what I’ve said about leaving usability until too late in the project. To those I say; Don’t leave your usability until too late in the project. If you want to know why, you may want to revisit parts two and three of this series. If you find yourself taking offense that any UX method could possibly be seen as a QA measure out of a sense of injured professional pride, stop. Before you warm up even one more indignant neuron, let me turn that on its head.
Hey! You got your QA in my UX
Much of what we do in UX is, when you boil it down far enough, is a QA measure. Which is to say that its purpose is to improve the quality of the product and the experience of the user interacting with it. We do research with users to ensure that the we design the right thing to solve the right problem. Then we test with users to determine how successful we have been in our designs.
Usability, and evaluative UX methods in particular, are the only way that we can objectively evaluate design by engaging with real users to evaluate our work. This is not a test of “did it work as it was intended to”, but instead a test of “is this intended to do the right thing.” It is in this regard, as a tool for ensuring design quality in particular, that usability stands shoulder to shoulder with established QA practices when they test the designed functionality of developed code. So yes, UX is QA.
Nuh-Uh! You got your UX all over my QA
QA, as a practice, has it’s own problems. The greatest of which is the fact that they are consulted at the eleventh hour, when their expertise and findings are more difficult to act upon. Does this sound familiar? I think QA should engage early and often, in much the same way I think evaluative UX measures should be taken early and often. Now, with that idea tickling your synapses, it should seem only natural that QA professionals should become UX professionals. From the ranks of testers, technicians and troubleshooters, we can grow usability analysts. We can build partnerships that surround a project – testing and improving it from early discovery to post-launch management, not just from ideation to launch.
We can arm QA departments with valuable UX tools and methods that they can apply either on their own and in partnership. They can continue to actively support the success of the project by doing what they do best – poking holes and breaking things. They can also engage with the project at more points in its lifecycle. Finally, they can do formally what they’ve always done quietly; evaluate with UX in mind. And in this, QA is UX.
The Efficiencies of Partnership
Not every organization will have the ability to have UX and QA work closely and cooperatively. Not every organization has both departments in-house. However, if those of us in UX, and our colleagues in QA both start viewing our roles as complementary, and start working from the same basic play books, the opportunity to collaborate improves regardless of whether it’s within or across companies.
By linking UX and QA, UX maintains project visibility for more of the lifecycle, beyond the inception of the development phase, and in return QA gains formative input and can raise concerns when they arise throughout the project. We also double our resources when it comes to staffing our evaluative efforts. Methodologies, insights and resources can be shared to ensure that projects get the care and attention they need throughout their lifecycle.
I hinted a bit at what QA staff can do as UX Analysts, but let me be more concrete. There are many tasks and services that can be accomplished in partnership with QA, or offered whole and complete by a QA department.
Heuristic Review (Investigation, done in a Discovery phase)
Format defined by UX
Conducted by: QA or UX
Synthesis: QA, UX or Collaborative
Usability/Task Analysis (Evaluation, done in all phases)
Format defined by UX
Test authoring: UX or Collaborative
Test execution: Collaborative
Accessibility Audits (Evaluation, done in all phases)
Format defined by QA
Conducted by: QA or UX
Synthesis: QA, UX or Collaborative
This allows QA departments to be more proactive, more engaged with the project’s health and success. Also it opens new revenue streams and engagement models that allow QA to show it’s value either in standalone engagements or as part of a larger project. In working with UX, we multiply the reach of both practices to positively affect project outcomes and finished products.
To sum up
UX has similar aims as QA. QA has the same overall goals as UX. There is a lot to be gained by building a common vocabulary, toolset and partnership between the two. Each can further enable the other, and together the combined resources and expertise can transform our expectations of project success. So, UX and QA professionals…get on that.
A final thought on usability
If you come away from here with one thought I would prefer it be this: The thought that you should be doing more usability. That you should want your designs to be vetted as thoroughly as your functioning code. That you should care about quality enough to apportion the time and budget to get it right, rather than eat the time and cost of fixing it when its wrong.
It doesn’t have to be expensive. It doesn’t have to be elaborate. But it should be in your project process. You should have space to size and plan and implement evaluations at the right times and in effective ways. You should include evaluative tasks in your projects. You should test your stuff.
Every year, articles appear in the blogosphere touting new UX trends or technologies. Some trends have merit and value. Here at The Nerdery we love to constantly push boundaries. However, sometimes when companies implement a trend, they put the cart before the horse. No matter what tactics you choose to employ, it’s always best to start with defining the problem you need to solve for the opportunity at hand.
Many of these trends appear engaging and beautiful on the surface. Designers and stakeholders may have the best of intentions when implementing the latest trends. However, blindly implementing trends can also fail miserably without a sound strategy.
Here are examples of trends or tactics that may have their downsides:
Parallax scrolling is a technique used where background imagery moves at a slower speed than images in the foreground, creating the illusion of depth. It can be very successful in the right situations and when implemented well.
User Experience Design considerations:
• If users need to find content quickly, scrolling through large volumes of content may deter impatient users. The Crate and Barrel parallax site requires users spend about 15 seconds browsing Christmas tree ornaments.
• If there is a large volume of content, it may be difficult to find hidden content and it may be difficult to search the site.
• If users are unsavvy, they may also be confused by the moving parts and animation.
• Content may take longer to load, if developed on one page.
• Depending on the way it’s built, parallax sites may limit search engine optimization.
• Parallax sites add a level of complexity for responsive design.
When Parallax works:
Parallax sites can be effective if you are providing users with linear experiences like stories or walking through a process. It’s also important to include sticky navigation to allow users to skip ahead to topics of greater interest, if applicable.
I love games and appreciate how they can be used to engage users. However, Gamification is not as simple as slapping on badges, leaderboards, points and “gamifying” your website with rewards. Some big brands have failed using gamification and companies continue to waste money while providing poorer user experiences.
Audiences and customers vary in their contexts, motivations, interests and desires. People are complex. Without user research and a sound strategy, you may be designing a product that users will not find valuable or impactful.
Oftentimes, games are built with the goal to increase user engagement. But engagement can be achieved in a variety of ways. Games are just a means to an end. We must first justify the means.
Think about the Harry Potter books. There are no badges, leaderboards, nor even pictures, yet children and adults spend countless hours of engaged reading. It’s due to the story, relatable characters, themes and other content that conjures emotions. Engagement can come in many forms.
It’s critical to understand what drives people. What are the things they need to learn and do? How are they motivated? What drives their behaviors? After a thorough discovery process we can better determine if a gamified system is actually the best tactic to achieve your goals.
Strategy Before Tactics
In general, any tactic without a sound strategy has a greater potential to fail. It doesn’t matter if it’s mega menus, blogs, social media tools, or infographics – it’s best to begin a project with a discovery process and user research to help align business goals with user goals.
At The Nerdery, we create strategies that help identify and prioritize business goals and user goals. Our discovery process may include workshops, stakeholder interviews, analytics evaluation, user research, surveys, contextual inquiry, personas, and many other methods to create a laser-focused strategy for your business or organization.
Design for People First
It’s certainly important to understand what new technologies and trends are being implemented. However, instead of designing with the tactics and technology first, we should first consider the people and their motivations and goals. Ultimately, we are designing for people—people who happen to use technology. If we begin with a solid foundation and target goals, we have a higher likelihood of achieving those goals.
“I need a website.”
Say these four words to any user experience (UX) designer at The Nerdery and watch their head swim with questions: Why do you need one? Who is this website for? What will it do? Where will it live? Who will maintain it?
Not every client has the vocabulary to articulate the answers to these questions, but just because they don’t have the words, doesn’t mean they are lacking a vision. Understanding this vision is critical to the success of the project. The earlier it happens, the better. By asking the right questions and using methods like sketching and visual examples, we can more quickly understand and align with our client’s expectations.
You say tomato and I say Solanum lycopersicum
At the beginning of projects, we write proposals and Scope of Work documents in order to arrive at an agreement about what we’re building. Relying on words alone to describe interactive, visual, complex concepts presents the following challenges:
- It’s hard to strike a balance between technical specificity and client-accessible language.
- Our industry’s vocabulary grows and shifts constantly.
- Our clients have different experience levels, backgrounds, and perceptions than we do.
- Words leave things open for interpretation.
- Words don’t evoke the emotional response that allows clients to compare their vision with ours.
I’ve experienced the frustration that occurs when a client “sees” something for the first time (design concept, wireframes, etc.) and it doesn’t align with their vision. The situation becomes emotional, even though we did our due diligence. The client already signed multiple documents describing everything they’re seeing, but they read those documents through the lens of the picture in their head, not ours. There’s no fault here, just room for improvement.
So, how can we arrive at an understanding of the client’s picture (vision, expectation) sooner?
The Role of Experience Architect
When The Nerdery created my role (Experience Architect) last August, it was so that we could better strategically support our ad agency partners, who experience this problem more often than most. In general, agency projects have very specific constraints and expectations. My job is to understand and validate these expectations quickly, so that our partners are equipped with knowledge to take back to their end-clients. With many agency projects, we’re brought in before our agency partner has “sold” the project to their client. This is ideal, because it allows us to help shape the vision to work within the constraints.
The Value of Sketching – Keepin’ it Real
The method I use most frequently to align expectations is interface sketching. I’ll explain a concept or feature, then roughly sketch it to solidify the understanding. I repeat this process throughout the entire project. It’s cheap, easy, and low-fidelity enough to imply a level of uncertainty, while still keeping it “real.”
This methodology can work extremely well for any client, agency or otherwise. It “demystifies” the UX process and gets clients involved and excited sooner. Best of all, it allows us to course-correct almost immediately if the client or partner has a different picture in their head.
By involving UX earlier in the project process to ask tough questions, communicate ideas visually and align expectations, we reduce the risk of misinterpretation. We also demonstrate our commitment to be a strategic partner. Written documents will always be necessary to communicate certain types of information (e.g. contractual), but the next time you’re trying to communicate a visual idea, think about grabbing paper and pen.
Usability is nothing new to IT, software, or design. It is one of the fundamental building blocks of the UX practice, and is the grandfather of evaluative UX methods which help us to judge the effectiveness of the solution we are constructing. Despite its history, recent usage has given it a layer of tarnish, making it a hard to sell and hard to include where it could do some good.
In previous installments I have re-introduced you to usability as a part of the user experience process and practice, dusted off the value and offered it to you both plated in gold and on the cheap. Also I have explored how poor use and understanding blackened its name, and told you what lies in wait if you leave it out. This week I shall tell you not only how you can use it but also when. Finally, in part four, I’ll show you how it could change what we presently think of as QA.
Judging the size of usability
While we can plan to always test something, that doesn’t mean everything needs the same amount of testing. Its true that not every project will need the same level of evaluation. However the gradient to judge these things is fairly simple.
The more common your design, IA and interactions are (a WordPress brochure-ware site with a modest ecommerce implementation) the less you’ll need to test.
The more novel or unique your design, IA and interactions are (some crazy new set of widgets that will change everything) the more you will need to test – and the more novel your testing methods will need to be.
There are no gotchas here – just an intention to do it right that can then be scaled appropriately to the needs of the project. Also, don’t make the mistake that a common interaction is by nature free of any testing burden. Just because a pattern or widget is well understood, it does not mean that the interaction is appropriate, properly labeled and implemented in way that supports the user. You still test. You just test appropriately. So the next thing you need to work out is when to implement the testing you know you need to do.
Timing your usability for best results
The best approach is to expose any designed solution to user feedback early and often. It is safe to assume that presumptions and gaps in understanding will cause some degree of failure in any project. However, if we plan to fail early during ideation and design when it’s cheap and easy to adapt and change, we can then watch the points of failure decrease – and then disappear – as the project progresses. Usability testing provides the mechanisms by which design can be evaluated and that value and effectiveness can be judged. Ongoing checks can then provide a level of confidence that the designed solution meets any known or discovered need.
Okay, so when exactly do we test for usability?
It occurs to me that “when” can still seem vague, so let me be clear. I do not mean “on a Wednesday before noon.” Although how any specific timeline works and the length of the project may vary, there are five points in the project lifecycle where usability can improve your work. All you ever need at any of these points is a thing to evaluate, and users to evaluate it.
Testing present state
This brings users into contact with an existing tool, app, or other artifact as part of discovery. It can be applied to a current version to inform a redesign, or be applied to competitors to discover design gaps and opportunities.
Imagine a competitive analysis that isn’t a list of what the competition has, but is instead is a breakdown of what they have that is valuable to users, and why it’s valuable or why it’s not. Imagine not having to guess at where your users are feeling frustrated as you choose what changes to make, because you’ve been able to watch them use your tools and seen their pains firsthand.
Testing the concept
At this stage you may be testing a storyboard, flow diagram or other very high-level concept. Just enough to get your idea across to see if it seems to be of value to the user, and worthy of continued development.
Here is where you can make some of the big decisions, test the big assumptions and ask the big questions. Why are we doing this? Will doing this yield real benefits, and to whom? Are we solving the right problem in the right way? Testing the concept with users is a method for moving away from holding your ground and into sprinting ahead.
Testing an articulated prototype
At this stage you have a more concrete and robust representation of what you’re making. It could be an interactive prototype, clickable PDF, paper mockup or any well-articulated version of what you are working on to test with users. Interactions may be limited to a representative sample, but you should have enough to be able to gather feedback to see if your layout, interactions, labeling and flows have any major flaws.
If you had to choose just one place to test, this is it. It’s early enough that sweeping change won’t kill the budget or timeline, and late enough to have a more concrete representation of what you’re building to test against. If you also tested the concept, you get to see if your fixes were effective. Methods and fidelity will vary, but the important thing is that at this point in the project things are still malleable.
Testing a developed prototype
This is what most people already think of as a “prototype.” It may be a whole or partial/representative solution. It will likely at this point be built in front-end code and have a layer of styling applied. The back end may still be decoupled, and data may be static, but “real-looking.” This is where we test in hi-fidelity.
When the visual design is incorporated and real interactivity is introduced, it helps to revisit things with users. You can recheck that problems found earlier have been resolved and that more complex interactions work as the users expect them to. Furthermore, you can ensure that things like color, typography and final placement and behavior are not introducing new barriers to users’ use and understanding.
Testing the deployed solution
This effort occurs when all the development work is complete. It may be during an alpha or beta release or even after full launch. Its purpose can vary based on the timing. If executed post-launch it either informs the next phase of work, or becomes part of the user-feedback cycle of a planned product-management regimen. If executed in an alpha or beta release, it allows for fine tuning of the interfaces and interactions.
It’s impossible to be too positive about testing to make good things even better. A late test like this allows real user feedback and analytic data to be combined with qualitative user tests to add the layer of shine one expects from a best-in-class solution. This perhaps points to something that should have been clear throughout: that when you test with users, things get better – and the more you test the better they get. This should not be your only test. It’s too late to make big changes, but it’s the perfect time to refine.
You should also plan to iterate if possible at every point you can. Whichever point you test at, stagger your testing to allow time for adjustments and refinements between passes to weed out more and more noise to get more signal.
So when you say “Prototype”…
The narrower definition of prototypes as “alpha release code” discourages their use for design experimentation and iterative improvement by focusing on a point too late in the project-development process for that level of freedom.
The variety of prototyping methods and media mean that prototyping can be both rapid and inexpensive. That there are no excuses. Make lots of prototypes. Make them early. Test them often.
To sum up
We’ve talked about how much you should test and when. It’s not difficult to understand how much testing you should feel on-the-hook for. Let complexity and novelty be your guide, but don’t let commonality and comfort make you relax your rigor.
Also I’ve given you five points in the project lifecycle to test at. To test iteratively at. Used all together. they will yield a well-honed and well-focused end product, but if you have to choose just one step, test at point three, the Articulated Prototype.
Finally, I’ve told you that a prototype is more things than you may have thought. They vary in form, complexity and labor required. Also, they’re not expensive. So go make some.
Imagine a world where we test design the way we test execution. In the final installment of this four-part series, I’ll talk about UX, QA, and where they can support each other to create a more robust quality process for the creation of anything at all.
It’s Not Your (insert digital thing), It’s You.
The title of this blog post is news I have to communicate to my clients regularly. I have to look them straight in the face and tell them: “The problem you have with your [website, mobile app, digital experience] is a people problem. It’s not the design, it’s not the UX, it’s not even the content. I mean, it may be all those things. But those things are just symptoms of a problem with people.
Let me be clear, though — I’m not saying that people are intentionally causing problems. In fact, more often than not, they have the best intentions. It’s just that those intentions aren’t always aligned and prioritized.
Alignment and prioritization comes with a solid framework for governing your digital things. Governance is made up of four key parts:
Authority: Who is empowered to make and enforce decisions?
Planning: How do you decide what projects to take on and how do you prioritize them?
Measurement: How will you determine if your digital things are getting you the results you set out to achieve and how will you make adjustments when necessary?
Tools: What kind of support do the people working on your digital things need to be successful?
For more on governance, check out our recent webinar.
So, how do you know if you need governance? Short answer: Yes. If any of the following symptoms sound familiar, you do. If none of the symptoms sound familiar, you are probably already doing it.
SYMPTOM 1: Perpetual Redesign
This symptom can also be described as trying to put lipstick on a pig. If your organization has found itself embarking on re-design after re-design thinking the way the site looks or the interaction patterns are the problem, you likely have a problem with content governance
SOLUTION 1: Define Your Content Strategy
Content is the reason most sites get any visits at all. People are looking for information. If they get to your site and they can’t find what they need or it’s not presented in a way that makes sense to your site’s visitors, you’ll lose them.
The first step is to articulate the purpose of your site’s content, who it’s for and what it should do for your business and your users. Then, craft your content accordingly. Get rid of what doesn’t belong. Revise it to meet user’s needs. Organize it with business and user goals in mind.
SYMPTOM 2: Microsite Mania
There are some good reasons for microsites. In my experience as a UX and content strategy professional, the reason I see most often is that a business unit decides to go rogue to avoid dealing with whomever is responsible for the core website. The reasons for going rogue range from it being quicker to do it on their own to not wanting to be told no. That’s the one I’ll focus on.
SYMPTOM 2: Win Over Stakeholders
Recently, my colleague Hannah Grossman and I were discussing the characteristics of a successful web project. We landed on stakeholder engagement and alignment as the universal contributing factor. It’s not enough to come up with a strategy. When stakeholders feel a sense of ownership, they are less likely to go rogue.
Start with understanding who your stakeholders are, what roles they play on your project, and what their pain points and challenges are. When you approach it from their point of view, you have a better shot at keeping your digital presence unified and on-strategy.
Here’s a handy matrix to get you started.
SYMPTOM 3: Homepage Turf War
We’ve all seen websites that are so jam packed with content that we have no idea what to look at. Or, there’s the home page carousel full of messages we’ve never bothered to look at. That’s what I’m talking about when I say homepage turf war. It happens for a couple reasons:
People throughout the business think their content is the most important
No one is empowered to create or enforce a strategy that suggests what’s most important
…make sure everyone who might contribute content knows who’s in charge.
Assuming you have a strategy and the guidelines to support it, the solution is quite simple. Give someone authority. Real authority. Let them tell the VP of Marketing no, emphatically, because what they’re asking for doesn’t support the strategy. And make sure everyone who might contribute content knows who’s in charge.
Empower them to enforce — and sometimes break — the rules you’ve set to follow a plan that supports your business goals and achieves your users’ needs. Even better? Insist they have a seat at the table as your business partners are determining how to communicate in the digital space. They can set expectation early to avoid conflict down the road.
Get your gavel
OK, so governance doesn’t have to be heavy handed and it doesn’t have to be a ton of work. Start with the basics and add as necessary. Job no. 1 is to document your strategy and the guidelines that will help you achieve it. From there, it’s mostly about communicating and collaborating. And recognizing that at the heart of whatever digital thing you’re doing, is the people.