We've moved: https://arnoland.wordpress.com

Hello everyone, this is the swansong post for this site, arnoland has moved to the 21st century at: http://arnoland.wordpress.com. See you there ...

The User Experience Designer’s Charlatan Test

A First Step towards UX Sanity Checking

Below is the CHI paper I wrote on the UX Designer Charlatan’s Test. It is very much a work in progress and I invite people to help me iterate on it: what questions should be added or subtracted. Each question is not arbitrarily chosen but reflect actual UX practices in the field as practiced by companies I or my colleagues have witnessed throughout the years. Multiple companies/designers/managers have been guilty of the points made here so no one should feel any one company/designer/manager is singled out here. The answer options are agree/disagree/no opinion. I tell you in advance, No Opinion is always wrong. No opinion essentially means you do not care. If too many people chose this option for a given question, I will take that as a indication of a possible low quality question that should be replaced by a better question.

Please enjoy, think of it as the UX Follies, so no chip on the shoulder implied or warranted. I do make the serious point that UX accountability and oversight are sorely lacking but do so with tongue firmly planted in cheek.

To give me feedback on the test comment here or send me an email at arnoland -at- gmail.
I know this paper (some 10 pages long) is longer than most blog posts, I will develop a new, shorter version of this post based on initial feedback I get from readers.

ABSTRACT

This paper proposes an introspective test to see whether the reader of this paper is a charlatan UX practitioner. If so, it points ways the reader can professionalize their practice. For the non-UX professional this questionnaire can act as an interview script to ascertain how professional a potential UX candidate is during a job interview. This paper also infers a need for a governing body of some kind to assure the quality of the practitioner. The test can be taken and evaluated. Future versions of this test look to include a wider coverage of UX best practices, techniques and methods. 

INTRODUCTION

In my 20+ years of experience in the User Experience/HCI Design field I have seen not only a large amount of beautiful UX (User Experience) work ship but also an incredible amount of wasted UX effort and pointless design work. Early in my career as a consultant I heartily took part in such practices because it impressed the customer but did not serve the user nor the company hiring my work. The deep point was reached with one of my most lauded designs, a business software generator whose UI’s were based on the paintings of Mondrian. [1] Without engaging me—or any other designer—for any follow up work, the company went broke trying to implement these designs on their own. 

Since then, I have been sensitive to user experience designer charlatans. Surprisingly this represents the majority of our profession that I have observed over the years, including design bureaus lauded for their so-called UX excellence, whose work served more to stuff their website portfolio, rather than be any practical help or added value to the companies they claim to be assisting. 

Internal teams, even for many large companies, are teeming with design mediocrities that systematically see that they maintain their safe mediocrities through charlatan hiring and design practices. This paper tries to ferret out those charlatans and unmask them for who they really are. I propose that we force everyone in our profession to take The User Experience Designer’s Charlatan Test. This is a personal test that one cannot take publicly to get the correct answers. Instead this is an introspective test the UX Practitioner must take to heart and test themself. Of course, this does not take into account the power of those who lie with such ferocity that they lie even to themselves (and believe their own lies) regarding their personal competence with no or scant evidence. For those of goodwill, taking this test with an honest introspection will point out the errors of your ways and show you how to take corrective action before anyone finds out you are a charlatan. UX is perhaps one of the most curious, frivolous and unprofessional professions I have witnessed. 

How is this possible? I know of no profession more allergic to any accountability, professional standards or even some basic tenets of solid design execution. I can’t tell you how many times I have heard even allegedly experienced UX managers say, as a design direction, “Go ahead, knock yourself out.” Or my favorite, “Use your own best practices” (for the reason that you, as the manager, are devoid of them). Most UX managers are overpaid traffic cops and most designers are simply incompetent. Don’t believe me? Take the test. If you can’t get at least 80% correct (16 of 20 or using five points per question, 80 points), then you are a charlatan and part of the problem. But don’t worry; you are in very good company and the answers you got wrong can point the way to your redemption.

One word on what this paper is not: this paper does not single out any individual company or person. I mean to accuse us all and almost without exception. There is no one company, organization or designer more culpable than another. My observations cover the work of many colleagues in many companies for whom I have not worked. So everyone should feel equally distressed.

And for further clarity, here is the definition of what I am accusing you of:

Charlatan — a person falsely claiming to have a special knowledge or skill; a fraud

In answering these questions none are aimed at how things are in your company, university or organization but rather, on your practices in them. In answering the questions, answer the way you strive to behave or practice if allowed. In other words you are not a charlatan if work forces you to perform unprofessionally—that makes you something else beyond the scope of this paper. 

For example, let’s pretend one of the questions is: “Agree or disagree: You believe users are irrelevant to user experience design.” You may very well—indeed probably do—work for a company where this is generally accepted. However, if you are actively fighting against this you should answer that you disagree rather than agree with a company policy. The test is all about you, not the company or organization in which you work.

