There comes a time in the lifespan of an Organization when using spreadsheets to plan and manage operations is no longer a viable option—they need to slowly transition into enterprise planning software, also known as ERP. These systems allow organizations to gather and organize essential business data and streamline their operations as they continue to grow.  

This software is essential for assisting organizations’ day-to-day activities like accounting, project management, compliance, and so forth. Naturally, this raises the question, “How does one even design an ERP?”. How does a team of designers lay the groundwork for such a complex product? 

Well, fortunately, we’ve got you covered. In this article, we’ll explore the peculiarities of an ERP design process and explore some best practices to help you avoid common pitfalls. 

Let’s jump right in. 

What is an ERP?

Fundamentally, an ERP is a product that allows companies to automate a wide array of their processes. Plus, enterprise resource planning systems ensure that the information from different processes and departments can flow freely within the organization, which provides everyone in the company with a single source of truth. 

ERPs typically contain multiple modules for processes that pertain to accounting, inventory, finance, supply chains, customer relationship management (CRM), and many others, depending on the kind of product or service the organization provides. As a result, this repository allows key decision-makers to access the data from different modules and departments, compare business performance, evaluate their success, and inform further decision-making. 

How to Design an ERP

From a bird’s-eye-view Designing an enterprise product isn’t that much different from building a basic app. However, the moment we take a closer look, we’ll notice that enterprise apps, such as Oracle ERP, have many layers of complexity to them. For simplicity’s sake, we suggest looking at ERPs as conglomerations of smaller apps. These smaller apps are unified into a single ecosystem.

Fortunately, though, the core process of designing an ERP is somewhat similar to designing any other product—one important difference is that often you’ll have multiple processes running simultaneously. Naturally, this can overwhelm a team of designers, which is why we strongly suggest having a DesignOps specialist on board to help manage this behemoth of a process.

Empathize 

Most design work starts here. But there’s a catch—your end-users aren’t necessarily a very tightly defined group. Given that ERPs are used within large organizations within different departments, you need to take into account the needs of all the people working in the company, i.e. show empathy.

Start by defining your user personas

This is a solid first step. What seems to be the simplest way to go is to segment them by their line of work in order to ensure that your studies will yield reliable results. Because of the complexity of the system and company structure, you can’t limit the UX persona's definition to their behavior or tasks. But want to segment them by the work they do. 

e.g., Task: Create a new document; 

e.g., Work: Analyze financial data. 

Conduct in-depth interviews (IDI)

A critical part of empathizing with the people that will use the ERP is conducting in-depth interviews with them. IDIs are an excellent way to get a more profound and detailed understanding of their opinions and needs regarding the user experience of an ERP. 

While general qualitative and quantitative surveys and questionnaires should by no means be excluded from your research stack, in-depth interviews can provide you with a much broader understanding of your users’ requirements and can yield much more actionable insight.

Leverage quantitative methods

Most likely, the organization that you’re designing the ERP for has a wealth of untapped data from their current solution. This information can provide you with a valuable perspective into the way this product has been used, especially from a quantitative perspective. 

By leveraging analytics, you can uncover a wide array of patterns that can be used to create a new and improved product for the organization’s staff. 

Look into contextual inquiry

Contextual inquiry is exceptionally useful in scenarios like these. Aside from allowing designers to get a better understanding of the product requirements, features, and content strategy, it can yield a lot of useful data that users themselves wouldn’t be able to provide you with directly. 

Think of it this way—while diary studies are a valuable source of information, people aren’t always aware of the peculiarities of their daily routines and tasks. Therefore, the observational quality of contextual inquiry studies will come in handy here. Observing users, in this case, will allow you to collect important clues as to how people organize their workflow, which will invariably lead to a more seamless and intuitive user experience. 

Competitive research

When it comes to ERP products, the competition often comes in the form of isolated single tools that cover a certain area of the process. Part of delivering a better product revolves around filling the gaps by creating a more coherent and cohesive product or ensuring better integration. 

Internal workshops

Given how diverse and multilateral the users of an ERP are, it’s essential to conduct internal workshops to ensure the overarching alignment between different stakeholders in terms of flow, processes, and features.

Define

Once you’ve collected enough data to be able to empathize with your users and acquire a better understanding of their needs and expectations, it’s time to define the problem you’re trying to solve via design. 

UX research

