Business Analysis in Software Design: Its Role & Integration

Business Analysis in Software Engineering

Business analysis plays a strong role in software engineering, guiding software development and bridging the gap between business challenges and appropriate software solutions. Business analysts conduct thorough analysis of business processes, systems, and user interactions to identify opportunities for improvement and innovation in software development. By collaborating closely with business stakeholders and software development teams, business analysis ensures that software solutions are in alignment with the organization's strategic goals and priorities.

The Merging of Software Development & Business Analysis

Traditionally, it was common for business analysis to be conducted separately from software development by a designated business analyst, who would communicate between the business and the software designer. Today, it is commonplace for business analysis to be included in the software designer’s role – as part of the software development process. This allows software engineers to have a deeper involvement in understanding the business and gives them a chance to actively participate in gathering user insights, conducting market research, and identifying user needs and pain points. Rather than receiving predefined requirements from a business analyst, who may not understand the exact needs required for the specific software development project, the software developer can communicate directly with the business and find appropriate solutions more quickly and effectively.

Buildable Incorporates Business Analysis to Enhance User Experience

Here at Buildable we prioritize understanding the unique needs and aspirations of each business to craft UX/UI designs that speak to the heart of the business and resonate powerfully with the end-user.

To better understand how to use UX/UI design to enhance user experience, we consulted with our very own expert software designer, Ryan Zuzelski. 

Nana: Can you share a specific example of a software project where effective business analysis played a crucial role in the success of the project?

Ryan: Yeah, so we had a client that used a DOS system. They were on a DOS system from the 80s all the way up till 2023 and because of that, you know, no disrespect, it wasn’t bad just because it was old. But it kind of failed to conform to their new business practices. It was very complex and wasn't super flexible. It caused some process misalignment and affected their data. You had to have a technician, because it was like you had to know the specific keys to press, and the specific order to do things, and what not to enter in terms of data – like percents had to be in a specific format. You couldn't enter zero, or in some cases you didn't have the right option to select, so they did like overrides and stuff like that.

So learning about their different departments and their functions enabled us to simplify their workflows. Because we were able to understand their business, we were able to design specifically for them. The new software increased their collaboration because they were all using the same tool and seeing each other’s data and workflow results. It also reduced the number of edge cases [a rare or unexpected situation that can cause an error or problem in a software product] that the software needed to account for.

And then finally, it allowed us to replace their antiquated database, which was pretty huge for them as their data is sensitive. And we were able to make it a lot more efficient to get reports. We found some instances where they had undercharged and they were able to recuperate funds in the hundreds of thousands of dollars.

Nana: Nice. Can you imagine if you had done that same project and you had a separate business analysis person who wasn't a software engineer and they were communicating back and forth between you guys?

Ryan: Yeah, it could have been difficult. It's definitely nice to have my experience working with software developers and even writing some of the code myself for that project and others like it, doing that, and design, and QA. You have people on the client side and they all know their job role and how things work in their world. But as a business analyst/designer, you can triangulate all the different individual needs and find that common ground that you need to create a unified solution that works for everybody. Having that perspective of all the different functions is super helpful.

Nana: Cool. How do you approach gathering needed materials and information from stakeholders with diverse backgrounds and priorities?

Ryan: Sure. Yeah, like I said, every business has stakeholders that have diverse backgrounds and priorities. You're going to need to triangulate those and find something that works for everyone in most cases. And the way that you do that is look for the common ground in everything that the individuals are saying and how they understand things.

It's tough because something that works for everyone might not work super well for an individual. So there's some pieces that you just need to kind of compartmentalize and make sure that they're supported in the way that they need to be. And sometimes it's that the individual has a very specific way that they like doing things that maybe isn't the best for the other employees or the future of that business. The better solution might be aligning your workflow with someone else's. And so it's all a game.

And so you can actually design around bringing them more into a mainstream workflow. And the client I mentioned earlier and several other clients, they all discovered new workflows and new ways to do their jobs because of the collaboration, the increased collaboration. And the new workflows that we created were just more efficient than the ways they were doing things. Sometimes people get entrenched in the way they do things because it’s just the way things are and maybe that is the best way to do things for that case. But when you throw in a new piece of software and the possibility of new workflows and things like that into the mix, you can create something new entirely.

Nana: Ok, cool. Speaking of collaboration, can you describe your approach to collaborating with different teams, like cross-functional teams that you have to bring together?

Ryan: Absolutely. So I can tell you that my role is different for every project. My job title does not change between projects, but I might play a different role. Part of that is just the way that Buildable operates. But another part of that is whenever you work with a different set of people, they have different strengths and weaknesses and things that they like doing or don't like doing.

And so the best version of that project team is one where you define all those tasks that need to get done and you divvy up the work in some way that makes sense for your strengths and weaknesses and those of your team members. And so the first thing that we need to do is establish responsibilities and foster accountability for making sure everything gets done by the person who's supposed to own that thing.

It usually is pretty similar for a PM on a project, project to project. They do largely the same things. And a designer usually makes designs, but I've had projects where developers make designs. I've had projects where designers write code. I've had projects where designers and engineers PM and share that load, like sending emails and writing documentation and stuff like that gets shared. So it's not about enforcing a strict regimen for this role does that and this role does that. I think it's more about figuring out how your project team is going to work.

