Improving programmers lives by removing monotonous tasks
⚠️ This project contains NDA-sensitive information, and some information has been redacted or modified to comply. This does not affect the process, story, or outcomes. Thanks for understanding!
OUR PROBLEM
Customers reported experiencing challenges with transferring the skills required to manage their software environments and needing help with time-consuming and complex tasks. We needed to design a product that helps systems programmers create custom services that codify organizational processes and domain knowledge while also helping junior systems programmers through tasks faster with fewer errors.
TEAM STRUCTURE & Design objectives
Our team was comprised of one design lead, two UX designers (I being one of them), two researchers and one visual designer. Due to the product release cycle, we were given a year to deliver our new product. To ensure we delivered on time, our team practiced a very formal scrum methodology and broke each area of our product down into bite-size scenarios to work on in our two week sprints. Each design team member took ownership of a specific area of the product to design for. My design objective was to create an easy-to-use, one-stop-shop service administration page that allows for system programmers to be able to manage their services from start to finish.
GENERATIVE USER RESEARCH
At the start of the project, we conducted monthly user calls with five sponsor users from the financial and automotive industries. During these calls, I would ask our users questions about their everyday roles and responsibilities to uncover user pain-points and areas of opportunity. We would have research debriefs following our client calls to outline key findings and areas we should learn more about.
Designing products using a design system
After speaking with our users and using IBM's Carbon Design System, I created wireframes of my administration page to share with my design team for critique. I built my designs in Sketch and was able to iterate quickly using the Carbon Sketch library components.
While designing, I collaborated weekly with my development team to understand the technical constraints and complexities of the technology. Being that each designer on our design team was responsible for creating a slice of the experience from scratch, at times it was challenging to align since we all were iterating our designs at different stages. Through daily design team stand-ups, design critique sessions and interlock calls with our development team, we were able to sync often so our work would not fall into silos.
As we evolved our designs as a team, we co-created a Sketch Carbon Library specific to our product so our product pages had similar behaviors and interactions. We were able to adapt the Carbon Design System to fit our product needs.
USABILITY TESTING
It was important to our design process to get user feedback, early and often. This process allowed me to co-create the solution with them. We conducted bi-weekly usability tests with sponsor users to get feedback on our InVision clickable prototype. These users sessions allowed me to rapidly iterate on the Administration page and validate a solution that met their needs quickly.
Administration table with published services in running in the catalog
Users can perform actions on multiple services at a time using the multi-select checkbox
The overflow menu in the table row allows users to perform actions on single services
If a user attempts to take a potentially disruptive action on a service, a modal appears to double confirm the user selection
Product documentation for hand-off with development
After validating my designs with our clients, I created UX documentation to hand-off my designs to our development team. Due to the sensitivity of our product, we were unable to use proprietary software for streamline hand-off. Because of this, we created our UX documentation in Keynote, outlining the functionality of each component and interaction.
At time of development hand-off, I emailed the UX spec to my front end developer and reviewed the documentation to make sure we were aligned before build.
After hand-off of the UX documentation, I established bi-weekly check-ins with my front end developer to facilitate questions and make sure the designs were being built to my specifications.
“I think the options made available on the administration [page] are intuitive so I wouldn’t expect much difficulty. ”
OUTCOMES AND REFLECTION
Since the product release, our team continues to get positive feedback from our users about the design. My one key take-away was that collaboration can sometimes be contentious. Designing a new user experience from scratch, while working with cross functional teams that have never worked with design before, adds a layer of complexity to the design process. Even though I talked to development multiple times each week, occasionally technical requirements still fell through the cracks. This was because we didn't have a single source of truth documentation process established. Many times, we would have team conflict due to miscommunication across the extended teams, causing frustration for all parties. In the future, I feel that it is important to create a process that allows cross-functional teams to input requirements in a single place in order to provide transparency and to improve the collaboration process overall.
