Tag Archives: business process

Your project goal is to update a business solution that is slow and laughably outdated. Frankly, this dinosaur is making life hell for Company X’s employees and causing good people to make costly mistakes. You want to deliver a solution that gets rid of that pain and they will enjoy for years to come. (Hopefully not too many years.) It doesn’t take long to realize that there is a fundamental flaw in a business process that no amount of intuitive interface design will fix.

The great thing about this situation is that you’ve discovered the problem. In the user interviews, discussions about pain points and daily tasks have painted a vivid picture of the issue. Old school requirements gathering processes probably would have disregarded the information about the issue or simply recorded requirements needed to follow the currently flawed process. That’s one of the beautiful things I love about User Experience work. You get to dig deeper. The team can now start discussions to address the root issue.

Of course solving a business process problem is rarely in scope for most software rewrites. But the customer expects the project to make their lives easier. They have put faith, time and money into the project because they believe it will improve their situation. If you deliver a kick-ass application, that only solves part of the problem. The customer will be disappointed and perceive that you didn’t deliver or that the project didn’t accomplish all that their dollars were supposed to. You can meet your obligation, do your best work, and then not understand why the customer a year later contacts a different vendor to fix what you built.

It may mean increasing scope, or writing another SOW to cover the additional project of a new service design. Or, heaven forbid, you may have to take on that extra work and absorb the hit on this fixed bid project. But you have to do something in order to make your customer happy. Either that or you end up being the infamous third-party that technically delivered the requirements, took the money for the gig, but didn’t solve the problem they were hired to fix.

Make fixing that business process your problem. Because it is. You may not be the one to do the work of fixing it, but any UX professional worth their title should be able to guide a business to a new process that will work. And then, when you deliver that kick ass application, they truly will love you. You will have provided critical value and brought a little more sunshine into the users’ lives. While you’re at it, capture some before and after metrics so that you can measure the awesomeness you have brought to their business.

Share

Like this:

Your project goal is to update a business solution that is slow and laughably outdated. Frankly, this dinosaur is making life hell for Company X’s employees and causing good people to make costly mistakes. You want to deliver a solution that gets rid of that pain and they will enjoy for years to come. (Hopefully not too many years.) It doesn’t take long to realize that there is a fundamental flaw in a business process that no amount of intuitive interface design will fix.

The great thing about this situation is that you’ve discovered the problem. In the user interviews, discussions about pain points and daily tasks have painted a vivid picture of the issue. Old school requirements gathering processes probably would have disregarded the information about the issue or simply recorded requirements needed to follow the currently flawed process. That’s one of the beautiful things I love about User Experience work. You get to dig deeper. The team can now start discussions to address the root issue.

Of course solving a business process problem is rarely in scope for most software rewrites. But the customer expects the project to make their lives easier. They have put faith, time and money into the project because they believe it will improve their situation. If you deliver a kick-ass application, that only solves part of the problem. The customer will be disappointed and perceive that you didn’t deliver or that the project didn’t accomplish all that their dollars were supposed to. You can meet your obligation, do your best work, and then not understand why the customer a year later contacts a different vendor to fix what you built.

It may mean increasing scope, or writing another SOW to cover the additional project of a new service design. Or, heaven forbid, you may have to take on that extra work and absorb the hit on this fixed bid project. But you have to do something in order to make your customer happy. Either that or you end up being the infamous third-party that technically delivered the requirements, took the money for the gig, but didn’t solve the problem they were hired to fix.

Make fixing that business process your problem. Because it is. You may not be the one to do the work of fixing it, but any UX professional worth their title should be able to guide a business to a new process that will work. And then, when you deliver that kick ass application, they truly will love you. You will have provided critical value and brought a little more sunshine into the users’ lives. While you’re at it, capture some before and after metrics so that you can measure the awesomeness you have brought to their business.