Get in touch.

Nevermind
Thanks for reaching out! I'll be in touch soon.
Close
Yikes! Looks like the form is busted. Check back later, or try getting in touch with me on twitter
Close
Close
JournalContactMenu
Case Study

Glow up for a 20 year old intranet.

Working closely with Accenture Federal Services, our team was asked to give a facelift to an intranet that housed critical data around the status and upkeep of a variety of digital systems. This project was a small piece of a much larger effort to eventually revisit how the information architecture is structured and automate what used to be manual tasks using ServiceNow. However, our team's main focus was solely on the UI and UX for the front-end of the client's intranet.

Project Overview

Our objective was to bring a system from Y2K into the era of modern web standards. Redesigning a UI of that age meant we had to be extremely sensitive to the fact that we'd be messing with the muscle memory of folks who had been using this system for nearly twenty years. Changing things like button location and size, what forms looked like, the typography...etc. were decisions we had to approach delicately. And since this was one of the largest systems the client had, there was more red tape than usual around getting approvals as we moved through each phase of the design process.

My roles and contributions

  • Lead and executed the UI design, from wireframes (in Axure) to final comps (in Sketch)
  • Was one of three direct contacts for the client. This involved presenting work, packaging and sending final deliverables, and answering questions
  • Was the quality-assurance stakeholder for our development team.

Surveying the landscape.

The first step in this project involved the client providing us with screenshots and walkthroughs of the now legacy interface so we could understand the intranet's architecture, how it was being used and what for, and get a sense of what folks wanted out of this redesign.

We noticed there were immediate easy wins: things like increasing the size of the buttons so folks had a larger hit area, and giving those buttons a bright color so they'd be easier to find. We also found that virtually no one used the green question mark boxes which opened a tool tip. We got rid of them, and paired tool tips with the text for each data point.

Other improvements were more challenging. Folks demonstrated how they had to squint and hunt around a massive amount of information just to find a single line of data. The legacy interface had two columns full of gray, unevenly stacked boxes which housed tons of tiny text, like, 8pt font. Although it would be a relatively big adjustment for users, we explained to the client that stacking those boxes in a single column and allowing folks to reveal and hide the ones they needed would not only reduce scrolling, but make finding and updating information in them faster.

The legacy system's unevenly stacked data tables.
The legacy system's poorly organized navigation links and buttons.
The legacy system's use of drop-lists where predictive search inputs should have been.

Winning key stakeholders' confidence with high-fidelity wireframes.

The biggest hurdle we faced in delivering on time was getting timely approvals on our work from 3 different teams, each at different ranks of seniority. Knowing we couldn't lose time on revisions, we made sure to always have a "safety solution" in our back pocket for both the wireframes and design comps so we could always fall back on a most-viable-product approach if folks began to get nervous about budget.

Knowing some approvers on each team were not very computer-savvy, it was imperative that the wireframes were as high fidelity as possible: I made sure accordions opened and closed smoothly, buttons had hover states, and form inputs were actually able to be typed in. Taking those extra steps to make the wireframes mimic real-life functionality saved us time speaking to and explaining how things would work. My "safety solution" was a second direction for the wireframes which offered a lower level of effort solution that would still meet requirements, but not require as much complicated functionality as the first.

I began my presentation saying, "we have two options for you today. I'm going to show you folks the minimally viable solution first." As I walked them through they began asking me hypotheticals, which I could easily respond to by saying "actually, I think you'll appreciate how we handled that in the other direction." They were extremely impressed by the fact that I had not only met their requirements two different ways, but that I was giving them the option to choose which solution they felt most comfortable proceeding with.

They went with the latter, saying it would also impress the highest ranking team and that we had the safety solution to fall back on if need be. I could feel the relief on the other end of the phone; even though my team and I were "just subcontractors" they knew we'd treat them as collaborative partners (not know-nothing-clients), and that we understood the intricacies of the system and the politics at play behind it.

Putting an agile spin on our waterfall workflow.

Our team at Brunch Digital usually conducts projects like this using waterfall methodology, but knowing the sensitive time constraints I advocated that we loop our developers in as early as the wireframing stage. Doing so allowed them to weigh in and provide guidance on the functionality updates I was proposing. This gave them more time to plan how they would approach cutup, and helped me feel more confident about the design solution and the time it would take to build. Because I was able to provide the client more accurate forecasting from our dev team, they were able to make more informed decisions when we presented options to them.

After finalizing the wireframes and moving on to design comps, we opted to design two different visual directions for the interface. While the level of effort to create either was nearly equal, having two options for the client to choose from would help us save time on revisions because we could get a better sense of stakeholders' likes and dislikes.

Wanting to duplicate our success we had with the wireframes, my colleague, Tyler Berg, and I decided one direction would push the envelope, and the other would be a bit more conservative: the main difference being one interface was darker and more open (appealing to the stakeholders who wanted the design to look like any other modern web app), the other felt more boxed-in and sturdy (a safer choice that would feel more familiar to older computer users). They chose the former, and also provided some points of feedback around things they liked from the more conservative option that they wanted us to incorporate into their chosen direction. Specifically, things like input styling and the overlay effect that happened when editing a data table. Since we were slightly ahead of schedule because of how smoothly the wireframe phase went, we were able to deliver the enhancement and remain on track.

They went with the latter, saying it would also impress the highest ranking team and that we had the safety solution to fall back on if need be. I could feel the relief on the other end of the phone; even though my team and I were "just subcontractors" they knew we'd treat them as collaborative partners (not know-nothing-clients), and that we understood the intricacies of the system and the politics at play behind it.

Wrapping it all up.

Because our developers had been involved since the wireframe phase, they were able to get a valuable head start on cutup as soon as certain aspects of the structure were finalized. This made "handoff" less like a cold transition from design to dev, and more like us letting the developers know that no further design changes would be made, so they were free and clear to fully dive into cutup.

While I was waiting for the final blessing from the client team, I had more time to work with the developers on questions they had and complete some early QA. Doing so saved us lots of time toward the end of the project because I was creating fewer and less complicated issue-tickets. Small, easy tickets meant the devs were under a lot less pressure to as we neared our final deadline.

We delivered cutup on time, and well above the client's expectation. Our team's reputation benefited greatly from how smooth and successful this project was, and because of that we put ourselves in a better position to win future projects with this client.

Personal Takeaways

  • I gained greater confidence not only presenting work to tough stakeholders, but on calls with 20+ people.
  • I became comfortable breaking out of our typical waterfall workflow and adopting more agile-like methods to better collaborate with my teammates.
  • I gained more experience in crafting different viable solutions and articulating the consequences (both positive and negative) of each.