There is only one correct answer. When in doubt, choose the best answer among multiple choices. For example, if the question arises: “All users are …” though you may be tempted to answer in the affirmative, the negative is the more likely answer.

Please use non-erasable pen to mark your answers. Freudian slips are as important as a considered answer. Without further ado, sharpen your wits, and here comes the test:

The UX Designer’s Charlatan Test 

Test Questions (5 points each question):

1. Design is purely data determined
☐ Agree ☐ Disagree ☐ No Opinion

2. UX has an ROI and that is it’s sole reason to exist.
☐ Agree ☐ Disagree ☐ No Opinion

3. You know what a great User Experience is when you see it.
☐ Agree ☐ Disagree ☐ No Opinion

4. I weight positively a UX resume that shows a lot of experience and impressive UX titles.
☐ Agree ☐ Disagree ☐ No Opinion

5. I consistently follow the most trendy or popular UX methods or tools. So-called timeless ones are too academic.
☐ Agree ☐ Disagree ☐ No Opinion

6. I can judge a UX portfolio by looking at it.
☐ Agree ☐ Disagree ☐ No Opinion

7. I am intrinsically opposed to the formation of a generally (State, National or Domain specific) accepted UX certifying agency.
☐ Agree ☐ Disagree ☐ No Opinion

8. I can name what UX should own and be held accountable for.
☐ Agree ☐ Disagree ☐ No Opinion

9. Aesthetics drives the UX, consequently, someone with a good aesthetic sensibility can naturally create a great user experience? Top designers know the profession in their gut and between their ears.
☐ Agree ☐ Disagree ☐ No Opinion

10. Agile and/or lean startup are design methods.
☐ Agree ☐ Disagree ☐ No Opinion

11. I believe engineering or development is the most important aspect to creating successful digital products.
☐ Agree ☐ Disagree ☐ No Opinion

12. I can sum up what a User Experience does in a short succinct sentence or two.
☐ Agree ☐ Disagree ☐ No Opinion

13. I can name three books on cognitive psychology that I have read, relevant to user experience.
☐ Agree ☐ Disagree ☐ No Opinion

14. Excluding Steve Jobs or Jonathan Ive, when asked who is my favorite designer, I can name a designer as well as their lasting artifact of digital design excellence.
☐ Agree ☐ Disagree ☐ No Opinion

15. Without objection, I work on projects I do not believe in, it’s a job after all.
☐ Agree ☐ Disagree ☐ No Opinion

16. I believe that only designers can come up with good designs.
☐ Agree ☐ Disagree ☐ No Opinion

17. I am specialized into a single domain.
☐ Agree ☐ Disagree ☐ No Opinion

18. I am specialized in a single set of design tools.
☐ Agree ☐ Disagree ☐ No Opinion

19. No one really understands UX design. It is best if I can go off and just do it without interference from engineering or product management. Then just show them what a good job we can do.
☐ Agree ☐ Disagree ☐ No Opinion

20. When designing, I show multiple and significantly alternative concepts.
☐ Agree ☐ Disagree ☐ No Opinion

The correct answers

1. Design is purely data determined

DISAGREE — data can inform design but data cannot make a design decision. Well collected and analyzed data can point out a problem but there are infinite number of ways to address the problem for that a designer—at the end of the day the designer is always trusting their gut, their gut feelings maybe supported by data and with the help of UX researchers that gut can be inspired or directed but not dictated to. Moreover poor quality data (bad sampling, asking the wrong questions, naive or inaccurate analysis) can have a detrimental effect on design. [2] A leading UX researcher once said, tell me what you want to prove and I can design a research protocol to prove it. 

2. UX has an ROI and that is it’s sole reason to exist. 

DISAGREE — Software development is one of the most complex activities. It requires work from many different backgrounds, domains and resources. Their success is inevitably a sum of their parts rather than the isolation of the whole. Are there instances where an improved UX appears to have had a positive effect on the success of a product? No doubt, but that can also be said of good product management, good engineering, none of which operate on an ROI so why should UX? UX has more vital role than improving a company’s bottom line it is what a company is really about to the end user. 

With so many competing interests and stakeholders in the software or digital product process, trying to prove an ROI on just UX is dubious at best. Instead the argument should be that UX is an essential part of the product just like the code just like marketing and just like the sales. [3]

3. You know what a great User Experience is when you see it.

DISAGREE — A user experience is intangible and abstract. You cannot see this thing; it is based on visuals, behavior and user perceptions. Without knowing those elements you cannot judge a UX full stop. So get off your hobby-horses! The UX award shows are mostly shams and temples to charlatanism.

4. I weight positively a UX resume that shows a lot of experience and impressive UX titles.

