Diverging, Converging, and Building

MackeyRMS came with this ask: although they have many customers utilizing their service, many are frustrated with their web experience. Plus, they want to make back-end updates and improvements. Could we come up with a working solution and implement within a relatively quick timeline?

Design, prototyping, front-end development
Three designers

What is MackeyRMS?

Created by hedge fund analysts, Mackey Research Management Software aggregates and organizes information across applications and devices… We provide company-wide research, file sharing and collaboration on a single web-based platform. Automated and accessible storylines including notes, emails, contacts, models, documents, events, & conversations. Robust CRM database for sell-side, management, investor and expert network contacts. Threads sortable by ticker, topic, timeline, contact, keywords and more. from MackeyRMS | What We Do

MackeyRMS is a platform targeted towards investment and trading companies. They provide a robust, searchable, and easily accessible repository where employees of those companies can submit and retrieve research, notes, conversations, and a whole host of content and data that they’d need to stay up to date. However, what makes it unique is that it’s entirely possible for users to interact with MackeyRMS without ever actually visiting the platform. MackeyRMS can take in content in a multitude of ways: type notes in directly via the web platform or the native mobile apps, import from other services (like calendars), or forward anything to a Mackey-specific email address. The platform can also pull in data based on what it knows based on your notes, like Bloomberg stock indexes or any accessible contact information about relevant persons, such as LinkedIn profiles.

“So how should we do this?”

It can seem very daunting when it comes to redesign existing products… At once, a bunch of questions comes to mind. Should we redesign the interface piecemeal? Are there parts of the UI that’s not working, or is the whole flow and structure confusing? Should we redesign with a fresh start all at once instead? If we’re redesigning anyway, can we use this opportunity to clean up technical debt? If we’re cleaning up the front-end codebase, can we make improvements to our back-end? When the redesign in question is for a multi-layered product which has a strong stream of highly active customers using it on a daily basis, these questions and answers become even more pressing and significant. And this was just the case for our work with Mackey.

Off the bat, we had to tackle the question of how this project should best be set up. To start, we did a design review of the existing product and ran a mini design sprint first; this helped us identify the biggest problem areas and define the scope of the redesign. After which came the question, how and where would we implement our interface changes, and how would that tie into the back-end updates? Should everyone work off the existing codebase? With three designers on this project, it was important to utilize everyone’s time effectively so that people could work relatively asynchronously while keeping towards the same goal. To make that happen, our strategy was to make a new repository, separate from the existing product, which would start as our in-browser prototype but be refined to be the new production-ready front-end for the client to hook up at their discretion after the handoff.

The process of redesign

One of the first things we did at the start of the project was getting to know some of our users and how they use (or don’t use) the web platform.

Since this is a service geared towards traders and investors, many of our users worked in a fast-pace environment and were used to—nay, preferred!—information presented in a high density (these are people who live on Bloomberg Terminals after all). One of the most common thing we heard was that people want to be able to do everything quick. The concept behind MackeyRMS is fairly straightforward, too. Let’s take a look at how someone would use the web app, or…

The critical path

  1. An analyst needs to write a report and is looking up past notes and research their company has done on Apple.
  2. She goes to MackeyRMS and searches for Apple.
  3. She looks through the results, reading through ones she finds to be relevant.
  4. As she reviews past notes, she composes a new one to share her report within the company.

With that simple path in mind, we felt that their previous interface really obfuscated that. And not just the interface, but the entire flow through the app could be reduced, made more agile, and better adapted for our analysts’ (and other customers’) use. The old design seemingly had multiple pages, all with their own set of controls and layouts. However, even though each page looked different, all of them were essentially doing the same thing: filtering and sorting the collection of research by tags. Furthermore, the placement of bits and pieces of features were mixed in with others, adding a potential layer of confusion. For example, a list of drafted notes is located in the sidebar, along with a list of tags for filtering search results. However, to create a new draft, our analyst would need to navigate away via the top level navbar.

View main
View reading

To brighten up the interface and make everything a bit more enjoyable to read and use, we gave the app a light makeover. We "flattened" the app as much as possible too, reducing it to three main screen variations: the main view, the in-depth "reading view" where you can read notes in full and scroll through other search results at the same time, and a notes composer for people to contribute into the company knowledge bank via their browser.

When speaking with our users, many pointed out some specific frustrations they had with the platform: the existing notes composer, the searching/filtering/sorting experience, and the exporting of notes. It worked out perfectly that we had three designers on this project, enabling each one of us to tackle these challenges simultaneously. Since we had devised the overall architecture of the redesigned app together already, each designer knew how our individual feature would slot in with the big picture. And although each designer took lead on their own feature, working in tandem meant that we were always critiquing and improving each other’s work. In my case, I wanted to take on the notes composer.

Notes composer:

Although everyone has to interact with the web app if they’re searching for content, that’s not the case if you want to add notes. Almost half of our interviewees said they don’t use the web interface to compose notes because it’s too difficult or not trustworthy enough for them to do so. To quote, some have "learned to deal with it or work around it" while others "… never enters in information through Mackey, and hopes to never do so." Well! If that’s not a sign that a redesign is needed…

View composer

People were equally vocal about what they needed out of a good notes composer, which was fantastic! Thinking back to those busy Bloomberg Terminals, it wasn’t a surprise that the ability to browse and read notes while composing a new one was essential—as was text formatting. Interviewees went into detail about how they would format notes in Microsoft Word first before pasting it into Mackey to get it just right, or email articles directly into the system. Someone even mentioned using Excel to create a chart which he then pasted into Powerpoint to create an image so that he could paste it into Mackey as part of a note.

Tabs Resizing

In the old editor, you would be bombarded with an overwhelming amount of dropdown and input fields off the bat. That’s because of all the different variations of note templates you could start with and—depending on each company—how many types of tags you could work with. This resulted in a very cluttered interface, even though it turns out most of our users rarely uses any of the templates or additional options. Those templates are important when they’re needed, but those times aren’t the majority. So now they’re tucked away.

Moving towards implementation

At the start of the project when all the designers were focused on redesigning the flow and structure, we whiteboarded together a lot. We did some classic design sprint exercises such as Crazy 8’s and Storyboarding. To make sure we’re always testing our thinking, we threw together quick clickable prototypes on Adobe XD (which was also when the beta had just come out and we wanted to try it, so two birds with one stone!) to share with the Mackey team and users. Once we worked out a collaborative rough "shell", we were able to spin off into redesigning our own features, again starting with rough XD prototypes, and once satisfied with the direction, we moved into the browser. We jumped in, using Middleman, and kept our markup, classes, and organization structure as component-based as possible. It worked out, too, since each of the features we were working on independently also made sense as their own component. To make sure our codebase stays consistent, understandable, and manageable for others, we stuck with our styleguides.

Bringing it together

Our engagement with Mackey was around a month or two’s time. In that time, we were able to redesign, test, and implement a large potion of our solution without needing direct support from developers. Meanwhile, the developers were able to spike out their own back-end changes independent of our progress. When our time together ended, the client was happy with our hand-off, but it was also much too soon to hook everything up together and launch. Good news though! We’ve since checked back in with Mackey a few times and learned that everything was on track, and that they have been able to utilize the front-end we built. For me, Mackey was a great example of when a large project gets broken down into more manageable and separate tracks before coming together perfectly when ready. As a consultant, it’s fantastic to know that I was able to come in for a short amount of time and successfully made an impact on a product—and that our concerns about writing good maintainable code for future developers paid off. That’s always a win.