Research should accompany your design process from start to end, but it’s extremely important during the Define stage. A solid combination of research methods will allow you to both identify the problem you’re trying to solve and focus on the things that really matter without wasting resources on guesswork. 

Synthesize research insights

Once you’ve studied your customers’ needs, it’s time to leverage your research results and use them to create detailed personas, empathy maps, and other deliverables. 

Align on goals and priorities

Given that the ERP you’ll be developing will be intended for a particular organization, you can always cross-check your findings and their derivatives with the core team. They’ll help you navigate the project more efficiently and align on goals and priorities via workshops. 

Ideate

After the problem is defined, it’s time to identify potential solutions for it. The best way to go about it would be by conducting ideation workshops, creating early sketches, and collecting early feedback from the core team. 

Prototype and test

Given how multifaceted and modular ERP products are in nature, there’s going to be lots of wireframing, prototyping, and testing involved. This is essential to ensure that every single flow of the product satisfies the needs of its end users. 

It’s also important to take into account that you’ll have to iterate after the product launch, which by the way, may happen in multiple phases.  

ERP design best practices

Now let’s cover some things that will help you avoid a whole host of pitfalls and increase the likelihood of a successful outcome when designing an ERP product. 

Organize your stakeholders

Close collaboration with stakeholders will prove to be very useful in the long run—not only are they power users of a fairly rare type of product, but they also have an in-depth understanding of their colleagues' needs, as well as the bottlenecks they face with ERP products on a daily basis. You can’t become an expert in all the things an ERP can do. That’s simply not possible—you need the stakeholders’ experience to guide your design.

The RACI matrix is also a useful tool in this scenario. Given the sheer number of people involved in designing an ERP, assigning responsible, accountable, consulted, and informed people on the project is a very useful way of planning and managing everyone’s work.

Involve developers early

Considering that ERPs are a very lengthy and complex undertaking, the cost of error is high. Involving developers early in the process will allow you to mitigate potential development-related issues early on and allow you to calibrate your plans and expectations. 

Optimize for different needs

Complex projects can be adjusted to different users with varying degrees of niche knowledge. Think of a person that is on their first day of work at the company you’re developing an ERP for. Overwhelming them can cause significant friction, which can deter them from learning how to use the product. 

Make sure that new users enjoy a thorough and well-thought-out onboarding process. Ideally, it should feature a learning-by-doing approach that would let them slowly but surely get the hang of the interface. 

Casual users already have a basic understanding of how this type of software works—their top priority at this point is for the product to be intuitive and easy to use.

Power users, on the other hand, care most about increasing their productivity—they already know the ins and outs of ERP software. All they want is for it to help them do better work faster. 

Balancing between modular and global thinking

We mentioned above that ERPs contain a series of different modules, but that shouldn’t be the way designing one should be approached. These modules have to work together.

If, at some point, you decide to allocate different teams to different modules, you’re running the risk of creating an experience that lacks cohesion and coherence. Therefore, it’s important to fine-tune your approach to designing an ERP, making sure that there’s a balance between modularity and wholeness.

Documentation and design operations

The bigger your design team is, the clearer the need for documentation is. Choosing to simply wing it can run the risk of utter chaos.

The more people you have on your team, the more you need documentation. Otherwise, chaos will have free reign over your product design process. The larger the organization, the larger the chaos. As such, you need thorough documentation that’s regularly updated.

Documentation aside, the larger the team, the harder it is to manage it effectively. Relatively recently, a practice of allocation a DesignOps specialist emerged, and we advise utilizing that.

Productivity beats simplicity

For a new designer, it might be tempting to sacrifice “cluttered” design at the altar of “clean design” and “minimalism." This principle, at best, would be situational. Power users often need access to a lot of information at once, so hiding it isn’t necessarily a good idea. We covered this extensively in our article about Enterprise UX. 

On top of that, having a learning curve that, in the long run, makes users more efficient is also ok. Remember that organizations stick to ERPs for years, so they definitely have the time they need to fully utilize your product.

Conclusion

ERP systems are a very taxing, lengthy, and expensive undertaking—these things need to be thoroughly considered before designing one. Throughout the design and development process, you’ll be closely working with professionals whose needs aren’t as self-evident due to their narrow specialization. 

Despite this, your workflow will mirror that of any other project. But you’ll need to do more testing, more prototyping, more research, more expert walkthroughs—more of everything, due to the complex and modular nature of an enterprise planning software.