DISAGREE — It is possible to be a total failure at UX and inhabit all kinds of responsible UX positions for major and minor companies. Since very few people understand UX, the chances of any engineering-driven company giving out meaningful UX titles are very low. When evaluating a UX title you need to do your research and see who bestowed the title; was it simply a manager? a Vice President? Who they reported to will tell you a lot more than their title. As to a UX resume, the gobbledy-gook in them should set expectations for what the prospect will be grilled on in an interview. None of it should be taken for granted. Saying does not make it so. Read your Descartes.

5. I consistently follow the most trendy or popular UX methods or tools. So-called timeless ones are too academic.

DISAGREE — Popular methods can never compete with timeless ones. There is a reason why they are timeless. [4] There are all sorts of sketching techniques, user research ideas and entire design ideologies, like Lean Startup, that have specific applicability. When looking for the right design tools, check out case studies and see how these tools work or do not work in your situation. Case studies that are simply “we came, we saw, we conquered” without exposing any of the involved trade-offs are useless. Our profession is nothing if not trade-offs and only timeless design methods will really get you to make the right ones. 

6. I can judge a UX portfolio by looking at it.

Disagree — By looking at a job applicant’s portfolio you are reviewing the work of the visual design’s initial impression, which may not have been a primary consideration in the design at all; moreover, you have no idea:

what role the applicant may have played in that design

what their achievements were,

what the ambitions of the project were,

their inter-team dynamics,

their design rationale, etc.

I think most people in this room would be astonished at how many even seasoned “Experienced” Charlatan UX Managers there are. I have observed many a hiring committee in many different companies and I have been appalled at the ease with which these charlatan glance at portfolios and quickly judge whether the candidate is a great candidate or not, even when the role was researcher, interaction designer, visual designer, or UX designer. The result has been mediocre and arbitrary hiring practices that lead to mediocre teams, which further ruin our professional credibility.

7. I am intrinsically opposed to the formation of a generally (State, National or Domain specific) accepted UX certifying agency.

DISAGREE — Except for trepidation on the quality of the certification process, why should you be afraid to show off your skills and prove you are a certifiable worthy designer? As Dan Rosenberg once observed, you need a license to practice architecture, why not also UX?

Personally, I would love to see a study done on the thousands of people who were fired not because of errors in judgment but errors in UX design and data presentation, which lead them to make the wrong decision. Charlatans reign supreme when no one is minding the professional store and no objective information is gathered about a designer’s competencies, and in specific UX areas.

All too often, people are touting themselves as UX one man bands. This is unrealistic. Each designer has a specialty (IxD, VD, etc.) Designers should be certified – at the very least – in their specialties. However, if you have your suspicions about how a board would be comprised and what they would use to analyze and certify applicants, that is fair enough; if you know your profession so well, get involved in the certifying committee. I don’t like the image of a certifying authority being like the Guild Meistersingers, simply observing adherence to rules of the trade and not their creative application. However, I prefer that authority to the UX Charlatans who would rather think of our profession as a mystical exercise that defies objective evaluation, observation or accountability.

8. I can name what UX should own and be held accountable for.

Agree — You must want to be held accountable to the design and its implementation. Even if in your current organization, you are not accountable, you should still be able to articulate the accountability as a desirable goal. Among the things you can mention are:

1. Accountable for the design concepts

2. Accountable for quality and effectiveness of all UX artifacts

3. Partner in the Development process, not a service

4. Empowered to log high priority bugs against bad UX implementations, which warrant high priority 

9. Aesthetics drives the UX, consequently, someone with a good aesthetic sensibility can naturally create a great user experience? Top designers know the profession in their gut and between their ears.

DISAGREE — Aesthetics can be surprisingly of little relevance because they are mostly subjective, except when they are based on the user’s aesthetic sensibilities, not the designer’s. Design rationales should rule the top priority design decisions instead of pure matters of taste. There should also be a reason for every ‘gut’ level design decision that the designer makes even if the reason is a simple design guideline important to the product, such as Fitt’s Law. You should be able to argue to defend your overall design with objective data and when disproven or in doubt should be courageous enough to change your mind. Great designers often have great instincts, but great designers use more of their brain than just their instincts. Incredible guts are only half the story as the difference between guts and gall is a thin line, without objective arguments. [5]

10. Agile and/or lean startup are design methods.

Disagree — These are software engineering methods. UX charlatans are constantly coming up with books, articles, and cults that conflate software engineering with design. The two have little to do with each other, except that they need to be scaled and coordinated with each other. If software development scaled to UX, instead of the other way around, there would be many fewer unsuccessful products. But that would assume there exists sufficiently competent designers and developers to trust in a real iterative design and development method. [6]

