Digital transformation challenges and the new role of the UX designer
For decades, the software development industry has followed the waterfall software development lifecycle. Nowadays, the industry is under one of the biggest paradigm shifts in its history, transforming into the agile way of working and software development to stay relevant and competitive. That shift has been understated but it is of unprecedented scale and importance.
In this article i will go through some of the misconceptions and mis-interpretations of some aspects of the Agile transformation, the challenges some of the organizations and teams are facing. I will not waste your time by offering useless definitions and trying to convince you that they are wrong. Instead, I will attempt to provide a reality check based on some of the misconceptions and misinformation out there and how the job of the UX designer has to transform to accommodate for the Agile transformation.
There are a lot of benefits to becoming agile. Work in small batches and validate your hypothesis as soon as possible utilizing the least amount of resources. Sound great, right?
As with any other change, people fight against it because simply it threatens the status quo, which is one of the most powerful biases in our “human software”. What we also fail to understand is how we have branded that change towards its intended audience!
‘Being agile means we will be done faster’
‘Sprints offer more freedom than waterfall software development frameworks’
‘Let’s build an MVP for now and when we get more money we could improve it’
Not to mention that Agile and Scrum are used interchangeably as if they were the same.
Branding is important!
As behavioral psychology would have it, there are 3 main ways to change people’s behavior towards a specific outcome.
Assuming we have to choose between 2 options. Option no 1 is Waterfall and option no 2 is Agile then we can do 3 main things to make people choose the one we would want them to choose.
No 1
Offer all available information for both choices and allow people to calculate the utility of each attribute of each choice in detail to make the right decision based on facts.
No 2
Enforce the choice you deem best by removing one of the options (enforcement)
No 3
nudging/choice architecture/selling it as you would a product
Unfortunately a lot of organizations choose to go for the first 2.
Understandably, some organizations feel threatened and they feel they cannot just wait for their employees to accept that change. They know, as they should, that choice No 1 is not really a viable option as people do not have the capacity or will to calculate the utility of these options, thus resorting to enforcement.
Enforcement (choice No 2) might work in the short term and you can see some success but effecting a foundational change like this one without committing to understand what the benefit will be to the individual, leads to major problems.
Change needs to be sold like any other product. You need to sell it from the consumer’s point of view.
What will I, John the developer, gain from going Agile and working in a Scrum framework?
What will I, Penny the project manager, gain from this change?
Don’t talk to me about the collective benefit for the company! What will I, John/Penny, gain?
These are the questions we need to revolve our change management around but we often do not.
The inescapable result of enforced changes is forced behavior that is not rooted in understanding or perceived necessity or value that might result to misinterpretations and skepticism that cost!
The cost
The costs of working in a different way without the right mindset and understanding leads to dysfunctional teams that are not more efficient or effective than before but less.
People oppose the need, for example, for all the Scrum ceremonies because they feel “busy work” has increased and the perception is that we are talking way more than doing now.
Writing up user stories correctly is an added hassle as it does not communicate clearly what is technically required resulting in user stories being duplicated for i.e front end work, back end work and design work, leading to an explosion in the number of user stories per sprint. Product teams have a hard time understanding how this amount of work will be completed in a couple of weeks.
Design work within sprints is now even more objectionable because the sprint is dedicated to practical work towards something that actually works and can be tested at the end of the sprint. Design work has to take less time than before and it has to precede the active sprint work by at least one sprint in order to not raise a wave of objections and to not be seen as a bottleneck.
The MVP problem
‘Defining the MVP’ is probably one of the most hazardous aspects of the misused agile software development implementations out there. Minimum viable product is often seen as such from a technical, financial and temporal perspective where quality is not part of the equation. We need to put more emphasis on the VIABLE part!
MVPs, often having the sole goal to be pushed out as quickly as possible, end up being launched and constitute marketed and rolled out products with continuous improvement, as an after-thought, being the way teams move forward.
I would like to ‘double-click’ on this MVP point as I consider it maybe the biggest threat to usable and useful products. MVPs, very often, are seen as the minimum viable product from a development, finance and time perspective, resulting in products that are less than useful, not very usable and offering partial or less of the utility they need to have to be of service to their users.
Minimum viable product does not mean an aesthetically lacking product of low quality and usability. Also, we should not always “cut” products vertically, going for one step of the process but going deep, simply because that does not allow for receiving feedback on the core process the end-user needs to go through using your solution. Especially for solutions that support step by step processes.
MVPs are built to prove or disprove the hypothesis made during discovery. They are built for learning. What will you learn if you roll out an MVP of a checkout process that only contains a form for the delivery information. If the core task is to buy then this MVP has not taught us anything. The users cannot perform the task.
Another example, the MVP for Uber could be getting a ride from your location to a target location. Rating the driver is not part of the MVP simply because if ‘getting a ride’ does not work or is not a viable idea that solves an actual need then it does not matter whether you rate or not as the whole point of the app is moot. In the same way, offering an MVP where the user can see where he is in the app, does not provide any feedback about the core task of ‘getting a ride’.
And the list goes on..
UX design in the digital transformation era
Taking all the above into consideration, the UX designer have to play an ever important role during this transformation. Product teams need our help not because we know everything and we are better than everyone else, but simply because we have been through that as it is the nature of our field. We are trained to have the Agile mindset.
So what can we do to help?
- Not part of my job is no longer something we can claim. As designers we need to assume more responsibilities to help our teams through this transformation. Things like being the liaison between IT and business is something we do anyway but now our work starts getting into change management and aligning the business as well.
- Align expectations upfront about the design work required, to inform the efforts of the team.
- Collaborate with digital transformation teams in your organization as well as agile coaches to align on a consistent tone and message. Help them see this change from the point of view of the people it affects the most especially since a lot of the agile coaches in the industry are externals.
- Help your team identify a vision for the product by conducting a workshop and involving the users in this process from the beginning.
- Help your teams identify what the MVP of the product should be and help them understand what an MVP is for and how it should be used. Map out the whole process, look at touch points and identify the core user journey. Conduct a workshop to help identify and align what the MVP should be, instead of engaging in an endless brainstorming session that usually leaves more questions than answers.
- All the design tasks need to be registered and visible in the scrum tool your team is using I.e Jira, TFS etc for the whole team to have an overview of what you are working on.
- Kick start a new product or re-defining one by using design sprints and don’t forget to finish each sprint with clear steps forward form the very next day.
- Help the product teams refine user stories based on research data and not bullet point requirement’s list. What do they have to gain? Reduced development, money and time by not building what is not necessary which in turn leads to solutions that are more robust and easier to maintain.
- MVP or not, demonstrate the value of understanding and mapping a problem end to end no matter what the defined mvp is. Map out the whole process, look at touch points and identify the main user journey. Conduct a workshop to help identify and align what the MVP should be, instead of engaging in an endless brainstorming session that leads nowhere.
Conclusion
The new role of the UX designer in a product team is one that I personally find very interesting and challenging. The digital transformation is an incredible opportunity for the User Centric mindset to flourish and product teams to mature in adopting it but that will not be easy without our help.
This is also where a UX chapter/Guild could have a great impact in aligning the future of UX design across business units and ensure help will be provided to the products who need it.
It is a golden era for User Experience and I have only great expectations for the future of this field.
Want to learn more?
If you’d like to become an expert in UX Design, Design Thinking, UI Design, or another related design topic, then consider to take an online UX course from the Interaction Design Foundation. For example, Design Thinking, Become a UX Designer from Scratch, Conducting Usability Testing or User Research — Methods and Best Practices. Good luck on your learning journey!
