Behind every great product is a story. This is the story of our new Admin redesign: the process we followed, the challenges we faced along the way, and what we learned from 5 months of ideation, testing, design, and development.
Something is wrong here…
Redesigning the Ceros Admin has been on our product roadmap for quite awhile. Over the past year, we’ve overhauled all of our major web properties from a design perspective, including:
- Ceros Studio (March 2015)
- Ceros Website (September 2015)
- Ceros Academy (October 2015)
- Ceros Blog (November 2015)
The Admin was long overdue for a visual refresh. But more than that, it needed some significant user experience help. Looking at support tickets, it was clear that parts of our interface were really confusing to clients. When we rolled out Intercom live chat in September, we started getting real-time feedback from users on areas of confusion as well.
All of this data confirmed what we intuitively knew already: Something was wrong with our Admin, and we needed to fix it.
Let’s make a prototype!
Shannon Hill, our Experience Designer here at Ceros, kicked off the redesign process in summer 2015 with a flurry of post-it notes. He started by mapping out the underlying structure of the current Admin, then identifying points that didn’t make sense and restructuring it. This provided the underlying information architecture upon which we based a first-pass prototype.
The team also spent a lot of time reviewing user feedback from our support ticketing system to identify the most common questions and complaints about the Admin. When live chat rolled out in fall 2015, we were able to get additional information from clients about their pain points.
Once he had a basic prototype of about 90 wireframed screens that users could run through in an interactive way, Shannon went out to visit existing Ceros clients and do some user testing. Getting people to agree to work with us on this project was a challenge in and of itself—but one that was well worth the endless rounds of emails and calls to set up testing sessions.
During these sessions, Shannon had clients run through tasks in the current Admin, observing where they struggled or got confused. He then ran through the new Admin prototype following the same approach.
Through this process, we were able to gain a ton of insight into what we could be doing better.
Design, test, tweak, repeat
Developing the right visual design and interface was an extremely iterative process. We went through about 10 different versions of the design based on user testing results, internal user tests with our creative services production team, reviews from our engineering team, and extensive feedback from our CEO.
Involving everyone early on in the process, and asking for feedback often, helped us avoid any big surprises or major course changes along the way. We wanted to avoid having a final round review with a large group of people who hadn’t been a part of the process, all providing feedback without knowing what previous decisions had been made or why.
Cooperation, workin’ together (dig it)
Once we finally had the design nailed down, our product team jumped in to begin building out the frontend and backend. At one point, we had four people working in three different countries across time zones on various pieces of the project—which made things even more complex than usual.
The real magic happened in the last few weeks, when we were finally able to have Shannon, our creative director Jack, and developer Sam all collaborating together in NYC. These daily in-person working sessions were really crucial to translating the design vision into a technical reality.
“Engineers and designers have to look at things in a completely different way,” says Shannon, “Engineers break down projects into small, executable components. Designers, on the other hand, look at things holistically, seeing how all of the various parts fit together.”
It was a constant balancing act between adding scope to improve the experience, and cutting scope so we could actually get a product out the door. There was a lot of negotiation—at the end of the day, it came down to getting very clear about our priorities. This allowed us to focus on implementing what mattered most, and prioritize the rest for future releases.
Started from the bottom, now we here
So, after months of working on this project, what exactly have we learned? Our main takeaway was:
“We wish we had Ceros to build Ceros.”
All of our testing, builds, and changes took a substantial amount of time and effort from multiple people. Building Experiences in Ceros is so efficient that we often lose sight of how intensive and complex the traditional development process can be.