All too often, charlatan UX’ers use agile or lean as an excuse for turning in shoddy work they can ‘fix later’. Agile, as commonly practiced, is largely nothing more than incremental waterfalls, and lean startup—again as practiced—is for people who only vaguely know what they are doing, Anorexic UX would be a better title for what they practice. Neither Agile nor Lean is an excuse for UX to turn in substandard work. I have never met a developer who can output code faster than a competent designer can paint pixels or generate a prototype. [7]

11. I believe engineering or development is the most important aspect to creating successful digital products.

Disagree — Software Development is not the most important factor in product development. There are others equally important, all of which are essential parts of the digital solution: UX, Product, Business, etc. The digital solution process (software, services or digital products of any kind) starts well before development, with an idea. The process also ends with development taking a back seat to marketing. Moreover, most of the time the product is successful because of the team approach, not because of the software engineer as hero.

12. I can sum up what a User Experience does in a short succinct sentence or two.

Agree — If you cannot sum up what you do every day of your life for work then you have no idea what you are doing. There are many ways to define UX. Whatever way you pick, it is a statement of your vision of the great user experience.

My particularly favorite definition—among many possible—is: User Experience designers take products that force a user to think like a computer and turn them into products that mimic the way their users think. The UX Charlatan has no idea what User Experience is.  They resort to a mish-mash of visual models, abstract visualizations and a grab bag of jargon where the recipient is none the wiser, which is the hidden agenda of the charlatan: obfuscate so they can just do whatever they want and call it good.

13. I can name three books on cognitive psychology that I have read, relevant to user experience.

Agree — if you do not understand basic tenets of the human brain, you have no business being in this profession. You do not need to be a cognitive psychologist, and in many cases I prefer that you aren’t; however, in the list of books below that you should have read I include some popular titles as well as scientific tomes, so there is really no excuse.

• The Psychology of HCI by Stuart K. Card, Thomas P. Moran, Allen Newell
• Designing with the Mind in Mind, by Jeff Johnson
• Why we Make Mistakes, by Joseph T Hallinan
• How We Decide, by Jonah Lehrer
• The Design of Everyday Things (original title was The Psychology of Everyday Things) by Don Norman

Some designers with no inkling of what Cognitive Psychology is claim that you do not need to be a psychologist in order to design. I will actually go out on a limb and tell them they are wrong. So much of what we do as designers is based on psychology: Cognitive, Gestalt, and Social all playing an important role, whether we know it or not. So, if you know what you are doing instead of intuiting it you are, by definition, a more professional designer. 

14. Excluding Steve Jobs or Jonathan Ive, when asked who is my favorite designer, I can name a designer as well as their lasting artifact of digital design excellence.

AGREE — I cannot tell you how many job interviews I have suffered when a potential candidate names as their favorite designer either Donald Norman or Bill Buxton. Mr. Norman has never claimed to be a designer. As for Mr. Buxton, when I ask the candidate what Mr. Buxton has designed that they love so much they cannot tell me. Other people great and small have also been named but, surprisingly, rarely is there a design heavyweight with a proven track record—because most of us wouldn’t know one if we saw one, nor know how to recognize them or their outstanding products. [8] This situation is understandable given the non-transparent nature of our industry, the lack of personal acknowledgment for the designer for anything and most organizations’ allergy for UX accountability.

15. Without objection, I work on projects I do not believe in, it’s a job afterall.

DISAGREE — It is alarming how many consultants and even UX internal employees gleefully perform jobs they know are senseless. I have seen many famous consultancies do absolutely schlock work. When confronted about that, they reply, “That’s what the client wanted.” Employees also do work they think is meaningless, just shrugging their shoulders, “That’s what management wants.” Now sometimes you have to do work you do not agree with, and certainly you should pick your battles. But wasting a quarter of million dollars in a project doomed from the start is morally reprehensible, especially when the due diligence was not done to change the direction of the project into a professionally responsible direction. If consultants work with in-house UX teams, or employees work with their internal stakeholders to change the direction of a project and management still goes is a direction the designer does not agree with, then the matter is one of personal ethics not charlatanism.

16. I believe that only designers can come up with good designs.

DISAGREE — You impoverish your design thinking when you restrict yourself to the ideas that only you or your UX colleagues generated. A real designer does not fear great ideas from developers, product managers, marketers, etc. Rather, the designer learns to embrace these ideas and learn from them.

17. I am specialized into a single domain.

Disagree — A designer who is specialized in just consumer Electronics, or medical e-commerce, or mobile music apps, or enterprise analytics software, or … (fill in the blank) are usually the most inflexible and unimaginative designers around. They tend to see things from a single perspective – the mainstream of the domain – which in turn leads to failing to see problems that others with a fresh pair of eyes can see. These UX Charlatans have, at best, mastered trial-by-error (woe betide the early employers of these guys) a single domain’s challenges and learned by rote how to solve problems by what worked in the past, instead of analyzing the situation and coming up with a fresh new idea. My most engaging work was often my first foray into a domain, or the first foray back into a domain after a long absence. In both cases I had fresh eyes able to learn and apply lessons from other domains. Another good example is how all the specialized mobile designers of Erickson, Nokia, Motorola, etc., failed not only to produce the iPhone first but even failed to come up with a credible answer to it.  It took another non-phone company, Google, to do it.

