Redesigning a Cyber Product
When I joined my company as the sole UX Designer, my first task was redesigning a legacy cyber product. This product was multiple versions old, and had a reputation of being difficult to use. The team had recently completed a major rewrite of the front-end to a more modern framework using Google’s Material Design as the base of their UI design. While this redesign made many components look more modern, certain workflows were changed during the redesign that resulted in more clicks - something we later learned the Users did not like.
The situation was made more challenging by the fact that the team and I did not have frequent access to Users - representative or actual. This meant that any workflow changes we made would be industry best practices or assumptions based on past customer feedback sessions, which would need to be abstracted to apply to the latest version. Thankfully, later in the project, we’d hired a subject matter expert (SME) who was a former User and was able to facilitate interviews with current Users.
Before I get into the design details, I want to quickly go over my process. This was my first major product design experience, and in many ways it defined and evolved how I approach product design. Reviewing the literature, and keeping in line with my Systems Engineering background, I designed the process I’d use for redesigning the product:
Understanding the problem to better empathize with User needs
Researching solutions (including competitive analysis)
Designing better workflows
Improving the user interface elements
Handing off to developers for implementation
Each step of the process would require some form of User feedback to ensure that every aspect of the redesign effort was User-Centered.
Starting the Journey
As a solo designer working with an Agile development team, seamlessly integrating into their cadence was a challenge. During my previous projects, UX Design was generally ahead of development, or performed before development even started. Since this was a product already deep in development, I had to figure out how to speed ahead of development by at least a sprint or two.
I spent about one and a half weeks analyzing the current state of the platform and compiling a list of “UX Bugs”. These “bugs” were then sorted by severity upon the usability of the platform, and the potential scale of the redesign effort, and finally presented to the team. To my surprise, the developers acknowledged many of the faults as “known issues”, and participated in brainstorming for solutions. The developers seemed eager to think outside the box and critique the platform from a usability perspective. Taking advantage of the momentum, I set up a Design Sprint workshop for the team, where we discussed solutions to three of the highest severity issues found during the initial analysis.
During the design sprint, I learned the importance of a team willing to critique itself; working with a team of developers that acknowledge missteps and make effort to correct them allows UX designers to focus on more pressing matters than convincing people the importance of viewing issues from a User’s perspective, rather than only a technical perspective. We discussed the three issues in great detail, iterating on concepts based on each other’s feedback, focusing on how we could bring value to the User’s experience with our product. The sprint resulted in three workflow frameworks and numerous UI sketches illustrating the workflows. I took the sketches back to my desk, loaded up Axure, and got to work on adding fidelity to the mockups.
…But what do users think?
You may have caught it already, but there was a vital piece missing from all of the work we’d been doing so far: we had no idea if the Users would like what was designed. I was leading the UX of the platform using principles of human factors engineering and interaction design, such as Nielsen’s Usability Heuristics, Krug’s “Don’t Make Me Think”, and Norman’s “The Design of Everyday Things”. Furthermore, I performed “guerrilla” usability tests by asking those team members who weren’t part of the development team to find and perform actions within the system. The thought behind “guerrilla” testing was to get some qualitative usability data; if those who have no context of the platform or updated design can easily find actions and use the platform, actual Users will likely be able to find the functionality easily. (Later on, we found that this assumption worked out on this project.)
Bring in the SME!
It was around 4 months into the redesign effort when the company hired a former User of the platform as a developer on another team. I eagerly set up a meeting with them to discuss their experience, and where the pain points were. They explained that many of the issues Users had focused around workflows, data density, and the number of clicks to complete a task. Common sentiments were, “All of the pretty visualizations don’t mean anything if I don’t get the information and actions that I need” and, “It took me too many clicks to find this information”.
Together, the SME and I built a database of User personas, or profiles of User roles. Each “Persona Profile” was structured much like a common social media page, with a representative description of the archetype of person. We divided the profiles into sections for “wants”, “needs”, and “dislikes” to better help us understand how to improve current workflows and better design new ones. We also included common job schedules, ambience of work locations, and desk setup/ergonomic factors. After compiling the database, the dev team and I could make more confident decisions about the product we were building.
The “Ideal” Experience
“You’ve got to start with the customer experience and work backward to the technology.”
- Steve Jobs
About five or six months after starting work on the product, and building the Persona Database, I started compiling workflows for what an “ideal experience” of the product could be. An experience crafted around the needs and wants of the Users, without considering what the current product could do technically. These workflow sketches lead to an information architecture overhaul - from the site map to the individual component interactions. I started working on a style guide with rules for how various components should be used and a framework on various display methods. This included a completely rethought interaction model and concept of displaying information. Conceptually, what used to exist as disparate information found in various parts of the system without a logical connection, usually only in tables or lists, was now displayed on an interactive, logical, and actionable canvas view. This meant Users no longer had to jump between different parts of the system to get all the information or take actions - one of the recurring frustrations conveyed by the SME.
I’d designed a medium-to-high fidelity mockup of the next-gen UI in Axure. While mockup up the next-gen experience, I integrated in some of the workflows and UI that I’d worked on in the past, but with the more streamlined next-gen framework; I wanted to show the product and development team that there wouldn’t be any lost capability with this redesign. At the next design review meeting, I presented a version of a workflow in the current product and the same workflow in the next-gen experience. Unsurprisingly, I was met with numerous questions about the feasibility - these were developers, after all, and they’d want to know about how we’d make the mockups a reality. What was important to me as a designer was that the developers started questioning why I made certain decisions. I was able to correlate User feedback (from the Persona Database) directly to decisions made in the workflow and UI design, which helped convince the developers and product manager to consider this “ideal experience”.
There was still the issue of the current experience, though. An idea I had was to craft the ideal workflows and “back-port” them to the current product design, which the product manager and developers agreed was a good idea. This allowed the developers time to build the code necessary to get to the ideal experience while maintaining the current product, and allowed me to gracefully upgrade the experience over time so that Users don’t feel intimidated by a completely new experience in the product they use every day to do their jobs.
A Second Product
While in the course of redesigning the current product, I was made aware of another project in it’s infancy within the same “family” of products. I swiftly began discussions with the product manager and development team on how to integrate UX and UI design, and was met with enthusiasm and willingness to rapidly iterate on ideas.
Since the two products worked together and shared Users, I was able to identify a few workflow styles and design patterns to use while redesigning this second platform. Over time, the design naturally started sharing various workflows, patterns, and other aspects that would, theoretically, solidify the mental models when using the two products together. This led me to talk to leadership about integrating the two products together; unifying the platforms together would allow workflows from one platform to translate easily to the other. I pondered workflows similar to the Microsoft Office family of products, where each product has its own identity and function, but seamlessly integrates into another. That is to say, when creating a table in Excel, I can simply copy and paste that table into Word and it “just works”.
Note: I’m not going to go into much detail about the development of this second product in this write-up, but I wanted to mention it for context.
Team Activities
For both products within the ecosystem, there were still numerous issues to fix for the short-term. Another team had hired a UX designer, and we’d collaborated on broad topics and provided each other basic reviews for a few months, but it wasn’t the same as having a dedicated designer on the same team.
Designers…Assemble!
Over the course of the next few months, I evangelized to leadership that expanding the UX team would allow us to accomplish significantly more. After buy-in from above, I set out to build a team of great designers - people I can rely on, learn from, and advocate for the Users on products we develop. The team grew from one designer to four; we grew in both numbers and diversity, with backgrounds in graphic design, IT, and fashion design. Furthermore, we were from different generations and cultural backgrounds. It was important to me that our team exuded diversity so that we may collaborate and provide unique viewpoints to solutions. Diversity in thought can help approach problems in a novel method.
The progress of the redesign exponentially increased as we added more people. One designer was assigned to the second smaller product, while two were dedicated to the larger product. I managed the progress, goals, and priorities of the redesign effort, while also contributing towards the product designs.
User Interviews
About a year and a half into my time at the company, I had the chance to perform User Interviews for the first time. Since our SME was a former User, they were able to use their former network and connections to set up regular, albeit remote, User Interviews. The UX team and I jumped at the opportunity to validate or invalidate our designs further by involving the Users directly at every step - from macro-level feature development to micro-level interaction models. We were able to interview numerous Users of varying responsibilities and skill levels, discussing the fine details about the workflows and compiling Journey Maps that reflected their expressions and emotions as we reviewed designs. As we demoed UI mockups, we asked them qualitative questions like, “What can we do to make your job easier?”, and “Do you feel an improvement to previous versions?”.
Oftentimes, the Users weren’t vocal about their satisfaction or dissatisfaction on changes to the system; Users simply accepted the changes made as “the way it is”. In an attempt to probe further, we started asking them about their day-to-day schedule on the job.
“What other products do you use”?
“How does [our product] fit into your schedule”?
“How do you start and end your day”?
As we started gaining more insight on their daily activities, we were able to design more empathy-driven workflows based around actual scenarios. With their feedback, we improved how Users were able to flexibly use our product as one of their tools in their daily routine, and the speed at which Users could access the data they needed to. This resulted in positive feedback and increased engagement during the User feedback sessions.
Continuation and Conclusion
As progress continued, User perception of the product slowly turned more positive and hopeful. New feature development started and ended with User interviews, and all workflows were approved by testing and feedback sessions. We’d successfully transformed the culture to User-centered product development.