Impact
- more active organizations in the year after 3.0 launched
- 3.6x
- more active organizations in the year after 3.0 launched
- new organizations signed up and stayed active after the redesign
- +2,113
- new organizations signed up and stayed active after the redesign
- active organizations from before 3.0, held steady through the redesign
- ~820
- active organizations from before 3.0, held steady through the redesign
What erxes is
erxes is an open source platform that puts a company’s inbox, sales, tasks, support and operations in one place. It runs on plugins, so each business turns on the modules it needs.
The team was planning to remake the whole platform as I joined. Version 3.0 had to modernize it and make it simpler to use without taking away what existing customers relied on.
Most decisions came down to that tension, showing less on screen while keeping everything for the people who use all of it each day.
My role
The only designer, on a small team with a manager, the COO, and a senior and a junior front end developer.
Platforms
Web
How we worked
We redesigned one module at a time, starting with Sales, then Inbox and Tasks.
Each module went through the same loop. I met with the CEO, COO, managers and developers, designed it and brought it back for review, and they approved it or sent it back for another round. The COO founded the company and had a clear picture of erxes, above all for layout and UX. Much of my work was turning that picture into designs the team could build, with my own judgment in each round.
We kept customers at a distance with one exception. A customer needed a feature fast, so we designed and built it first, and it held up into the final design.
The inbox, before and after
The old inbox had five columns side by side, an icon rail, a tree of channels, brands and integrations, the conversation list, the conversation and the customer’s details. A row of coloured buttons at the top changed status, and the details panel was a long list of labels, most of them empty.
I collapsed the channel tree into one level you step into and back out of, so the conversation list gets the room. I moved assigning, tagging and the other actions into one header row and one Actions menu. The thread now records who assigned a conversation, which tags someone added and when someone resolved it, in order, instead of in a separate tab.
I turned the customer’s details into editable fields in a panel you can close, with a small rail beside it for the other panels.
Editing without leaving the table
Most of erxes is records like contacts, deals, tickets and tasks. In the old version, changing almost anything meant opening the record on its own page and coming back. I brought common edits into the table, inside the cells.
The email cell needed the most care. A contact can have several emails, so the cell shows the primary one as a chip marked verified or not. Click it and every email opens in place, where you can pick the primary one, change its verified mark, edit, delete or add another without the row losing its place in the list.
Filters that say what they’re doing
Filtering was harder. Each business slices its data its own way, and the filters had to handle that without turning into a wall of settings.
Each active filter reads like a sentence, Assignee is Gal Zorigo or Type is Product, and you can remove each one on its own. The result count sits under them, so you can see what you’re looking at.
In the inbox, the states people check most come first with their counts, resolved, unassigned and awaiting response. Assignee, date and company sit one level down. You can save filters you reuse as segments and nest segments inside each other.
One board, several ways to see it
Tasks and tickets live on kanban boards, and a board suits some questions better than others. Alongside it I designed list, timeline, gantt and workload views, so a manager can see the same work by status, by time or by person.
Working with engineering
I worked side by side with one of the front end developers. We went through designs together, agreed on what we could build in the time we had, and adjusted as we built.
How it shipped
We shipped on a tight deadline, and to get there the team and I scaled back parts of the design together. The live product differs from these screens in places, so I show the design as I handed it over.
What I’d do differently
I would work in smaller steps. We were redesigning a complex product on a tight timeline, so much of the work turned into translating existing features into a new interface.
I’d spend more time up front mapping the core workflows and setting up the design system, then build and check those workflows with engineering one at a time. That would have caught gaps between the designs and the real product before they piled up.