Executive Triaging System
From paper trails to a streamlined request system for one of the most active consulting firm's CEO.
UX
Visual Design
Product Design
Avanade
Overview
I was brought onto a project for one of the highest grossing consulting firms (let’s call them “Oltiva Consulting Group” ) to support their Office of the CEO. This was the team that was responsible for intaking, triaging, and planning out the engagements done by the current Oltiva CEO (well call her “Janet”). At the time, coordinating these engagements meant juggling emails, stacks of printed pages, and literal hand-offs between team members trying to piece together Janet’s calendar. Our goal was to utilize a new platform to help move that entire workflow onto a digital platform and make it customizable to each individual team member to support their unique needs and workflows. Fun!
Stopping the Marriage
The ERTS, Executive Request Tracking System, had design comps by the time that I had joined the project. The only challenge was that there wasn’t enough UX support on the project at the time, so a lot of the designs were done by committee. The UX organizational layout was laid out in multiple columns leading to no clear correct way to flow through each page. There wasn’t clear visual hierarchy, and overall the system felt clunky and difficult to use. At the time, there was no pushback or concern around whether or not those screens were done correctly from a UX perspective.
As our team joined the project, a lot of the initial reviews with stakeholders were a delicate balance of trying to show new version of different portions that had clear visual hierarchy, prioritized key details, and allowed power users to quickly go row by row to fill out what they needed and move right on. The first step was redesigning the cards to be more informative, easier to scan, and visually consistent. Next came refining the layout of the intake flows.
The biggest challenge at the time was the fact that these original screens were weeks away from getting green lit, so each session felt like we were rushing to the alter to stop a marriage.
“Wait! Don’t use those, we think these are better and here’s why”
“Stop! We don’t recommend you move forward with those screens, we think that these are much more intuitive and can get users to the finish line a lot quicker”
Eventually, after a few long and tense conversations, the OCEO team agreed,
“You’re right, these aren’t working. We need to rethink this.”
Phew!
”Now get to work, we’re short on time.”
Ah, right. Gotcha, we’re on the right track and our clients believe we know how to get everyone to the right direction, but we need to get stuff out. Kind of felt like in those child mystery movies where the main character barely escapes expulsion and the headmaster is like “You’re safe. For now.” Except we were never in trouble. I didn’t get into trouble. This is a bad metaphor now that I think of it…
Showing not telling
A core part of this project was being able to showcase both to the development team but also the stakeholders how functionality would work. We were in daily meetings in which we’d discuss with the lead developers ideas that I was working on to establish a) is this feasible? and b) when should this be implemented. With stakeholders, we were actively doing user testing with the core members of the OCEO team to figure out if our designs were as intuitive as we though. How did we do that, I hear you ask through the screen? Figma Prototypes! Lots and lots of figma prototypes.
I would wire up high fidelity wireframes to help showcase functionality, navigation, and explain new features. This helped the OCEO team grasp key features without digging through lengthy docs or chaotic Mural boards. Eventually we had a working prototype that someone could navigate as if it was the fully coded product. Great for explaining ideas, terrible for keeping track of components. This wasn’t sustainable, so I then took some time to create a system to help track all the bits and pieces of our new product. It was time for (cue suspenseful music), a design system!
Designing a Design System
I settled on the approach of utilizing atomic design, documenting and componetizing all the smallest components, things like buttons, colors, fonts, small card backgrounds, etc. These were the atoms of all of the larger pieces that would make up a page, so I eventually had a whole section of the core design pieces, the atoms.
What do you get when a bunch of atoms combine? A molecule! These were design elements that utilized a bunch of different core design components to make a stand alone object. Things like data cards and drop downs found their homes here.
A bunch of molecules create an organism! This is where you’d see carousels of cards sorted by priority, subsections of pages that each had their own primary function, all stored in these sections.
What happens when you put a bunch of organisms together?! Well you get a page… the analogy kinda died there, but the idea stayed the same! Utilizing the components that were in the organism section, we could craft full pages that the development team would be able to see and inspect. That way, we had a clean version that we could replicate to create new designs from or to create prototypes to help communicate with stakeholders. The best part about this system, was that if we needed to make a global change, we just needed to modify the atoms or molecules and the changes would cascade throughout all of the areas. No tedious combing through of screens to make the same change.
We also had a change log that developers could reference to see when a component was changed. This helped tremendously when it came to communicating with the devs when we had to make a tweak. Instead of getting lost in Teams messages, developers always knew to look at the top line on the change log to see what things got tweaked, how they got tweaked, and when.
We called it the ‘Dev Page’, since for them, this was their single source of truth. If you wanted specs for a design, you always went to the Dev Page.
Function by Function
There were three central parts to ERTS: The Intake/Triage system, the trackers, and dashboard.
The intake and triage system allowed OCEO team members to quickly understand what was the ask for the CEO’s time. A request could move through several stages: intake, triage, execution, archive. A member of the OCEO team is able to record notes related to the request and begin the process of meeting planning.
An OCEO team member would be able to establish pre-prep (meetings without the CEO) and prep meetings (meetings with the CEO to prepare them for the eventual meeting), and document notes, action items, and schedule any follow up meetings based on need. Our goal here was to consolidate all actions related to a request into one platform. Instead of someone needing to compile emails and notes from different meetings, all of these details are able to be stored within the individual request so that once a request/meeting had been completed, they could use the archive of that record to review should it be needed later.
OCEO members had different focuses: some gathered materials for meetings, others triaged requests. One tracker wouldn’t fit them all, so we decided to allow OCEO members to create their own tracker. Per user, up to 10 trackers we able to be stored that could help tailor information to help OCEO members track the most important details relating to them.
The dashboards posed a similar user need to the trackers. Our cards were designed to showcase the most important information related to a request. We had numerous user testing sessions with key OCEO staff to understand what was the core information that would help keep someone in the flow of “what was that thing?” without derailing them and forcing them to click into a specific request. From mission critical responses to seeing which meetings need to be scheduled and what tasks someone has for the day, we had buckets to carry all of those tasks. Unfortunately during the span of the project we didn’t have time to design a dashboard builder, so created several dashboards based on user interview needs to come up with different layouts to help support the main archetypes for each OCEO team member.
Takeaways
This was the longest project I’ve worked on so far at Avanade, and was also the first time I was operating more in a product designer role compared to a envisioning role as a UX Designer. It taught me how much I enjoy watching a product evolve through iteration as well as being able to communicated with the development team, conduct QA on dev passes, and overall think deeper about the product I was designing. It was one thing to come up with an idea based on key user needs, but it was another thing to engage with how the platform we built our solution provided challenges and constraints, understanding which feature was more important to develop first, and continually work with the OCEO team to craft it into something that was really tailored for them.
This was my first time working on a design system, and I feel like the trial and errors of building out the Dev Page really helped me tidy up as a designer, and helped me become a better teammate to my developer counterparts. We received a lot of positive feedback from the developers, and eventually became my go to plan for designing with a new design system.