These are just finance guys. They don’t care how it works, they just care about the numbers.
The other day I was in this meeting where the new project team was being brought together to kick off a new piece of software that was geared toward capturing financial data. This software would ultimately provide key answers to to the finance staff as to how their clients were being billed.
So of course we’re getting the regular rundown that I’m sure a lot of software teams are familiar with:
- The project has to be delivered in 3 months
- We are going to focus on a small set of features for the first release
- As a result, a lot of this process will be manual
Blah, blah, blah and then the kicker comes.
The product owner (we’re almost 100% capital “a” Agile in the company at this point) says “and look, I don’t want to spend too much time on the look and feel. These are finance guys, all they care about are the numbers. I don’t want to spend time on the interface.”
Now my skin crawls. Assumption alert! I hate hearing stuff like that. But friends, let me tell you, now is not the time to fight this battle. Politically, bringing this up now and having the argument about UX and how important it is to make each piece of software so easy to use your Grandmother can bill clients is not the goal. Keep this under your hat for now, otherwise you’ll find yourself getting cut out of meetings faster before you can say resource allocation strategy.
But don’t be too hasty…
So now how do you proceed? Rather than throwing in the towel altogether on the UX and also rather than blowing yourself up in a critical meeting the question then becomes: How do you get going on this project with this weird constraint around – interface doesn’t matter, let’s just build this as quickly as possible approach?
Well for one thing you start by falling back on your principles of good UX but marry them to the project objective (notice I didn’t say “goal”) of being as quick as possible. The thing to ask yourself and the product owner is “hey what gives with the users not caring about how this works?” And in this case I found out that the reason behind it was that several attempts to build this project failed because it was too complex and now the company was out of compliance and we had a limited time to build it. Cutting out screens that the developers then had to build and test now seemed like the only logical option.
Get to the root of it!
Ah ha! So now that you know the root of the decision, you can find out how to to deal with it. Side note: why didn’t I just ask the product owner this during the kickoff meeting? This way I could have gotten this out of the way right then? Well certain situations require a more gentle hand. I was new to the project team and don’t know the players involved and their levels of ego. So outright questioning at that point of a product owner with an ego can look like I’m challenging them. And when you are brandy new to a team, outright challenges can go one of two ways. And one of those ways could suck for you. So, in the real world, because this is a real world case, the way I went about this was to create screen designs that were easy to use but in as few screens as possible. How do you do that? I’ve heard as fews clicks as possible but as few screens?
One of the reasons I love software design so much is that there are so many ways to approach the problem. To solve for this objective of create less work for the developer but still make something that’s easy to use, I put the following principles into my mockups:
- Stop errors before they happen: Don’t let the user make a mistake they don’t have to. Disable buttons and prevent them from submitting things that are half-baked or don’t make sense. This cuts down on errors to handle and it also cuts down on confirmation dialogs.
- Eliminate pages: I got rid of detail pages wherever possible in favor of editing things right in the results table. For example, when assigning roles to new users on an admin screen don’t have them have to click through to a user detail page just to change their role, let them do it right in the grid.
- Understand why the business asked for something: Cut down screens by getting down to the real goals of what the business is trying to do with the application. This is where BA skills come in handy but basically by asking why they want to do something will sometimes lead to an ah ha moment with the business stakeholder that shows them and unnecessary set of functionality in the app or something we can consolidate. An example here was that the business initially thought they needed to approve all special editing that happened after the financial data was imported. This turned out to be a false assumption that cut out tons of screens. We would have just went ahead and built that had we not been focusing on why the business wanted certain things in the app.
The result is now we have a web app that displays financial data in a way that is easy to manipulate and understand by the users and we were able to build it within the time constraint allowed. And we were able to do this by sticking to some basic principles about simplification in UX and focusing on the goal of the application (which is something I always harp on).
So now here we are 3 months into the project. The demos are going well and the product is being accepted by the stakeholders faster than the sprints can even end. And now that the product owner can see the possibilities of what the team can do when paired up with some good UX practices, they are thinking of extending the project and making it responsive.
“Wouldn’t it be great if John could go into his management meeting with his iPad and bring up the billing data?” he said.
Wow, what a shift from finance guys just don’t care about that kind of stuff, I think to myself.
The big takeaway here is when you hear something like “We don’t have time for UX” or “the users don’t care” or something in the neighborhood of “don’t focus on user experience” pick your time and place to see where that thought is coming from which will highlight a path for you to getting good software out the door.
