Over the course of my career, I have come across, seen and heard many management people. For some strange reason, some of them really inspired and motivated me. If you are working in User Experience (UX) domain, then leadership really becomes an important trait for you. Selling and champion UX in the organization is part of our day-to-day job for all UXers.
Therefore, I decided to pen down my thoughts and definition of leadership. Here is my definition of true leader with which you may agree or disagree.
Mahatma Gandhi once said, "A true leader is someone who creates new leaders." This holds true for today's corporate context also.
A true leader mentors and provides exciting opportunities to others.
A true leader is never afraid of losing his position because he is continuously growing and educating himself with others.
A true leader is devoid of any ego, proud, or superiority complex.
A true leader understands the power of one-to-one human bond and believes in life-long personal relationships that go beyond professions.
A true leader knows you as a person and not as an employee/worker.
A true leader treats everyone equally and fairly.
A true leader is both a great listener and speaker.
A true leader does not command respect because he earns it.
And lastly, a true leader brings smiles, joy and hope.
As true User Experience professionals it is important for all of us to instill these leadership values to grow ourselves and the organization.
The definition of business according to Wikipedia: A business (also called a company, enterprise or firm) is a legally recognized organization designed to provide goods and/or services to consumers.
My definition of business is slightly different. You may consider it inappropriate and skewed but to me real businesses are the ones that make profits by improving the quality of life of their customers. However, most of the businesses these days work on maximizing profits by taking short cuts so that the senior executives could make their CEOs happy. The shortcut formula does not stop at the senior executive level but trickles down and mixes with the life-blood of the organization culture. Ultimately people become myopic and look for short term profits which cost them miserably in the future.
The Context
This is a story about three companies:
Financial Services company (Let us call it FS)
IT Solutions company (Let us call it IT)
User Experience Design consultancy. (Let us call it UX)
As a first step to design its application Suite, FS invites companies to come and assess their existing systems. Finally, IT gets the approval to develop its suite of applications. UX, which does user experience work for FS was not invited for two reasons: first, it would increase the cost of the project; and second, they were designers (who made things look beautiful thus not required at the start of the project).
Process of Assessment and Business Requirement Document (BRD)
IT sends two of their Business Analysts to FS for system assessment.
In case if you are not aware of system assessment, here is a brief description:
“System assessment begins with the evaluation of the system to collect and analyze information on current system design, existing task flows, system performance, and technology. Later this information is used to identify existing pain points, gaps, and improvements that will optimize the system performance. It also includes additional recommendations for improving resource utilization, and improving environmental performance related to the assessed system(s).”
The BAs work relentlessly day and night to study the existing systems, create “existing” business process model, discuss and document the new functionality that FS seeks in their new suite. The assessment exercise lasts for two months. Everybody works overtime to complete the assignment and to make it “happen” and “successful”.
The documents that were created as part of the assessment exercise were:
Business Process Model (in MS Visio)
Business Requirement Document (BRD) (in MS Word)
Just to give you an idea of a *BRD, it consists of:
- Introduction
- Document Purpose
- Project Overview and Background
- Impacts (Users and Characteristics)
- Business Requirements
- Attachments
- References
- Modifications
- Approvals
(*BRD format is company specific and may differ from company to company)
The Project Starts
Everybody celebrated the success of completion of BRD. Project managers from IT sat together with their Business Analysts and designed phases of the project. The project team divided the BRD functionality in terms of use cases. They further divided the use cases on the basis of their complexity and prioritized them in chronological order for development. The project plan was ready and the project got kicked off.
At that point of time, one senior executive at FS realized to include UX to add some design and colors to their new product suite – yes, design and color stuff (at least that was the perception). What the executive had missed was the second point made by Roberto Verganti in his article in Design Mind. “Designers have an amazing capacity to get close to users, understand their needs, and then creatively generate countless ideas,” Professor Roberto said.
UX team arrived on site with their bag of tricks and tools. The UX team was told to design the solution without contacting the real “users” as the project was in stealth mode. The UX team was granted permission to talk to Subject Matter Experts (SME) and employees of FS.
From MS Word to Whiteboard
The project started with Joint Application Development (JAD) sessions. In JAD sessions, FS's SMEs and some managers, IT consultants, and UX team participated. They would start the session discussing the use case assigned for the session and later look into the BRD for the functionalities mentioned – bullet-by-bullet to detail down requirements as per BRD.
The problem with the UX team was that it did not think of the project in bulleted points as defined in the BRD. UX approached it in terms of scenarios and stories (yes, even when they had no access to users) and looked at problems from holistic perspective. The UX team started weaving a story around the bulleted points of BRD. The team did not stop here but start to these stories on the whiteboard.
As Dan Roam has mentioned in his book “Back of the Napkin”
Visual thinking means taking advantage of our innate ability to see – both with our eyes and with our mind’s eye – in order to discover ideas that are otherwise invisible, develop those ideas quickly and intuitively, and then share those ideas with other people in a way that they simply “get”.
The JAD session turned into brainstorming sessions. Brainstorming sessions broke the team hierarchy and brought everybody on the same platform. Everybody was freely expressing his ideas. Great! The project started rolling but there was a problem.
When FS executives started seeing the BRD on whiteboard, they soon realized the gaps in the BRD. As a consequence, the BRD was updated not once or twice but again and again. Whenever the team discussed a use case, BRD was updated with some or the other missing functionality. FS was neck deep in problem because it had already signed the BRD and every change to it was costing them money. The BRD was full of requirement gaps.
Not only FS faced the requirement gaps problem but IT also realized that the order of their use case for development did not make sense anymore. The detailed scenarios revealed that some of the dependent use cases were planned before the parent use cases. It was like expecting a child before the parents were born.
Both FS and IT were in deep mess. FS had to sign a couple of change requests to BRD, which not only impacted their scheduled launch of the web application suite but costs also.
IT had to alter development schedule and ate up some of the added scope to maintain good relationship with FS.
If all the damages - both money and time - to both FS and IT are quantified, it will run in excess of two hundred thousand dollars.
Where the heck is the problem?
BRD was not the only problem. BRD was the outcome of a closed requirement gathering session and not an open brainstorming session. Nobody was made to thought out of the box. The process happened to be a traditional and liner question and answer session (mostly one-to-one); instead of a vibrant and participatory group brainstorming session.
Clients can articulate their “wants” but not every “need” and “goal” that they have. A Consultant’s job is not only to elicit visible but latent requirements also - using his expertise and experience.
Because the clients want something does not mean that they need it. Most of the times, clients do not ask for what they actually need. Often, clients miss on their needs and jump straight to the solution that they have in their minds. They tend to state the same solution as a list of requirements that are not really requirements that they “need”.
IT did not have the same tricks and tools that UX team had. If UX team were brought onboard during the BRD phase, this sheer waste of time and money could have been avoided.
Designers bring Design Thinking?
Tim Brown of IDEO has rightly said, “Thinking like a designer can transform the way you develop products, services, processes—and even strategy.Great design thinking results in functionally and emotionally satisfying solutions where the emotional value is generated through the creation of meaning.”
He also mentioned in one of his other posts, “Design thinking can be described as a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.”
In Roberto Verganti words, “Now that designers have become highly effective at being creative and user-centered, they can pursue an exciting new challenge that taps into their unique cultural background: that of being radical researchers.”
Executives do not have time to train themselves as a designer; therefore, the best bet for them is to hire a design firm. Designers save waste of money and time and also bring in terrific user experience to improve end user's quality of life. As an executive it is important to look at the long term profits and not to repeat the “The-Two-Hundred-Thousand-Dollars-Mistake.”