18. I am specialized in a single set of design tools.

Disagree — A good designer is open to learning new skills and techniques. This often means adding new tools to your list of trusted tools of the trade. I am not against anyone having a favorite tool, but one should still be open to see if other tools might be more suitable for a given project. One should also be flexible enough that if required, you could design in new tools you have not previously used. The UX Charlatan is a one trick pony, like to a hammer all problems are a nail. [9] Conversely it is also true that organizations should not force a specialization in a single UX tool, but rather in a set of UX deliverables for their projects (but that’s a different topic).

19. No one really understands UX design. It is best if I can go off and just do it without interference from engineering or product management. Then just show them what a good job we can do.

DISAGREE — The best way to impoverish design is through walling yourself off from your product development team, and, by far the worst offense of UX Charlatans is not being transparent with your product teams. Walling yourself off means just going off and designing, getting feedback from stakeholders and then iterating in isolation from other team members. Lack of transparency means hiding the design process, your decision-making rationale, and your design activities from stakeholders. Stakeholders should be enabled to manage and assist you better if you are up front with your process and planned activities. You should also be upfront regarding what deliverables or outcomes will result from these activities and their trade offs if you need to compromise This empowers everyone to come up with a workable and understandable UX plan. Lastly, by iterating in isolation, instead of in participatory, collaborative or interactive design sessions, you mask your lack of knowledge or skills at the expense of getting essential feedback from other stakeholders. 

20. When designing, I show multiple and significantly alternative concepts.

YES — Just presenting a single UX solution and getting feedback is more an engineering than a design exercise. While appropriate for developers, for designers iteration must involve interactive collaboration as well as the use of multiple design concepts and synthesizing them into a single unified concept. This allows you to include innovative ideas you would not otherwise have considered.

Quick Summary Results Table

Question Answer Reply

1 Disagree

2 Disagree

3 Disagree

4 Disagree

5 Disagree

6 Disagree

7 Disagree

8 Agree

9 Disagree

10 Disagree

11 Disagree

12 Agree

13 Agree

14 Agree

15 Disagree

16 Disagree

17 Disagree

18 Disagree

19 Disagree

20 Agree

Total

X5

SCORE

Table 1. Answer sheet for the quiz. How well did you do?

In Summary Table 1 displays the answers to the quiz. Add 5 points for every correct answer. Give yourself an honest score. Please do not tell anyone what it is; this only works as an introspective reality-check that only you need to enjoy. Moreover, if you are a charlatan chances are we know that already. But cheer up, as I said – you are in good company in this profession. However, given your results, does the looming possibility of a universally accepted UX certification board make your tremble or shout with delight. 

Conclusion

The purpose of this exam is an introspection for the benefit of our profession. I hope people undertake this test honestly in their hearts and let it serve as a guide for where they may wish to work on their profession in order to become less and less a charlatan and more and more a professional.

For those who wish to hire UX professionals, I hope this quiz can also serve as a guide to ask questions that will lead you to a competent candidate. Let me just repeat what this paper is not: this paper does not single out any single company or person. I mean to accuse us all and almost without exception. There is no one company, organization or designer more culpable than another. My observations cover the work of many colleagues in many companies for whom I have not worked. So everyone should feel equally distressed.

ACKNOWLEDGMENTS

There are also many non-charlatans: designers from whom I have learned and by whom I have been inspired. I am also blessed to have known many excellent UX Managers with whom it has been a privilege to work, and who have helped me grow out of my own charlatanism. My professional persona is also a sum total of the amazing product managers, developers, marketers and the occasional CEO it has been my honor to know. To all of them I am greatly indebted and without whom I could not have made these hopefully pithy, wise, and (for those who can appreciate such things) humorous observations. I think I do them a greater favor by not mentioning them here.

REFERENCES

1. Priester, Ruurd, Arnowitz, Jonathan , Willems, Eric, Faber, Laura, Mahler, Mondriaan, and Bauhaus: using artistic ideas to improve application usability, DIS '97 Proceedings of the 2nd conference on Designing interactive systems: processes, practices, methods, and techniques, Pages 12-21
2. Albert, Bill, Tullis, Thomas, Measuring the User Experience, Elsevier Books book 2013, this book covers  many different ways data can be collected and analyzed.
3. Rosenberg, Daniel, The myths of usability ROI, interactions - Volume 11 Issue 5, September + October 2004, Pages 22-29
4. Arnowitz, Jonathan and Dykstra-Erickson, Elizabeth, Masters of our process, interactions Volume 14 Issue 5, September + October 2007 Pages 56-ff.
5. Mackay, Wendy, Dykstra-Erickson, Elizabeth, and Arnowitz, Jonathan. Perspectives: trialogue on design (of) interactions, Volume 8 Issue 2, March 2001 Pages 109-117
6. Arnowitz, Jonathan Taking the fast RIDE: designing while being agile, interactions Interactions Homepage archive, Volume 20 Issue 4, July + August 2013, Pages 76-79
7. Enter the chief design officer! hail to the chief! interactions - Volume 14 Issue 4, July + August 2007, Pages 56-ff
8. Arnowitz, Jonathan, Arent, Michael, Berger, Nevin,  book, Effective Prototyping for Software Makers. Morgan Kaufmann Publishers Inc. San Francisco, CA, USA ©2006

