What kind of Jew will you be?

Today our electoral college, our last line in defense of fascism will officially elect a fascist dictator to the US presidency. Our country is on the precipice of its final destruction as a democracy. An authoritarian regime is about to take over. One so completely divorced from democracy that they currently aim to harm the very people who elected them. So does this mean we are doomed? No. We can descend into fascism, but we can also descend into chaos. Or we can repeat the last 8 years and descend into gridlock with a bad taste in our mouths. Nevertheless we should be prepared for the worst. It leads me to contemplate the fate of the most vulnerable for they will surely bear the brunt. Time has taught us that the ‘vulnerable’ are not the poor or the downtrodden they are the ‘different’. Think your wealth will protect you? I am sure the rich Jews of Germany thought exactly the same thing. So using that analogy, if this were Nazi Germany (and it very well may be) what kind of Jew will you be?

There were Jews who disbelieved in what was happening. Surely this cannot happen here? They cried to themselves even as they were being herded onto trains, to experience exactly what they could not fathom. These were the believers in civil society, the believers in institutional safeguards. The vast majority of the 9,500,000+ Jewish population (https://www.ushmm.org/wlc/en/article.php?ModuleId=10005161).

There were Jews who desperately tried to escape. Some succeeded and went to another country where they could get on with their lives while the rest of Germany crashed and burned. Of those who escaped not all fared well. Many were miserable refugees, some, like Stefan Zweig and his wife, committed suicide, and yet others found they had not escaped far enough like Anne Frank’s father Otto who escaped to Amsterdam only to be captured there and sent to a concentration camp.

There were also those Jews slow on the uptake. “Oh my god, this is really happening!” they would realize in various degrees of too late. For these Jews a dilemma came up: they had to fight their fate but how? Some went into the underground. Some went into hiding. Some tried marrying Aryans (some 4,700). Others tried forged papers, and even went so far as to fight in the army for the Germans.

There were also the apathetic, the apolitical, the ones with their heads in the sand or up their ass. They simply reacted to consequences as they appeared. They went into hiding when kicked out of their homes. They stole food when they were deprived of money. They were shoved into lower and lower levels of pragmatic survival. (about 1,400 of these survived living in Berlin throughout the war). (http://www.holocaustresearchproject.org/nazioccupation/berlin.html)

Then there were these special class of Jews, call them delusional, call them the elites, call them the traitors. They thought working with the Germans would be the way to help attenuate the circumstances. They enjoyed privilege for so long they were useful to the Germans. They gave an air of legitimacy for the fellow disbelievers that it really wasn’t so bad. Their leaders after all would protect them. But nobody could protect them. Even this Jewish elite, somewhat serendipitously called in German the Jewish Rat, could not protect them nor themselves. (http://www.jewishvirtuallibrary.org/jsource/Holocaust/judenrat.html They were actually called the Judenrat or Jewish Council) Though some did abuse their ‘privileges’ to help their friends or themselves, others wanted to only to find out that wasn’t so easy. They ended up helping the Nazi cause more than they ever hurt it. Of course these Judenrat members did not find these jobs very cushy and were often subjected to the same intimidation, torture and murder as the others. And to be fair, many were forced into the Judenrat, I am referring to those who more willingly participated in them thinking they could reform the Nazis from within.

Then there was those Jews who opposed the system from the very beginning. They became the easiest targets of retaliation and often used as symbols of the impending martyrdom to follow. They certainly died with clear consciences. They raised awareness. They disabused the disbelievers, allowing many of them to take action. Many of them won credibility among the underground and as resistance fighters often got free passes from the underground to safer ground. That was surely the fate of Victor Lazlo, the secondary hero of Casablanca.

So the question remains. Given on impending Trump presidency: what kind of Jew do you aspire to? Or are you confident this can’t happen here, and certainly not to you?



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.


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. 


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




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. 


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.


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.


  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:


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.


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.

Prototyping 3: What is a prototype, part 2 other dimensions

In Part 1 of what is a prototype we discussed many dimensions of what a prototype is, but this covers only part of the story, actually half there are many more layers of complexity and if you do not understand them, instead of controlling a prototype, the prototype will control you or worse victimize you. So let’s begin with some prototyping characteristics, for lack of a better term.

Prototyping characteristics

Prototypes have many more important characteristics than just content and fidelity. Knowing what these characteristics are will also help you plan and execute the prototype to the right level of effort. Too numerous to name them all here, here are just a few examples:

Longevity — what is the lifecycle of the prototype. Is it something to be presented and thrown away, or is it part of an evolutionary prototyping design cycle? How long a prototype will continue to haunt you, should effect how much effort you are willing to put into it.

Stage — what stage of development is the product? Usually, the more mature the more detailed the prototype should be.

Speed — how much time do you have? If you have one week, it probably isn’t enough time to make as thorough a prototype as you would like, you may have to adjust your content-fidelity ambitions based on how fast you must work.

Style — will the prototype be narrative (e.g. demo’d) or interactive (e.g. used). Interactive prototypes are more difficult and time consuming than narrative ones.

Medium — will the prototype be in a digital media or physical, if digital will it be on the web, mobile or a desktop application, etc.

Being aware of the characteristics of a prototype, empower you to make much more professional judgement as to what kind of prototype you can make.

Defined audience (s)

Audience — who is the the prototype for? Unlike the end product which is meant for an end user a prototype is meant for certain stakeholders, which may or may not include end users. The prototype should be designed to communicate clearly with the stakeholders. For example, this usually means that a prototype meant for the CEO of the company, will probably look different than a prototype meant for a domain expert

Prototyping tool(s)

Prototyping tools are like tools of the trade, the more you know the better. Likewise for many the simplest software tools suffice for most purposes.

There is no one single prototyping tool that can do everything. Prototyping tools are as varied as there are types of prototypes. Prototypes can just as easily be made in Excel, Powerpoint, Visio, even Word as they can be made in Axure, Dreamweaver, Visual Studio etc.

The point is to match 2 things: First, match the prototyping characteristics with the right toolset. Secondly, of those tools, use the tools you know best. Chances are, your talents in software you know well will outstrip the added functionality of other software tools.

Personally, I no longer use a single tool, but quickly jump between Graphics editors, html editors, scripting tools, layout tools, and yes the occasional prototyping tool.

…but having said that there are some types of tools

  • dedicated prototyping tools
  • Programming tools with prototyping capabilities
  • graphical tools
  • layout tools
  • presentation tools

Dedicated prototyping tools, tools that are only for the creation of prototypes not working software or any other purpose. Examples:

  • Axure
  • Denim
  • Balsamiq

Programming tools with prototyping capabilities — tools that can create full functioning software, but due to their efficient interfaces can allow users to also create prototypes. The theory, or rather myth is if a designer uses one of these tools, a programmer can take over the design and implement it without recreating it. This is rarely true as the html code, or programming code used by a designer (focusing on visualizing something) is completely different in nature to that of a programmer (focusing on implementing something). Examples:

  • Dreamweaver
  • Visual studio
  • Flash

Graphical tools — tools that help you create the visuals of an interface, ideal for wireframes. Sometimes these tools can also mimic interaction making them suitable for a variety of prototypes. Examples:

  • Photoshop
  • Fireworks
  • Paintshop pro

Layout tools — tools that help you layout content. Sometimes these tools include interactivity such as hyperlinks or programming scripts that help create a variety of prototypes.

  • Word
  • Pages
  • Excel
  • Numbers
  • Visio/OmniGraffle

Presentation tools — tools that have some built in narrative capabilities that make it particularly (though not exclusively) suited for narrative prototypes.

  • Powerpoint
  • Keynote
  • Acrobat


Prototyping is much more than just wireframes or a ‘dumbed down’ version of real software. The Methods are many, and in addition to the methods below, there are all sorts of hybrid methods which combine features of other methods. Just to give you a flavor here are some examples of some of my favorite methods:

    • Wireframe Prototyping — A wireframe is a narrative prototype, usually created in the beginning of the design process. This prototype shows high-level sketches, visualizing conceptual assumptions about the product structure and general interaction.
    • Storyboard Prototyping — A storyboard is a narrative prototype, usually created in the early stages of the software-making process to articulate business and marketing requirements in the form of a usage scenario or story. These stories narrate the user actions needed to perform tasks as specified by marketplace, customer, and user requirements.
    • Paper Prototyping — A paper prototype is an interactive prototype that consists of a paper mockup of the user interface. The interface is usually fully functional, even if all the functionality is mocked up on paper. Paper prototypes allow you to test a design with many different stakeholders, including end users.
    • Digital Prototyping — A digital prototype is an interactive prototype that consists of a digital mockup of the user interface. The interface is usually partially functional, even if the functionality is implemented by hyperlinking, screen switching and other methods of mocking up actual interaction. Digital prototypes like paper prototypes allow you to test a design with many different stakeholders, including end users. Unlike paper prototypes, digital prototypes can be tested remotely.
    • Blank Model Prototyping — Blank models are low-fidelity prototypes produced quickly by user study participants using readily available arts and crafts materials to represent their notions about what an intended hardware/software design could be like. This method is used in the early stages of product design to elicit user perceptions and mental models about hardware form factors and interaction controls in conjunction with a software user interface.

And with the prototyping methods that covers the definition of a prototype. Now was that so painful? Now you understand at least to some degree the richness of prototyping. Instead of being victimized by these dimensions you should be wielding them like a weapon. So hopefully know you can understand the basic concepts of effective prototyping: that a prototype is:

  • purpose
  • content
  • content fidelity
  • requirements and assumption
  • prototyping characteristics
  • defined audience (s)
  • toolset
  • method

If any of these concepts are still not clear, I can discuss them in subsequent postings. Next week I will discuss the so-called benefits of prototyping, which probably could better be labelled: the myths of prototyping.

Prototyping 2: What is a prototype

In my last post I discussed what a prototype does. Now here comes a far trickier question: what is a prototype. A prototype turns out to be quite complex, and rightly so. Because to get the benefits of prototyping (the subject of my next post), a prototyper must understand these vital concepts, otherwise you are just shooting arrow into the air.

A prototype is deservedly complex since it is by definition the coming together of many different disciplines. Whether you like it or not every prototype has an either implied or explicit:

  • visual design
  • interaction design
  • technical implementation
  • information design
  • editorial content
  • and my personal favorite: a reason to exist

But those are all vague terms and do not really help you get control of your prototype. And getting control is the point of the definition of a prototype that I want to discuss. This definition will provide you with everything you need to control your prototype, so it does not control you. Likewise, for you non-prototypers, this will also give you enough information to fight what I call the razzle-dazzle effect: a prototyper who over-delivers a slick prototype and uses the wow factor to cover up a paucity of good ideas.

To begin, we need a prototype definition that covers what are the parts that make up a prototype and not what a prototype does (that was covered in the last post).

The Effective Prototyping definition of a prototype

A prototype is a model of a design that is:

  • utilized for a specific planned purpose
  • illustrating specific content and fidelity
  • articulating defined requirements and assumption
  • specified with prototyping characteristics
  • customized for a specific audience(s)
  • created with a specific tool
  • performed in a specific method

Here is a less verbose but more specific version of the same definition:

A prototype is a model of a design with:

  • purpose
  • content
  • content fidelity
  • requirements and assumption
  • prototyping characteristics
  • defined audience (s)
  • toolset
  • method

Below we will discuss them briefly, for more thorough details, you can always consult the full book, Effective Prototyping for Software Makers .


A prototype will be created for a specific purpose. Whether it is a proof of concept, or a demonstration of a product’s interaction or a visual direction, it is important to know what the purpose(s) is (are).


Based on what the purpose of the prototype is, you will want to prioritize the content in the prototype.

A prototype consists chiefly of 4 different types of content:

  • Interaction — how a user will interact with it
  • Visual design — how the prototype will visually appear
  • Editorial content — what information will be on the prototype
  • Information Design/Architecture — what will be the structure of the information


Generally, only in late stages do you want the content all at a high fidelity. Consequently, a prototyper will strategically set the fidelity of any given content higher or lower depending on what they want the prototype to focus on. The higher the fidelity, the more prominent the content. The lower the fidelity, the more the content will fade into the background.

Setting the wrong level of fidelity is the most common error. It results in discussions getting bogged down on visual design, when in fact the interaction design was the only intended goal of the prototype.

Contrary to what most prototyping texts state you can play with fidelity within a content type. For example you can raise the fidelity on the visual design for the chrome of an application and lower the fidelity of the content in order to discuss the visual structure of a given. You can also de-emphasize a content type completely, for example by showing all text in greeked text format you for your audience to concentrate on the visuals or interactions instead of trying to read editorial content which usually grabs their attention.

However, the issue is more nuanced than it appears. For example, let’s say you want to test the interaction design. Then, if you set the visual design level to lowest and editorial content to lowest fidelity, it will be impossible to really test the interaction: you need just enough editorial and visual design content to test the interaction. Likewise, say for example, the visual design is already finished and agreed on by stakeholders, then there is no real reason not to use a high fidelity visual design.

In general, the rule is, lower the fidelity of the content you are both less sure of and do not want to evaluate. At any rate a professional prototyper should be able to justify their choices.

requirements and assumption

The whole point of a prototype, when used as part of a digital product or service creation process is to validate requirements, or rather separate the requirements from the assumptions. Requirements are some function or feature that is necessary for the success of the product or service. An assumption is something that is presupposed to be a requirement, but has never actually been proven or tested. A prototype usually consists of proven requirements, requirements to be validated in the current iteration and assumptions. In general, the higher the assumptions the more risky a prototype is. Whether something is a requirement or an assumption will help prioritize content and set its fidelity.

I see know the post is over 1,000 words, so let’s stop here and resume with prototyping characteristics next week.

Prototyping 1: What does a prototype do

A series on prototyping

In the 4 years since our book on prototyping first came on the scene there was precious little written about the professional way to prototype. Today prototyping seems to be the hot topic, unfortunately most of the current stuff available on the internet only give an isolated tip or trick. What is especially harmful is that most of these articles rush into how to prototype without really understanding what it is. These works are rife with unquestioned assumptions and and uncritical approach to prototyping.

The book I co-wrote with Michael Arent and Nevin Berger remains still the only thorough attempt to understand prototyping. In the coming series of posts on prototyping, I want to make a compact discussion of what a prototype is and how it works from our book Effective Prototyping for Software Makers . This post will it a little more approachable and if you want the full details, by all means you can buy the book

In this series of posts I want to address 3 broad topics:

  1. What does a prototype do
  2. What is a prototype
  3. Raising the bar in prototyping

In this first post I want to discuss what a prototype does. For that I want to use a definition of prototyping that restricts itself to what it does not what it is. For that I turn to a definition from the book “Universal Design Principles” by William Lidwell and others:

A prototype is “The use of simplified and incomplete models of a design to explore ideas, elaborate requirements, refine specifications, and test functionality.”

For ease of discussion, I will break this definition down into its components. First, I will throw out the models business because that goes into what a prototype is, which will be the subject of the next post. That leaves us with the following uses of a prototype:

  • to explore ideas
  • to elaborate requirements
  • to refine specifications
  • to test functionality

All prototypes attempt to do at least one of the above purposes and usually more than one simultaneously, often without the prototyper even being aware of it. What is essential to know is that the prototype is first and foremost a communication medium. A prototype communicates the above 4 concepts.

Explores ideas

Here the accent is on if the idea is desirable. Prototypes are at their best when they explore abstract concepts or ideas and makes them concrete. It is easy enough for a group of technocrats to discuss their new idea for a killer document registration, yet being able to both rapidly and interactively visualize with a prototype makes the idea come alive and often inspires and informs the whole ideation process. Any software idea can be visualized with a prototype. But here are just a few examples (a fuller list comes in a future post discussing prototyping content):

  • Interactions design
  • Application functionality
  • Visual design
  • Information design/architecture
  • Rough concepts and ideas

Among the many means of using prototyping to explore are:

  • a single prototyper visualizes the idea
  • a group prototypes through participatory design practices
  • members of a group each sketch out their ideas as a group
  • a group brainstorms a prototype with a designer as facilitator

Elaborates requirements

Here the accent is on, whether the prototype is possible. A prototype elaborates requirements by often illustrating what is necessary to actually put an idea into action. For example, and idea of having a running total in web interface when illustrated will make a developer realizes they need Web 2.0 technology. Or it could make the business analyst realize that discounts or other items that effect the total also need to be known upfront or somehow communicated to the end user. Once an idea is explored, software makers often look at a prototype differently. Among the types of requirements that are elaborated by a prototype include:

  • Business
  • Organizational
  • Functional
  • Technical
  • End user

Refines specifications

Here the accent is on, whether the prototype is feasible and if so how. One the idea is desirable and deemed possible, then the detailed design comes in. A prototype is often a superior form of specification than a large paper document with lots of verbiage where the requirements are difficult to ascertain let alone visualize. Furthermore, the prototype speaks in the visual language of the product itself and cross cultural and language concerns are not so big an issue with today’s global development teams.

A prototype can be stand alone documentation if it is a totally complete model. Otherwise, often some form of annotation or some lightweight document is needed to accompany it.

Tests functionality

Here the accent is on evaluattion, for example whether the prototyped design is usable for the end user.

A working prototype (paper, digital or whatever form) can be shown to stakeholders and they can test it to see if they can work with it. If it works the way it should or they way it needs to. This way corrections to the design will cost no redevelopment costs.


So in a nutshell, this covers what a prototype does. In essence it communicates four things:

  1. to explore ideas — is it desirable?
  2. to elaborate requirements — is it possible?
  3. to refine specifications — how do we do it?
  4. to test functionality — does it work?

How and what it communicates will be discussed in my next post on what a prototype is. In that post I will discuss the characteristic parts of a prototype. Understanding these characteristic parts allows you to control how your prototype will come across to your audience.