SYNOPSYS. CODE SIGHT
PRODUCT DESIGN / STRATEGY / UX / UI DESIGN / USER RESEARCH / USABILITY TESTING
OVERVIEW.
As the Senior Product Designer for the Code Sight team, I worked directly with the Project Manager, Product Owner and Engineering teams to evaluate, research and design the various enhancements for the Code Sight plugin: A software remediation tool for Developers which integrates into Jetbrains’ IntelliJ (an integrated development environment software UI).
Developers are now efficiently able to: Authenticate themselves, scan local and access remote server-level projects for code-related issues while being able to code more efficiently and being offered remediation tips in order to create bug-free code.
ROLE. SENIOR PRODUCT DESIGNER
DURATION. 1 YEAR, 5 MONTHS
TOOLS. MIRO, BALSAMIQ, FIGMA
Above: The Products & Licenses UI
Responsibilities.
Gather requirements, create personas, interaction designs and present them to a preliminary group of Stakeholders which included: Lead Development Engineers, the PM, Sales Engineers and eventually the larger Development team throughout the design sprints. I iteratively developed these new enhancements over a period of a year to completion.
This was iteratively completed over 1-year which included:
-
Creating personas
-
Creating user stories with the PM
-
Information Architecture of item-layout for the various menus throughout the UI
-
Interaction designs
-
Design Feedback with Sales Engineers
-
Presentations to lead group of stakeholders
Above: The progression of the Products and Licenses UI (old to new - left to right)
Pain Points.
How do we streamline the way our Users onboard and run a scan?
-
Users had a tough time figuring out how to onboard onto a multi-product installation scenario.
-
Users needed a way to switch issue scanning between manual and auto modes.
-
Users are unable to view and select server-related issues.
-
Users had no indication why a scan would fail or be given any tips on how to fix the issue.
-
Users had a difficult time trying to navigate to areas where they would need to authenticate the plugin as the usability was quite dated and lacked clear logical paths to information.
-
Users felt disconnected by the various iconography peppered throughout the UI.
-
Usability in some parts of the UI were complicated and disjointed – users usually found themselves lost when trying to navigate to specific areas.
Feedback Research and Pain Points Analysis.
-
PM and Sales Engineers wanted to alleviate the complexity of the multi-product customer journey and antiquated UI and usability with more streamlined versions – my journey began with speaking to the PM and Sales Engineers who were directly gathering feedback from the users.
-
Examining deltas/variations in stakeholder’s current process versus innovative streamlined version.
-
Extensive prerequisite technology stack assessments with engineering teams.
-
Run and delegate a story-mapping session with Users and Engineering teams separately to understand needs and technical implications.
Above: Remote View - A story-mapping process that I ran with the team which helped break down the various components in the story and allowed the engineering team foresight to future technical implications.
Challenge.
Based on the feedback I collected - the focus was targeted: Win user trust and help introduce and transition them comfortably into the updated UI.
UI Patterns and Process Flow Explorations.
1 - Onboarding experience – Can an enhanced wizard-like flow help guide through the multi-product selection and authentication process?
- The wizard flow is a bit antiquated and may lead to further error-related scenarios (which the development team wants to avoid).
INSTEAD:
A simple layout showing all the product cards in a row (with helpful tooltips) allows the User to better understand their product of choice at a glance.
After selecting a product, the User follows the usual authentication flow and received a visual confirmation of installation.
2 - To visualize that a product was installed, failed or needed updating, iconography was used via a simple green (or grey) checkmark, or a warning symbol tagged with the associated words.
Confirmation of design: This was then reviewed with selected Users as a measure of additional confirmation.
3 - Auto/Manual issue Scanning Modes – Would a radio button suffice as a toggle? Or a tabbed view?
- A segmented control works best for the current UI, allowing users to quickly switch between the two modes.
- Alternate ideas: The radio button is hard to miss due to the density of the UI. A tabbed view brings on additional technical complexity.
Walkthrough of Design Process - Remote View.
• Concept sketches based on conversations with the PM were created.
• Sat in on User interviews to walkthrough their needs for accessing server-level issues which helped better understand their current usage patterns (and what frustrated them) when accessing locally scanned issues.
• Recorded their pain points and prioritized their day-in-the life activities.
• A design thinking session (incl. story-mapping) with the lead engineers was the next step in the process in order to understand the technical implications.
Above: Edge-case scenarios with server and source configuration connection errors had to be well thought out ahead of implementation
Above: In order to aid the Developers during implementation, additional connection and installation scenarios were included in the mockups in order to reduce the number of questions
UI Iterations.
UI ITERATIONS
Above: The full Remote View flow including a vast array of edge-case scenarios to remove surprises and lighten the load on implementation
User Feedback and Handoff.
As the sprint was completed, I held final design reviews with SEs, gathering final feedback and making small iterative changes, then held a larger review session with the Engineering Leads and PM and finally the developers. This stage was essential as it allowed the developers (and PM) to ask any finalizing questions before implementation handoff occurred.
User Testing and key takeaways.
-
After release, I held additional feedback loops to gather initial feedback from our Users. The outcome was quite positive as the regular feedback during the design phases and input from our PMs and SEs were accurate to the degree of what our Users were expecting.
-
Continue to work with PM, Product Owners and Engineering earlier to understand technical implications and deal with out-of-scope features.
Case Study: Authentication Flow and Source Selection.
In order to scan for remote issues, Users would first have to authenticate but also select a source based on the type of product installed.
Above: A breakdown of the various scenarios the main Coverity dropdown would change depending on the installation and connection
Over the course of 1.5 months, various rapid-scale iterations were completed for the Remote View epic, from authentication, to source selection to the point where the User runs and filters through server-related issues. In between the wireframing journey, I connected regularly with the Sales Engineers through various feedback loops to gain insights on the current progress of the wireframes, challenging them and verifying questions on the flow, previous frustrations and how this new UI would help their Users.
