Last year, the short video “The Expert” went viral in tech circles. Depicting a comically frustrating meeting between a tech consultant and a client, the video is available with subtitles in 39 languages, has well over 10 million views, and has thousands of comments, many of them written by people saying they have been in similarly frustrating meetings.

We see a hapless technical expert asked by clients to build “seven red lines, all of them strictly perpendicular, some with green ink and some with transparent.” The technical expert tries to explain that the request is impossible, but is thwarted at every turn. His project manager and account manager are aloof and condescending and the clients grow increasingly more unreasonable.

One client passively aggressively asks such questions as “I’m sure you know what transparent means?” and the other piles on more outlandish requirements such as “When you inflate the balloon, could you do it in the form of a kitten?” The meeting ends in the worst possible way: with impossible tasks assigned to the expert and the clients expecting an impossible-to-achieve project outcome.

The popularity of this video speaks to the prevalence of the problem it depicts. Clients make an unreasonable request, the project jumps to the design phase during the first meeting, and the very next step is to start building. No one in the meeting asks about the users, who they are, what they need the product for, or what problem the product solves. The meeting is dominated by discussions of technical limitations. And no one present has the skills to drive the meeting to a conclusion where the next steps are clear and the client leaves with reasonable expectations.

Happily, for the most part, UX professionals are able to navigate the problems depicted in “The Expert.” They can help ask the right questions and map the way forward to achievable next steps.

In real-time however, even the most experienced UX designers can find themselves frustrated by stubborn customers making outlandish customer requests and so unpacking what’s really happening in the meeting depicted in “The Expert” and other meetings like it can serve as an important refresher. For experience design practitioners, understanding this difficult scenario from the client’s point of view can help us approach this very real and seemingly intractable problem from a fresh perspective.

Sharing Power

On the surface, “The Expert” is a funny look at the day-to-day struggles of technology designers, however, a deeper look shows that the video depicts a fundamental power struggle that exists in the domain of technology design. The video brings to the forefront such important questions as: Who has the final say over what technologies are designed? Who gets to decide what does and does not get built? And, most importantly, who is allowed to take part in design conversations?

Though the video seems innocent enough, it has an insidious central premise, which advocates that technology ideation and design should reside primarily with technical experts. By presenting a case where only technical people are able to understand whether the project is possible or not, the video argues that the focus of design conversations should be on technical possibilities, and technologists (who are the only ones capable of understanding the details) should be making the decisions.

The request the clients made for seven perpendicular lines is geometrically impossible. The way forward is clear, what the clients want cannot be done and there are no questions to be asked or decisions or tradeoffs to be discussed. The moral is that projects that involve collaboration with clients and management result in projects doomed to failure.

In reality, the video has a false premise. Clients do not usually make requests that are technically impossible. Clients bring impractical ideas that their users will not like (“convert this paper form to a web page with no changes”), ideas that they have seen on other sites that are not really suited to their business (“we need a customer forum for our tire shop”), ideas that are difficult to execute, and other types of plain-old bad ideas (“include lots of pop ups”).

The false premise of an impossible idea allows the creators of the video to assert that collaboration is not worth the effort, because clients and business types simply do not know enough to be part of the conversation. This idea is regressive and takes us back to a time when back-end technology was king, usability issues were nice-to-haves, and if users could not figure out what to do it was because they needed to RTFM (read the f*** manual) or were creating their own ID10T errors.

There’s no doubt that client requests are often unreasonable, that client management takes skill and practice, and that even the most skilled professionals will sometimes find themselves hitting their heads on their desks at the end of the day. However, this video posits that client unreasonableness is not just a challenge to be approached with skill, but instead that clients do not know enough to engage in conversations about technology design and PMs and account managers just exacerbate the problem.

This is a perilous assertion that threatens to take us back to an era where decisions about technology were made by an isolated few instead of collaboratively and with the needs of users (instead of technological possibilities) as the central focus.

Approaching Technical Problems and Translating Language

Along with the reminder that sharing power is fundamental to the work of UX, “The Expert” provides other important reminders. First, a technically oriented approach to solving technical problems sounds logical, but in reality a focus on the technical (especially in the very first meeting) is probably a veiled (and often subconscious) attempt by technologists to claim sole control of the design process. “The Expert” focuses its entire seven minutes and forty seconds on technical limitations and the critical early questions about users, their goals, and their expectations are never asked. Approaching client problems through technical possibilities and limitations is not productive and distracts from the real questions at hand.

The job of translating technical knowledge into everyday language is its own skill

The hard questions center on understanding and figuring out what will actually meet the users’ expectations and needs. The technical decisions certainly involve detailed feasibility discussions, schedule negotiations, and feature trade-offs, but that comes later. In the end, an unwavering focus on technical limitations from the first meeting is what causes the failure of the project in “The Expert,” not the input of clients and management.

