Moraware UX Case Study Image

Moraware: Case Study

Project: Creating a mobile-first stock counter for the reception of materials at countertop fabricators across the US.

Intro to the company: Moraware

Moraware began ten years ago as a brotherly favour. Over time their software grew into a complete solution for countertop fabricators. While initially designed by their dev team (which has gotten them to where they are today with over 10.000 active customer accounts), it has left them with a lot of design and technical debt. Improving customer success through improvements to the software, alongside the creation of new areas meant this project was going to be a challenge… speaking of which.

Patrick Foley headshot

Patrick Foley

Senior Product Manager, Moraware.

"We already have a full-time designer, but we were behind on one project and needed some additional help to get over the hump. Nathan blended with our team and our existing designer perfectly.

Working with Nathan has been great - he allowed us to move much more quickly and get our software designs ahead of the needs of development. 

We worked very closely and collaboratively - and often asynchronously. Each day or two, we would chat, or I would record a screenshare of a feature detail we were working on. The next day, Nathan would come back with wireframes that realized the goal of that feature. Then rinse and repeat on the next feature. We reviewed these designs with various team members and continued to iterate until they were ready to give to developers. 

Nathan very quickly developed an understanding of our software and what we were trying to do for our users - he has a great sense for building SaaS software that needs to continue delivering increasing value for customers. 

I strongly recommend working with Nathan!"

The challenge.

Every day, staff across the US receive deliveries to their countertop fabricator warehouses. An accurate reception of these deliveries and subsequent stock counts is critical to the success and profitability of these businesses. Currently there is no way to do this using Moraware.

The challenge was to design a new addition to the Moraware software suite; A mobile-first app that allows warehouse staff to accurately receive, count and update stock…all while being tied into the main body of the software. 

the UX process for Moraware

The process.

Moraware have a full time UX designer and several product managers. I was teamed up with their senior product manager, Patrick Foley. Patrick walked me through the software. He explained its limitations, desired outcomes from working together and ways in which we could communicate and collaborate.

I spent some time looking around the software and making notes. To say the software was big, would be an understatement. I needed to dig in to understand the needs of companies that would use such software.

Initial sprints would involve just Patrick and myself. Once we got to a stage where something had legs, it would be presented to the rest of the team. However, early on I learned a valuable lesson: Sometimes a wireframe can be too clean.

Initially I worked in Figma, which I love, however some team members were a little confused as they designs looked too developed. They thought they were looking at finished designs. I quickly took a step back and went to Balsamiq. For better or worse, there is no mistaking a wireframe made in Balsamiq. An oldie but a goodie.

The entire process was very collaborative, a preferred way of working for me. Ideas grow from feedback and other people’s perspectives. I thrive on this. You may be wrong going in a certain direction, but you won’t know until you go there.

figma wireframe vs balsamiq wireframe

Problems and challenges.

The problem of working on a well-established project with technical and UX debt.

The existing software was very old school, not just in looks but also implementation. Given the size of the software, it meant all work would be pushed out in gradual increments and following certain established design guidelines. We couldn’t go crazy and reinvent Moraware. Moraware weren’t looking for a UX overhaul. They had 1000’s of active users, so no decision could be taken lightly.

Time zone differences…Not exactly a problem.

I’ve worked remotely for the last 8 years, so working around time zones is not new to me. However, finding times that everyone is available to meet and discuss work can sometimes be challenging. Thankfully tools like Slack, Zoom and of course good old screen-recording-software helps ease the pain. In the end, working asynchronously gives both myself and the client the freedom we need to get the job done. 

Project expectations.

While there was a general expectation of “Let’s make this incrementally better”, certain departments had differing opinions on how to achieve this. The great thing about Moraware was the collaborative aspect. While my main point of contact was the senior product manager, I was also in close contact with their UX designer and the development team. All presentations involved the whole team.

An often-overlooked department within any feedback session is customer support. They are on the frontline and deal with client frustrations daily. They are in a unique position to help.

One aspect that I really enjoyed about Moraware was the small changes mentality. It was refreshing when compared to the go big or go home attitude that can get some businesses into hot water. Working like this meant that iterations were ongoing, and nothing ever stood still. 

Moraware Initial Wireframes

Understanding the business.

As with any new project certain things need to be done:

  • I need to understand the goals of the project.
  • I need to understand what each department is hoping to achieve through this project.
  • I need to learn how the current software works (and not only on a superficial level. What is it trying to help with/achieve?).
  • I need to know how many users we will be affecting. It’s not the same to change how 20 customers interact with your software as it is with 10.000. 
  • I need to know how the client likes prefers to communicate/meet.

Customer personas or real-life testers?

Moraware is lucky enough to have thousands of customers. This meant that all the work was based on real customer feedback and interaction. This feedback was gathered through 1 on 1 chats between the product manager or support staff and the customer. While customer feedback can sometimes be skewed, the team at Moraware were experienced enough to know which information was valuable and which to skim over. 

The iterative process.

As with 99% of all new projects, early user-flow diagrams and designs were sketched out on paper. Once I had a rough idea of the direction, I jumped in and started wireframing the screens. While Balsamiq is certainly more old-school, it does a great job of removing distractions when presenting to the team. It’s very important when presenting screens that the team understands they are looking at wireframes and not a lo-fi version of a finished concept (See above 😊).

Moraware Initial Wireframes
Moraware Initial Wireframes

Results and final thoughts.

The work with Moraware spanned several months. In that time, I worked on 3 different areas of the software, each area affecting the other. Working with such an experienced product manager made the project thoroughly enjoyable. Constant iteration, updates, feedback sessions and asynchronous work methods meant we were able to get a lot done in a short period of time.

I know that through our work together, Moraware will save their customers a considerable amount of time using the software and money through loss of hours, stock and client material orders.

Every business is a world unto itself. They way they work, their systems and even the way they communicate. Being the hired gun, often means you must adapt to fit the situation, but with Moraware both parties adapted to a process that was productive for everyone. A truly satisfying project. 

Nathan J Powell Logo

Interested in working together? Drop me a line and let's chat!