6 ways UX projects get executed — in real life
Beyond what’s taught in D-Schools and what you might read about in most blog posts, working as a UX designer can be very different in the real world
I started working as a UX designer four-and-a-half years back.
As a newbie UX designer, I had a few assumptions, some idealized beliefs, some processes and some definitions ready with me like any other designer starting out.
I was sure I was completely ready to solve any problem with all the processes at my disposal and it was clear in my mind that I would be able to tackle everything that was thrown at me one after the other quite easily. I had it all figured out!
Then real life intervened. Within the first few projects I was assigned to, I got to know that working in UX design in the real world doesn’t work like the way you would think it does. None of the processes I knew about were the perfect fit for that particular project I was working on and with no easy answers forthcoming, it all started getting me down. When I wanted to apply all the things I had learned, all the processes I had placed my trust in, to solve business problems, I started seeing multiple problems like:
1) Business stakeholders often just don’t have the budget for getting UX design done right. For them, the UI is the UX.
2) Business just doesn’t allow for the research part. They don’t see the value it brings.
3) An unfortunate reality, particularly in Enterprise environments, is that UX people don’t have access to the end-users.
4) Stakeholders/ business people are less interested in your UX process because they know (or pretend to know) what their users (they) want exactly.
5) Business people/stakeholders think of UX as a cost to the project/assignment. Think of this as how different companies look at capital expenditure (Capex) and operational expenditure (Opex).
If you have spent any time reflecting on the realities of UX design, you might have experienced some or all of the above problems.
Initially, I was clueless about how UX worked in the organizations I worked in. By the time I had spent a couple of years in UX, I noticed there were a few patterns or ways UX projects were executed in real life and I started exploring and experiencing those in my daily work and assignments.
Based on my experience, most UX projects fall in the following six categories in the way they are executed — not in textbooks, not as per your D-School mentors — but in real life.
Ad-hoc UX
While working on multiple projects with multiple cross-functional teams from various technologies, we learn to take ad-hoc decisions based on available information and opinions that we get from our team (Managers, Developers, BA, etc.) or even from the client in some cases.
For small engagements, it fits perfectly but moving forward it’s a difficult thing to follow. As we take ad-hoc decisions every time on available information time by time, we lose the flow of assignments because of multiple directions and approaches.
For bigger assignments, this pattern doesn’t work. With each issue, we need to bring the complete team on the same page and decide the approach to solve the issue and stick with that approach throughout the project.
What to expect
Ad-hoc decisions can make a bad impact on the project as it moves in a different direction every time and leads to the delay, rework and confusion in the project functioning.
UX is UI
Most of the times I have noticed that when UX teams involvement is over in the project and if any issue occurs, implementation team does not involve the UX team and try to solve the issue as per their understanding and with the help of UI guideline provided by the design team.
The team takes a decision and pay attention only to technical implementation or any specific need of the business and they completely miss the User experience part.
What to expect
When nobody pays attention to the user experience details such as messaging, styling, continuity, the language of the application, it leads to frustration and confusion for end-users. This might sound like a cheap approach as it never includes the cost of UX but with poor user experience, it increases the rework and support cost for business.
You can experience the huge quality and business loss in this pattern as the user hate the product and stops giving recommendations for the products.
End-to-end UX
As a UX designer, I always welcome this approach as it gives control over multiple elements. It is an amazing and challenging way to solve problems.
In this pattern, UX pays more attention to the complete end to end experience of the user.
Many designers including me say that its the best way to handle the problems/ projects but, in this pattern, the focus is more on the total experience than the specific need of the business.
What to expect
By understanding the problem statement we start mapping the graph about each and every possible interaction of the user with product (eg: Newspaper ads, social media posts, Campaigns, Native apps, websites, portals, etc.) and start building the user experiences up to, between and after the interactions of any app or web.
However, it is a costly affair for the business to go with and I have experienced that most of the organizations don’t allow the budget and time for this pattern.
Designer’s Rule
Most of the time when I have started designing for any product, I have always thought of what I would like to have in it? What problems or frustrations I can avoid in the product? How can I improve the product for myself?
In this way, this pattern has helped me to take out problems, confusions and usability issues and fix them immediately. I try to make something that makes me happy as a user.
This pattern gives you the ability to work as if you are the customer and you decide what you like and what you want then design your product accordingly.
What to expect
This pattern is not diverse, It is limited to designers’ thinkings. Once we start including multiple teams or for that matter multiple designers, it introduces variations in ideas. This is a limited approach and great for the beta version of the new type of products. But it doesn’t work for further versions especially when the business introduces features and functionalities it increases complexity.
Research-Based
This pattern is been widely accepted by various agencies and organizations worldwide but in most cases, Business just doesn’t allow for the research part.
It includes researching the users and their activities. UX teams find users’ needs and make sure that the product will address those needs.
It has multiple names such as User-Centric Design, 6D Method, 5S Method, etc.
It includes user interviews, stakeholder interviews, competitive analysis, surveys, business goals, user personas, tasks, analytical thinking, creative thinking, visual thinking, design thinking, understanding pain points, requirements, Journey maps, Usability research, etc. All of these things get us to exactly what the user is looking for and address those requirements.
What to expect
This pattern takes time, cost, resources and it increases the budget for products and businesses. Though these costs are worth it for organizations, I have noticed multiple times to save cost, business/managers/stakeholders without knowing the value of the process they don’t allow to spend that much time and money on these patterns/approach.
As business starts blocking this process, again we jump to designers way approach. And as mentioned it is not an approach for evolving products.
Smarter UX
We are in a trending world most of the time our solutions work for a particular time period and then disappear or become useless.
I don’t say the RnD approach is not good but when we do research we do it for the particular trending behaviors, thinkings, users and particular requirements from the business.
If you have noticed the old era which we call vintage era it has given us timeless things in spite of having less scope and resources for user interviews, stakeholders interviews, competitive analysis, surveys, business goals, user personas, tasks, analytical thinking, creative thinking, visual thinking, design thinking, understanding pain points, requirements, Journey maps, Usability research, etc.
In this pattern, we focus on the domain and the functioning of the business. UX designers learn the variations and operations of the business and link the similarities and resemblances in parallel businesses.
Apple took best practices from other competing products (Nokia, Blackberry) and they come up with a solution which was not just a phone but it was with the best end-to-end experience for the user. They designed the iPhone to ‘feel’ special, for people who were using mobile phones for more than a decade from other competitors.
What to expect
What I think that while we are following the RnD approach we need to know our users, so well that we will be able to guess and estimate the results of all these surveys and researches. In this pattern, we come up with the consulting approach because we have learned the best practices of the other non-competing organizations/products from previous researches. This varies from multiple domains and businesses.
I have experienced the above patterns while working in a particular type of engagement, requirement, time, place. I have learned that the above patterns vary as per products, services, needs, and position of the UX team in the organizations.
We should always revisit the patterns with each engagement and we should do it every time .