Excel Protptyping Templates

A long time ago, in a galaxy far far away, I co-authored a book with Nevin Berger, Michael Arent and Fred Sampson on Excel Prototyping for Software Makers. Yes, really using Excel as a software prototyping software. It is still a good idea, although the version of excel have evolved so it makes the book not as helpful as it once was. Nevertheless, for some people look for a simple fast prototyping tool Excel is still attractive for some.
There even seems to be renewed interest in our book: http://www.amazon.com/Effective-Prototyping-Excel-Interactive-Technologies-ebook/dp/B003FK5PWA/ref=sr_1_3?ie=UTF8&qid=1391438838&sr=8-3&keywords=excel+prototyping. Unlike the book link on the left this one will make me no money via Amazon, which is only fair since the book is dated and no plans are made to update it.
The problem with this renewed interest in our book is our web site has died a slow painful death. The web site is where we made our prototype templates available.
So to facilitate a place to get these templates, I am posting them right here, enjoy:
https://drive.google.com/file/d/0ByaeNqsDdjGXQVNwbXl4UjQwUEE/edit?usp=sharing
If you have any problems downloading post a message here, but please be polite.
Lastly, I am using Google Drive so if you have a problem with the way Google Drive works that's not an issue I can solve.

Taking the Fast RIDE: Designing While Being Agile

A new year and a new post in my less than active blog, here is an article that originally appeared in interactions magazine.

While many design methods are practiced “in the wild,” the most prevalent one appears to be “Design first and ask questions later”—also known as “Throw it over the wall and see if anybody salutes,” “Launch first, fix later,” and so on. Whatever you call them, these approaches are all responses to the pressure for rapid turnaround man- dated by Agile and other high-speed development environments. These design approaches are all proven methods—that is, proven to create Frankenstein UIs within a mere two to three iterations: That’s speed.

A single-minded focus on speed guarantees that these methods produce poor user experiences, because they do not allow for the reflection and deliberation necessary to achieve high-quality, coherent design. Instead, speed breeds pragmatic short-term solutions. An interaction style gets locked down in the early sprints. Then other ad hoc interaction styles emerge for parts added later. Too much emphasis on reactive speed reduces design to puzzle fitting: How can I put this new square-peg function into my round-hole application?

I am concerned that in an attempt to adapt to the pressure for speed, designers are failing to uphold what we know is good design practice. We compromise too much of the interaction strategy y in order to “ just get down to it.” The end result is competing styles, competing imagery, and unintelligible system/conceptual models.

Agile and the Emperor’s New Clothes

How do you get out of this cycle and still survive in the context of fast Agile or pseudo-Agile (aka reckless) release cycles?

This question may sound odd, coming after years of our learning to live in Agile environments. Agile’s true believers may argue that the whole point of Agile is not about producing speed, but instead about creating a structured process to produce high- quality results in the face of the pressure toward speed (which Agile itself did not create).

But there are obvious incompatibilities between Agile and the needs of good design practice. Unfortunately, an emperor’s new clothes mentality has developed in which it is not acceptable for user experience people to point these out. Instead, we become mock up

monkeys scurrying to meet the next sprint deadline, throwing in features and widgets at whim.

Part of the problem is that Agile’s own best practices are often not followed—for example, and most important, the regression testing, which introduces some flexibility in Agile software development. People tend to claim that Agile is iterative, but without regression testing, it is too often practiced in a piecemeal manner, wherein once something is developed it cannot easily be changed. This makes the emerging Agile practices look a lot like an incremental Waterfall development process. Once sprints begin, the train has left the station. You are then stuck with design decisions made at Sprint 0 or 1, with little ability to iterate on basic concepts.

Perhaps you have heard statements like this or experienced things like this in Agile environments:

• Sprint 1: “Designer, just do something, anything, right now so we can get some feedback—we can always change it later.”
• Sprint 2: “Designer, sorry, we can’t make changes anymore—that would affect the back end.”
• Sprint 3: “Oh, we can’t do that because of lack of resources. You have to stick with your current design. Of course, you can always tack on a new visual design.”

