Design Thinking - Desired Outcomes over Fixed Requirements

Being Agile in FinTech, an industry that uses technology to make financial services more efficient, requires at least twice the effort that you would put in to implementing a proper Agile process in an average tech startup.

Due to the financial aspect of the services that a company provides, the stakeholders, project managers and business analysts come from an environment where different Waterfall based project management processes are essential for understanding and keeping projects under control.

There are separate stages for analysis, design, development and testing, so before moving from analysis to design, the project requires clearly detailed requirements.

We need requirements in an Agile environment as well, as we initially have a list of features (often called user stories) for the software that will be built. Each feature needs to be detailed so therefore a business requirements document is created in order to describe the business needs.

So the business requirements document is common to both practices, being part of the analysis stage where the desired outcome is specified.

A business requirements document (BRD) details the business solution for a project including the documentation of customer needs and expectations.

A business analyst thinks about all the big issues in advance and tries to foresee all the possible scenarios at a detailed level. And in the financial services industry, for stakeholders it is imperative to have a clear process in place to assist with project management and implementation.

Business analysts need to make reasonable estimates of how big a project is and how much it is going to cost. And due to this need, the BRD, once it’s written, it becomes a “bible” for the success of the feature request.

At that moment, the BRD starts to be protected like a most precious jewel even if it comes at the expense of good design solutions.

And exactly here, at the beginning of the project, any Agile UX practice is forgotten. Even if an iterative design process was agreed to be followed, the desired outcome is forgotten and the focus is solely on the requirement.

We suddenly have a fixed-scope project that needs to be designed in an Agile manner.

Now scope can be used to describe either the definition of done in the requirement or the actual outcome.

So if we modify the scope, we either fail to meet our initial requirements, or we realise (for example due to new research) that the initial requirements needed to be changed and we simply adapted.

So what is the definition of done if we modify the scope in fixed-scope project? We certainly fail to meet the initial business requirements.

So let’s forget about fixed-scope, focus on the design outcome and release a feature that brings value to the customers.

Adapt the requirements as many times as needed in order to actually be agile and release a feature that brings value to the customers.

Putting value on outcomes and not on requirements is the key to a good design process, understanding that what really matters is the customer’s experience, the value that the functionality brings to the end user.

Radu Fotolescu is an UX Designer based in London, currently working in FinTech. Founder of UX Design Today — UX Courses & Axure Libraries.