What have I learned while designing ParagonERP

June 18, 2018

—

Stefan Gutnick Allen

Becoming a UX designer

For a brief while, I had a job that required me to organize interpreters for international conferences. This involved making their contracts, which was done in an SAP system ‒ one of the ERP heavyweights.

The software was so inherently confusing that I made a guide just to make the contracts. It was almost like a set of directions on how to cross an entire city in one go. Click on the icon that for some reason looks like a… mountain? Hit tab three times and then enter the contract dates. Refresh the page to generate the list of conferences to assign them to. Sacrifice a woodland creature and pray that the data is up to date.

So when I heard about a company trying to make an ERP system with a focus on user experience, I jumped at the opportunity to join the team. Despite having zero experience, I became Jonar’s new user experience designer. I had a lot to learn.

I learned so much that after work I would be mentally exhausted. I felt as if my brain had been running at 110 percent all day, everyday. I was pretty comfortable using software, but I had no idea how much skill, knowledge and hard work is required behind the scenes to actually make it and keep it running.

Within a month, some of the first features that I designed were actually implemented into ParagonERP. But that didn’t mean that I was done learning, just that I had started on my journey as a designer. I still consider learning one of the most important parts of my job.

Of all the lessons I’ve learned, I’d say the following are the most fundamental to user experience design.

It’s easy to spot mistakes once something is built. It’s almost impossible to catch them all beforehand.

No software is perfect, and that’s not a secret. Anybody who’s ever used software before has found some case where they wished the software looked or behaved differently. Maybe it’s something fairly trivial, like an animation that gets annoying the 100th time you see it. Or, maybe it’s an application designed so badly that all Hawaiian residents were mistakenly told they were being attacked with missiles.

But a lot of these details are incredibly difficult to spot before you actually design or build the software. Luckily, there’s a solution to this problem: prototyping. Prototypes help us spot issues or areas from improvements we never would have anticipated otherwise.

For example, when designing Paragon’s rule engine, we realized in our prototypes that a lot of the controls were obscuring the actual information people want to look at. So we returned to the drawing board, and came up with some ways to make the controls less obtrusive to the user experience. Before actually trying it out, we had no idea how necessary this redesign was.

If you’re building the software, you’re not the typical user.

It’s kind of a cliché to say that if you’re the one building or designing the software, you are not the user. But there’s a good reason for it being a cliché ‒ unless you’re designing software for yourself, you can’t fully predict people’s needs. If you try to guess, you’ll get it wrong. In the end, software is an abstraction of the real world, and the real world is very complex. People’s jobs, experiences, and needs are also very complex. So you need to get out there and figure out what problems your users actually have.

When first designing some of the accounting features in Paragon, we relied on traditional accounting wisdom, and forced users to close their general ledger periods. Even though it was the safer, conservative approach, it turned out to be a mistake. Nowadays, the expectation of accounting software is that periods can be left open for convenience. It requires a bit more vigilance on the part of our users – but they needed to be able to leave their periods open, so we changed it.

This isn’t to say that you should blindly follow what your users tell you. They’re experts of their domains, but not at designing software. Understand what their problems are, then use your own knowledge and experience to come up with the right solutions.

Don’t try to build something for everybody.

Imagine if a tire manufacturer decided to make a tire that could work interchangeably on a tractor, a car and a motorcycle. Think of all the potential customers they could have ‒ and with only one product! Sure, you might be able to make the tire, but is it a good idea? It would be too small to be effective on the tractor. It would be too large on the car. And it would make a motorcycle dangerous.

Software is a bit more adaptable than tires. But if you try to design for everybody, you’ll inevitably design for nobody. Nobody will be quite satisfied with your product, as they can tell it wasn’t built for them.

ParagonERP is a great example of this. It’s got a lot of functionality that a lot of different businesses can use. But would I recommend it for everybody? No. It’s probably not the right software to manage your small café. But if you actually need an ERP system, you should give it a try.

These are just some of the things I’ve picked up during my time as a user experience designer. I’m not sure what lessons I’ll learn next, but that’s okay. It’s kind of like testing a design ‒ you’ll always be surprised by what you got wrong, and what you got right.