UX and the requirements gathering phase

When I was in college, requirements gathering was something that was taught in one semester in one class. Now that I have some psychological scars from many years of software development, I see how this is a tremendous mistake in the academic approach to teaching software development.
To discover, gather and understand requirements is possibly the most important phase in development of any digital product, because if you don’t get that part correctly then you’ll start off with a fundamentally wrong base that is destined to fail.
To build a software the goal is, most of the time, to give form to an idea that someone has, in a virtual environment. This has a lot of challenges that are very little technical because you need to be able to have a connection with the people that have the idea and using questions, stories, metaphors, examples, scenarios, and other tactics, you need to uncover what is the vision that people have for the product. And it’s important that during this phase we keep in mind that we must be constructive in our approach when others share their views and opinions, because in this phase nobody knows the end user well enough.
At Bliss Applications we have a pretty intensive process to discover and scope what our client wants to build. It entails a planning of some weeks, sometimes months, depending on the size of the product we are building. The process is made of moments that are both collaborative with the client or internal within the teams. These moments can be workshops to define user profiles, main journey flows, interactions between users and systems, benchmarking competitors, and more. We generate a huge amount of information from these moments.
After being able to retrieve the information from the people that own the idea, we also need to make sure that this information is stored and shared across the board, between different teams with different skill sets, that a lot of times don’t even use the same wording for the same concepts. The communication between these team members and the way the gathered information is stored and disseminated is super important to ensure that whatever the UX that is imagined and initially designed, is actually what is implemented.
So during ideation and UX design we want to have a multidisciplinary team that can provide not only their expert advice and insights but also a different perspective into each other’s inputs. This allows for much more robust outcomes that consider different angles and approaches, from people that are professionals in thinking about digital products in all its entirety.
In the end we know that this is usually the starting point and things tend to change and mutate along the process afterwards, functionalities change, goals evolve, insights get more holistic, and all of this has impact on the requirements as they get expressed, so we need to have a great way to keep this updated, organized and aligned to ensure sustainability and scalability.
Next post in the series:
This is part of a series of posts listed here: