Marketo is a marketing automation web-platform that helps marketers better manage, nurture, and thus score leads. Marketo is a trusted platform for CMOs, helping marketers create better relations with their leads, and grow revenue. The platform is huge, complex, and used by over 6000 customers on a daily basis.
The Marketo platform is undergoing a major UI revamp. And though just an intern, I was entrusted with the UX of two completely new and equally important features - both of which are slated to be developed and implemented in the next release. I also worked on redesigning Marketo's Community Support space, and animating loading screen for the new platform. Besides those, I worked with the senior designers on a number of projects at different stages, right from research to visual design.
One of the most interesting aspects of this experience was the mentorship program, apart from having a cool intern mentor, every week I had a new mentor from the team with stronghold on different parts of the UX process - user research, visual design, sketching and wireframing, etc.
Folders are one of the most important parts of Marketo. Folders can be thought of as not only an organizational tool but also as a high level reporting tool and an area to create and manage all the assets (Programs and Campaigns) within the folder.
The goal was to revamp Folders for the new UI; but with enhancements to folders along the way. Improve the general UX in order to make users more efficient, while maintaining the familiar workflows Marketo users are comfortable with. With something called channels in Marketo, we needed something that would focus on a bird's-eye view of the data (cost and leads) of the channels running in the Folder. So, working with the PM, I came up with a possible solution of adding an Overview Reports tab
Currently, the folder overview looks something like this:
Having just joined the team and been assigned this project, I had to do quick a lot of reading and research about the platform, folders, channels, and the current flows. The result - there wasn't a place in the normal marketing instance where this kind of data is being reported but a more advanced data reporting tool RCE. So, I wasn't sure if this rolled up data is what a user wants. But given a tight schedule of the release, I talked to the product manager and realized it was a knowledgeable call from his part as he's had conversations with the customers prior to this.
Trusting that, I started getting familiar with the new UI standards and putting my ideas out on the paper, whiteboard, and Balsamiq
Realizing that a data visualization for a rolled up view would be a good feature going forward, I started designing something that would reflect consistency in design across the new platform. After brainstorming and discussing designs in review meetings, I went in and created the low fidelity wireframes with quite some confidence...
The PM loved the designs I presented, and we almost put it in for developing since the company was on a tight schedule. I however thought it would be better if I could get some users to see and make sense of these designs. So, I decided to conduct testing with some internal marketers who use this platform just as regularly as our customers - daily. The approach was to keep it organic, took some brilliant pointers from the research mentor; the goal was to see if the data that they see is making sense to them as soon as they lay their eyes on it, its an overview data after all, it needs to be comprehensible at first glance.
The result from these tests were a lot more informative than I had anticipated. The graph visualization that I came up with was definitely seen as a value added feature, but it wasn't as quick to understand and take in since there was kind of information overload on the screen. The cost graph increasing downward, the leads bars crammed together, with the summary at the right presenting data that is a little different from the data in the graph, plus there were problems with understanding what the filter menu for the graph did. So, all in all it was a good thing we didn't just go ahead and develop it.
With the user testings opening up more than a couple of flaws in the design of the graph, we decided to pass the rest of the tabs in design for development, while I continued to iterate the reports design - and there were quite a few iterations before we felt comfortable moving forward. The iterations go from left to right in the order they were designed after continuous feedbacks from the UX team after each iteration:
After the iterations, and consulting with senior designers, it was time to hand in the final designs. The details and reports tab both combined into one, summary, and graph in programs view put into one category. The graphs with a little more visual element to it, and the cost metric displayed as another bar and not just an overlay. Now, once these designs are developed and released to the first few customers, usability tests then will validate or bring up more flaws into my designs. Meanwhile, have look at some snapshots.
Though I knew, it was good to be reminded that every now and then it's good to step back a little, analyze the bigger picture, and go at it again. I also, learned that even internal user testings can help a big way if they closely represent the customers. Working with the PMs and the devs brings up their point of views too, which is as invaluable as a user's perspective. In company this big, with a certain UI language set, it is challenging but really fun to try and come up with design solutions while maintaining consistency with the set standards.
The primary objectives of adding label - a user defined value assigned to an object for classification or categorization - functionality in the new platform is to allow users to have more control over the metadata that is associated with objects in Marketo to increase findability, and improve reporting.
For the, users would be able to add labels to local assets, programs and folders and use those labels as search/filter criteria in the tree, also be able to delete labels from an asset, create new labels, and copy labels from their parent. This would provide baseline functionality to allow users to get a feel for the new labeling interface and allow us to gather initial feedback and data. The MVP would also include a base level of product instrumentation to allow us to understand how customers are using the new feature.
To start off, we scanned through dozens of threads on the Marketo community, where the users themselves post their problems, suggestions, or solutions to other user problems. This helped us realize that the users have been asking for a expanded label functionality for years; also a sense of assurance that we weren't asked to design an insignificant feature.
We then sought inspiration from other systems and how they handle tags/labels in their products, and in what context do they implement it. With some initial research done, we put our respective ideas on paper and then met to compare and contrast solutions, only to find out that we were pretty much on the same page as to what our vision of the feature was.
The design process was very agile, with design review meetings, and brainstorm sessions with the PMs, engineers and other designers held very often. The first iteration suffered from quite a few flaws, inherit labels from parent wasn't intuitive enough. So, with the second iteration, carrying parent labels interaction was reworded, and autosuggesting label names was modified. The latest iteration, introduced a few changes with a 'remove all' button, further changing new label creation interaction, and interactions around limiting the user to 10 labels per assets was made less confusing.
Labels project was quite different - agile and iterative at the same time. Design review meetings were held more often, brainstorming sessions involved the PM more often; designs were built in stages and iterated over as well. This process was quite fun to be involved in, with feedbacks exchanged face-to-face and design suggestions being received from a cross functional team - though not every suggestion is going to be implemented, listening to these suggestions helps you understand how things are perceived from different points of view. Also, the fact that we did not talk to the users directly highlights the fact that the process in the industry is quite flexible. We did not have to develop Hi-Fi wireframes for labels, as the team had a UI library in place, which helps the engineers to develop designs based on low fidelity mockups. Hence, through every iteration the user flow and user interaction were the most focused rather than the visual design of labels.
We received a help call from the admins of the Marketo's Community Support space to redesign their website, with a goal to subject users to a clutter-free experience and also help them find solutions and answers quicker than now. The website was built some time ago, with poor information architecture and a bulky UI.
We decided to conduct a remote card sorting activity for users. The task required the users to segregate screenshots of the website into 6 categories base on how often they use those features of the website. We sent out invites to about 20 customers. The result of the participant users' card sorting look something like this:
We had a pretty good idea of where we want to go with the redesign job. The results were pretty baffling to say the least, with most of the features of the website rarely ever used and searching being the main feature around which the website use revolves (as expected).
Talking to the stakeholders, we realized that the users mainly come to the space to post their questions or search for blogs to solve those questions. So we then decided to get away with most of the content, and hide the ones that are in-your-face but useless in bubbles, where it can be accessed if at all the users wants to. And make the website more search friendly, by also reorganizing the filters as compared to the previous chaotic layout.
The redesign project taught us an important lesson to always be open to tweak your process as the needs arise. We redesigned the website despite not being able to do a thorough user research, but the designs were well appreciated by the stakeholders even though we didn't have compelling data to validate our decisions. When there are some successful solutions in the UX community, isn't it viable to take advantage of them and save some efforts?