Long-time listeners, first-time Soundset mobile App makers

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. Continue reading Long-time listeners, first-time Soundset mobile App makers

The Art of Remote Communication

The Scenario

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…

Continue reading The Art of Remote Communication

Hitting the Strategy Sweet Spot: The Importance of Business Discovery

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.

Continue reading Hitting the Strategy Sweet Spot: The Importance of Business Discovery

Your Users are Yip Yips

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.

Continue reading Your Users are Yip Yips

The Science of Successful Bars: How Customer Experience Relates to Digital User Experience

Bar RescueHave you watched the show Bar Rescue? 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.

Continue reading The Science of Successful Bars: How Customer Experience Relates to Digital User Experience

Reclaiming Usability – Part 4: UX and QA, an Evaluative Partnership

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

    • Synthesis: 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.

Don’t Let the Buzz Fool You: Trends May Not Be Your Friends

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

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.

Technical considerations:

• 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.

When Words Fall Short: Sketching to Align Expectations

“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.

Reclaiming Usability – Part 3: Where you can put your testing

TestingIconUsability 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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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”…

A prototype is any representation of a thing, that is not yet that thing. This can include coded HTML/CSS/Javascript mockups, interactive prototypes (Axure and Protoshare), clickable screen-shows, storyboards, flowcharts, and any other thing that can communicate the intended behavior and information on screen or on paper.

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.

Next up…

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.

Reclaiming Usability – Part 2: Who Put Usability in the Corner?

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.

Last week I re-introduced you to usability as part of the user experience process and practice. In the next three parts I will dust off the value and offer it to you both plated in gold and on the cheap. I will explore how poor use and understanding blackened its name, and tell you what lies in wait if you leave it out. I shall tell you not only how you can use it but also when. Finally, I’ll show you how it could change what we presently think of as QA.   

Part 2: Who Put Usability in the Corner?

When people think of testing something, there seems to be a comfortable place where the mind settles. They want to test it when it’s as complete as possible, because they think that’s when it will be most valuable. As it turns out this is a fallacy. While you do get very detailed and concrete feedback on a very complete version of what you’re testing – you also have no more time or budget left to act on the information you get.

As a result some projects don’t survive to see a phase two in which to implement fixes identified at the end of phase one. If this happens often enough usability begins to look like no more than an added cost that has no guarantee of ever producing an actionable benefit. The result being that companies and stakeholders may choose to avoid usability altogether because they would sooner not know about the things they aren’t going to be able to fix. If that’s what usability is, who needs it?

It’s not unreasonable to question the value of activities that only give you information when it’s too late to use it. Furthermore, it’s lamentable that the practice has been allowed to fall into its presently unusable state. In mis-applying usability we have created unusable usability – an irony so strong you can build a bridge out of it.

Discarded without a backward glance

Okay, so maybe I have talked you into thinking you should reconsider doing some usability testing in your next project. However, penny-wise and skeptical of what might be a hard-sell on a particular methodology, you may also be thinking that not every project needs usability or any sort of evaluative work. You may be thinking that you can look at your projects and pick and choose which you think can handle the extra cost – and for those you might suggest it. This, is also part of the problem. When we approach evaluation as an add-on or optional extra, as something we’ll do if we have the time or the budget to spare, we set ourselves up to exclude it. Clients like thinner budgets and this suddenly looks like a piece you didn’t even need. We make it easy for ourselves and our clients to say no, and think no more about it.

For those of you who read the previous installment “Part 1: Usability as a Valuable Part of a Nutritious UX Process” you already know that usability does not have to be cost-prohibitive. And even when the price tag seems high, the long-term effects of doing it will save you money down the road.”

Going in blind and crossing your fingers

As attractive as the lure of budget savings or blissful ignorance may sound, don’t fall into that crater. Yes, it is a crater. Untested and un-evaluated ideas, structures and interactions are more likely to suffer from unexpected failures. You may want to rely on what seem to be established patterns and well-worn heuristic knowledge, but you’re still gambling and the risks are considerable.

Lack of evaluative testing can place any project at higher risk of unexpected mid-development scope changes and finding high-profile deficiencies in QA or even post-launch when it’s far too late to act on them. When you factor in the risks of a poor launch, undertaking usability and other evaluative measures becomes a question not of cost, but of timing. If something isn’t right, you’re going to have to fix it. Better to fix it before it’s damaged your relationships with users than after, right? You may engage internal resources or external ones, but it still costs you and you’re going to pay regardless. It’s only a question of choosing when and how you want to do it. For instance; you may pay for evaluative testing and catch it before launch, or you may launch with known problems and pay after. Also, the exact nature of the costs involved aren’t always contained to time and budget. They can include negative impact to credibility, diminished project profitability, and lost opportunity to name a few.

This risk seems to be higher in projects where stakeholder assumptions and suggestions are accepted and implemented without evaluation, when we learn too late in the process about mis-alignments with user needs, or when projects outgrow their budgets via protracted, last-minute or post launch revision cycles. It’s especially true when failing projects need to be propped-up, or rolled-back just to re-establish profitability because they were either un-launchable or launched and met with derision instead of adoption.

The burden of the UX professional

Those of us who are UX professionals need to take a harder evaluative stance. It is in everyone’s best interest that we do so. We need to communicate clearly about the potential risks and establish possible repercussions and the extent of client liability when acting against evaluative recommendations. While our reputation, our profit and our opportunities as UX professionals may be at stake – it’s not just our success we’re trying to protect. We do the things we do and recommend evaluative measures primarily to protect the project’s success.

We should plan every project with the expectation and structure in place to test and evaluate appropriately. The question should not be “should we test?” it should be “what should we test, and how should we test it?”

To sum up

We’ve discussed how the way usability is often employed has served to diminish its apparent value as an actionable way to bring user feedback into the design process. Also that we make it too easy to eliminate the safeguards evaluative work provides to a project. To follow we’ve touched on the risks involved in eliminating usability and other evaluative measures. We then finished off with a call to UX professionals to act as the guardians and guarantors of a project’s success by advocating for the inclusion of evaluative measures.

Next up…

Next week I will talk about how to size and deploy usability efforts in the project life-cycle. A topic that also opens the door to a role for UX as product managers and long-term custodians of the solutions they create.