As common and frustrating as this sequence of events sounds, the main point is not just that things keep changing; it is that the serial structure of Agile sprints, which may make sense for engineering, does not fit for design. Often with the best of intentions, designers are either too lazy to push back or intimidated into thinking serially instead of conceptually. This fundamental mistake causes poor design.

Design does not proceed by dividing a complex problem into parts and then working on them sequentially. Design is more of a layered process, moving from broad concepts to devilishly (or heavenly) detailed design. Broad design concepts, overall IA, and key interaction models need to be established first. This conceptual design then guides the detailed designs. Then, as this detailed design progresses, some detailed decisions may fracture the existing overall concepts, showing their limitations. This speaks of the need to supply feedback from the detailed design work back to the underlying conceptual layer.

Establishing a successful conceptual design calls for intensive collaboration between designers and researchers. I would advocate (hence my article’s inclusion in this section of interactions) that in Agile environments, designers and researchers need to be joined at the hip more than ever. They need to work in close concert in order to be as strategically and tactically “agile” as possible.

What About RITE?

Rapid Iterative Testing and Evaluation (RITE) is one of the main ways of trying to incorporate an iterative user-centered design mind-set into an Agile development process. It also joins research and design by coupling testing with quick design revisions. (See Medlock, M.C., Wixon, D., McGee, M., and Welsh, D. The Rapid Iterative Test and Evaluation Method: Better products in less time. In Cost Justifying Usability. G. Bias and D. Mayhew, eds. Morgan Kaufmann, San Francisco, 2005, 489-517.] for more information on RITE.) RITE does ensure some feedback from testing into design. However, in my observation, it does not address the mismatch between Agile and good design practice.

RITE is too reactive and tactical; it also does not address the need to support early, deep design work. It actually separates the testing activity from the interaction design activity by fragmenting the team, and puts both design and research in a reactive, entirely tactical mode. I have seen teams where the usability researchers are consumed with scrambling to plan and set up a test of features on parts of a couple of pages.

Meanwhile the design team is moving on to design some other part. Soon the usability researchers are scrambling equally reactively to test features from the next pages under development. The result is that no one ever evaluates the overall concept or architecture, or even the contextual fit of the application as a whole.

RITE’s testing-led approach to design improves design incrementally. There is nothing inherently wrong with this, as long as one is testing the right things. Unfortunately, this practice will never lead to that, especially as testing will tend to focus on what is being worked on in a given sprint. RITE also can lead to a kind of tyranny of testing.

Testing is an important evaluation technique. But a good researcher knows to mix a cocktail of different evaluative techniques to come up with a far richer view of the system and its user. RITE’s pragmatism never gets to the level of sophistication needed for a holistic design evaluation.

The RIDE Alternative

There are better ways. In this design-hostile environment, I advocate a design method I call Rapid Iterative Design and Evaluation (RIDE). In addition to rapidness, it emphasizes inter play between design and research, beginning with conceptual design, where every evaluation is not necessarily a test. The method also allows for alter native evaluation methods for specific iterations. Moreover, it includes partnering with engineering and product management to rapidly work through multiple concepts. This allows the team to identify the backbone of concepts. These backbones (as opposed to key user stories) get developed/ evaluated first. This places UX strategic design decisions up front, where they belong. While these strategic decisions are still made in the context of a sprint, RIDE respects the need for the layered design thinking needed to design a system holistically.

RIDE strives to do this by:

• encouraging the design team (by which I mean to include ever y- body with design input—interaction designers, visual designers, user experience researchers, and, yes, even engineers) to work faster through collaborating rather than working in isolation;

• respecting the best practices of UCD/HCI/design; and
• encouraging the development and evaluation of multiple design concepts at each stage.

The main ingredients of RIDE are:

• Understanding the product context
• UX Planning—establishing cross-disciplinary collaboration
• Defining UX goals
• Rapidly generating and evaluating multiple design concepts
• Holistic iteration.

The first two steps here belong in the product-definition phase before the sprint cycles begin. Since Agile promotes fragmentation, a holistic view of the product should first be developed. Unlike a traditional UCD project, the concept is developed in broad strokes, leaving the further definition to the sprints.

Understanding product context 

Understanding product context— taking time to understand the users and usage context.

The product context is an essential element in the definition of the product. This effort, led by product management, includes development, design, and research. It helps clarify the product landscape, the users, and their environment. Design helps to visualize this definition through the rapid sketching of multiple concepts. These concepts are done quickly and iteratively, as more and

more information is gained about the product. The end result is a basis for a product requirements document (PRD) and two to three credible alternative UX directions.

UX planning

UX planning—establishing cross- disciplinary collaboration at each phase.

Design and research create a UX plan, which is meant to span the design and sprint iterations. The plan anticipates the possibility that some research and design

activities stretch over sprints. This is the strategic plan to achieve