The second reminder “The Expert” offers us is the critical importance of language translation. The creators of this video used an easily understandable geometric impossibility to illustrate just how ridiculous client requests sound to a technical expert and how bizarre the scenario feels for experts when the other people in the meeting cannot understand just how impractical the requests are.

From the perspective of a non-technical client, however, what typically happens in these meetings is just the opposite. The clients start by making what to them seems like a very reasonable request. Then a technical expert uses confusing technical jargon to tell the clients that what they are asking for is obviously not going to work. The technical expert cannot believe how clueless everyone in the meeting is and gets increasingly agitated. The clients are unable to decode the technical jargon and see the annoyed expert as condescending and difficult.

Technical people with no training in user-centered approaches often struggle with the difficult task of expressing technical realities to non-technical people. Once you become a technical expert by working in a domain for many years, it becomes nearly impossible to remember what it was like when you were not an expert. The reality is that the job of translating technical knowledge into everyday language is its own skill that requires its own expertise. Understanding your audience well enough to use language they can comprehend in order to get your information across is not easy and takes skills that are not learned over night.

Moving Forward

“The Expert” reminds us again of the importance of skilled UX practitioners on design teams. UX practitioners can ease the struggle for power, ensure users and stakeholders have a voice in the process, put user needs first, and perform the role of translator. The more we normalize the idea that customers make unreasonable requests and that part of the art and skill of UX work is to expect and handle them, the more we move forward as a discipline.

Clients understandably (and unfailingly) bring unreasonable requests to the table. UX practitioners help drive projects to innovative and creative solutions that make the clients and their users happy. Discouraging clients from taking part in the conversation may sound desirable on those days when they are insisting on radio buttons instead of checkboxes for a multi-select list, but client and user participation in the process is central to UX practice and has implications beyond these frustrating meetings and the technologies that come out of them.

Customers are going to request unreasonable things. The way we choose to respond to those requests is where the rubber hits the road. Focusing on the users, improving our translation skills, and developing creative ways to manage difficult clients is how we will continue to move forward. If we can do that, meetings like the one portrayed in “The Expert” will become a thing of the past.


Article No. 1 390 | February 12, 2015
Article No. 153 | April 14, 2007
Article No. 1 392 | February 17, 2015

Add new comment



Great article!

You've done an amazing job of seeing this video from a completely different perspective, offering constructive criticism, and sharing real actionable lessons in client relations and communications that I find relevant to personal on-the-job experiences.

Thank you.

Thanks Alisha!  

I really appreciate your kind comment. 


Really great article Toni.

Thanks Mike!  

I originally applauded this vid because it was sure to draw people into conversation. To me, true conversation is a very important in the interaction between clients and "IT", as it is in other non-IT endeavors such as redesigning a kitchen or planing an entirely new house. One comment I made when this vid first came out was about the statements that the client's request were "impossible". This has consistently reappeared in most of the later posts. One of my favorite quotes from my Dad (a metallurgical engineer) was that "most requests are easy, the impossible just just takes a little longer". Just dropping that one objection from these conversations just might open people's eyes to totally new possibilities. At one time in our past, everyone also thought the sun revolved around the earth.


It is a really funny video and I agree it opens up a conversation about an important dynamic that isn't talked about much. I used to work with an excellent developer who would say "anything is possible with enough time and money." That guy and your dad had the same idea about technology innovation! 

Thanks for the comment on the article,






Thanks, Toni. I'd like to take this another step forward. The majority of my past work (since about the 1960's) has been as a "Business Analyst". By one definition of this role, we serve as a liaison between the LOB (Line of Business) and IT. The LOB in the vid is represented by management, the project manager and the "users", or representatives of the users. IT would be the UX designers, developers & testing. A subset of a BA's skill set is to be particularly sensitive to the verbiage used during conversations. So...when someone says I want several perpendicular lines and another says impossible, we are supposed to be really, really good at ensuring everyone understands what those terms mean and to trottle back the desire to leap into design. For example, I would ask the LOB what they mean by perpendiculer, because they may actually mean intersecting. (Perhaps they failed geometry.) There are many other questions I'd ask to ensure everyone understood each other before leaping into design. I'm nt saying that the whole scenario couldn't be played out satisfactorily without a BA, but I will say that I've seen many conversations come to a halt because of a leap into design before understanding is reached.



I was also a BA for years and I too spent a lot of time managing that relationship between customers and developers. The main point I was trying to make in the article, though, is that the users themselves are never mentioned. It isn't just the problem of calling the requirements "impossible," the real problem is that the focus should be on users and user goals at the early stage depicted in the video. The solution "8 perpendicular lines" is potentially not valuable to the end users at all.

I am very interested in software development team configurations. Your comment about BAs is something I've been thinking about for awhile. UX professionals do a lot of the work I used to do as a BA. I would love to know about how people percieve the difference between these professionals in the real world today.  

Thanks for your comments,


Fantastic article 

Thanks Ryan!