Nana: Nice. Okay, cool. Do you use any metrics or key performance indicators to measure the success of your business analysis?

Ryan: Yeah, so metrics and performance measurement are critical on any project when you're not sure if it's working. It's a great way to make sure that things are working as intended. And they're different for every project.

So if we want to make a consumer app, we might build into our design and code base the ability to track the number of times people click this button and measure conversions and stuff like that. And then for an internal portal, you can measure that in time savings for employees, and things like that. But it's super different.

But it's an art in itself, figuring out which metrics you actually want to track and then actually designing for them. So it's important to identify those early and evaluate yourself on them often. We like to do integrations with analytics, tools, and stuff that helps us do that asynchronously.

And then there's always, you know, in client work, I want it to be this way. And that's the end of it. But when we have the chance we like to do that metric creation, collection, and then measure ourselves against it. It is really important to be collecting that data.

Nana: Okay, cool. Awesome. Can you share an experience where you had to adapt your business analysis approach to accommodate changes in project scope or requirements?

Ryan: Yeah, I wouldn't necessarily say my approach changes. Changes in project scope and/or requirements are something you can pretty much count on with any project. And so it has to be – it should be – baked into any approach. But I can tell you that when scope changes, something else also needs to change or things are not going to work.

There is the trifecta of budget, timeline, and quality. And when scope changes, obviously, it shifts the balance of those things. So what we do about that is we perform risk value analysis to prioritize scope and ensure we're always working on the most valuable thing.

Usually, clients have an idea of what the most important thing to the thing that they want to build is, this feature or that feature, or this nice to have thing. It's going to be the main idea that we want to build first. And if you're always building that most valuable thing, then your scope decisions, they just get easier, because you've already built the thing that you absolutely need. Maybe your budget, or timeline, or scope has changed in some way, and you need to reprioritize; well, then you haven't wasted any time. You built the thing that you absolutely needed to. Now you can see how you want to approach it.

Nana: Cool. Okay, thank you. How do you handle situations where there is ambiguity or uncertainty in the business’ requirements?

Ryan: There's always some ambiguity or uncertainty. And it should be treated as an opportunity. We talked about how different people have different perspectives. That's a lot of where ambiguity happens, is things have been done a certain way for so long, you're not sure how to align those things or how to make something that doesn't exist. That's usually the main thing that's ambiguous is that the thing doesn't exist yet. And so that's kind of our opportunity as business analysts or designers to come up with that – that something that doesn't exist, but is the better way.

And so that is usually, figure out everything that is known and absolutely wanted. And then you ideate, and you got to think about your business goals, you got to think about your users’ needs. And in doing all of that, you come up with some ideas, put some designs on the board and, and see which one is going to work best to resolve whatever design problem you have. And then you test it out and see if it works.

Nana: Cool. Okay, that gives me a new perspective on it.

Ryan: Yeah, that's what we do. And that's what we do every day. pretty much. If it wasn't ambiguous, I think we wouldn't have a business.

And there's always, in any design space, there's a range of things that exist. And the range is things that are absolutely known to things that are unknown. And somewhere in there you go from what is known to what is an assumption.

And so there's like three parts in there, there's the known, there's the assumption, and then there's the unknown. And the assumption can be pretty dangerous; it's better to have the ambiguity. We practice user research and meet with our users. A lot of our clients are users, but if we're making a consumer app or something like that, we perform user research so that we can define where that assumption lies and then take that into how we resolve the unknown. It's the toughest part of the job. And I think that it's the most exciting too.

Nana: Oh, awesome. Okay. Let's see. In your opinion, what are the most important qualities or skills that a successful business analyst, working as a software designer would have?

Ryan: Sure. Coming off of our last question, it is the toughest part of the job and the most exciting. I think that's the perspective that you need to have. It's an obsession with the problem, rather than the solution. Someone said that to me once and it makes way too much sense.

There’s a concept called the feature factory, which we really try to avoid in our products, which means that you're building features that don't really have a place or that address a problem. And that's kind of what marketing does. You make a product, then find a market for it. And there's some places where that works; custom software is not one of those places. It is a place where you need to solve a problem with a piece of software, with a product. And so if you start with product and try to place it, you're not going to have as much success as if you sit down with that problem, and understand it, and then compose a solution that solves it efficiently. So I think that is the main thing.

And then, however good you are at analysis and design, you should be a good teammate and know how to leverage people's abilities, even on the client side or whoever you're solving the problem for. You should know how to work with them, leverage their abilities, and be a good teammate.

Nana: Nice. That's awesome. Okay, cool. Anything else to add?

Ryan: I think that's just about it. It's really cool to do what we do. And it's super rewarding when you get it right. I had a meeting this morning where one of my employees produced a design and he finished up presenting it and someone on the client side just said, ‘That's awesome’. And that's what happens when you get it right. And I think that's what business analysis in design is all about.

Nana: Awesome. Well, thank you.

Ryan: Thank you, Nana

 

End Interview