the design goal of the product and includes identifying the types of evaluation, research, and design activities that will take place and when. Again, this plan does not follow sprint planning but will take it into account. After every sprint, the plan can be reiterated based on the usually unexpected outcomes of the sprint.

The RIDE UX plan also creates the possibility for each stakeholder to influence, guide, and inspire the design at all levels. RIDE acknowledges that design is not done in a vacuum. The more isolated it is from other disciplines, the more discontinuity and signal interference will arise in the UX. Rather than separating UX design into individual sub-disciplines (visual, information, interaction, engineering, product management, and other stakeholders), these all need to work together, because each part of UX design informs, feeds, and inspires the others.

For example, there is nothing to prevent a researcher or engineer from coming up with a great interaction design solution. Nor a designer coming up with a better analysis of the data. Quite to the contrary—combining their differing perspectives almost guarantees new, innovative ideas. We need not be afraid of a plethora of ideas. Some designers in fact fear engineers making design decisions. Yet if the developer is in tune with the larger design concepts, the chances of their having a good point are significantly increased over when they do not. And further, good designers should be able to defend and persuade stakeholders of the value of their designs; otherwise they might have to face the possibility that they may be wrong.

Outside of these core stakeholders, there is another equally important outer circle. These people include anyone who is taking vital interest in the user experience

and has the power to influence it for good or evil—anyone from developers to marketers to CEOs. Without cultivating their support from the beginning and working to keep them on board, you risk having progress derailed later by random changes of direction. In this planning phase, one should engage them early and on the most abstract level they can stomach: product definition. Get them to wrestle with the big conceptual design choices before development starts. Support from them also strengthens your mandate to execute on the concept.

Of course, nothing guarantees that the CEO won’t insist on purple buttons late in the game; however, in an Agile environment, this is less likely to happen if the stakeholders are on board when the conceptual train leaves the station.

Without this plan, you have to find some way of dealing with these outer-circle UX inputs. Research may give you a chance to resolve design debates objectively, but the Agile timeline typically does not allow for this. The best defense is to make them partners proactively in the design process. Include as many stakeholders early on in brain- storming sessions where the conceptual design is worked out.

Defining UX goals. 

Before the beginning of a sprint, it is important to establish the UX goals. These goals require four types of iteration: product definition, conceptual design, detailed design, and evaluation activities. I don’t mean to suggest that these are serial types of goals; rather, they are all interconnected. In the early sprints, the accent may be on product definition, moving to conceptual design. But even these should be done in service of the detailed design. This way, activities do double duty: iterating the practical short-term goals and informing /evaluating the strategic longer-term goals.

These goals are also planned along three time scales:

• The project end—progress to product release

• The current UX plan timeline— the current planned and ad hoc UX activities

• The current sprint—a time snapshot of the current state of the UX goals.

Rapidly generating and evaluating multiple design concepts.

Designer and researcher work on a coordinated effort at designing, evaluating, and then iterating during the sprint. Many parallel activities are driven by the design strategy, not by a reactive “test and see what happens” approach. It is much different from RITE in that the UX goals will determine the strategy for the sprint. The evaluations may or may not trigger reiteration; they may just inform. They can also split off another design variation for exploration. This depends on the agreed-upon evaluation activities: Are they formative or evaluative? Are they abstract or concrete? Will they help find a synthesis among competing ideas? Researcher and designer are partners in this effort. In parallel, longer and different activities (focus groups, interviews, cognitive walk-throughs, etc.) are being done to triangulate with data from other evaluations.

Holistic iteration.

This involves evaluation at the strategic level in parallel with detailed design. Detailed designs sometimes will trigger refinement of the conceptual design and vice-versa. Moreover, evaluations can touch visual, interaction, information, and system design issues— one cannot predict which. Therefore, many design disciplines involved can lead to vastly different results. For example, when a particular design tests poorly, an interaction designer might change the interaction. A visual designer might change typography, colors, and so on. This leads again to incremental and non-holistic revisions. Real iteration would involve these different design disciplines and find ways to distribute the answer among all the design elements, thereby coming up with a far more robust iteration. Holistic iteration also means assuring the deliver y of what engineering needs to meet their goals and their management objectives. Meeting this need will, of course, mean trade-offs on design. This is why having engineering in the core team is essential. Any development method that ignores or frustrates the engineering team’s management goals will fail.

Conclusion

RIDE is a richer design methodology because it leverages a collaboration of all stakeholders. It encourages exploration through a reliance on multiple design options that are synthesized, as opposed to a single option that is puzzle-fitted with additional features. RIDE seeks to find a holistic solution for Agile design and development, not just a tool for rapid changes to a single concept. But most important, it tries to find the right way for design (interaction, visual,

and information) to work with researchers: joined at the hip. It also requires strength and energy, because--as with any quality UX--there is no free RIDE.