Skip to main content

Product Design

We support the business of Hyletic by becoming experts in our stage group, educating ourselves about the entire product, and staying engaged with user and business goals. We partner closely with our stable counterparts in Product Management and Development.

Team Structure​

Each Product Designer is assigned to an area of our product, called Stage Groups. They learn everything they can about users and their workflows to design solutions for real customer problems.

Product Design Workflow​

Product Designers follow the guidance outlined in the Product Development flow while working on stage group work with our stable counterparts.

Design Principles​

Our design principles can be found with the Pajamas Design System.

Macro UX​

Bringing all of the DevOps stages together in one platform creates an inherently better user experience than using a siloed toolchain. However, we know that we can't stop there. Inside of our product, workflows between product areas must be cohesive and connected, so that users can complete higher-level Jobs to be Done (main jobs).

Proposal​

In Q4 FY22, we will run an experiment that pairs a Staff Engineer with Senior/Staff Product Designer to refine an existing workflow. The Engineer and Product Designer will work together to identify areas of friction in the workflow, and they will resolve them by submitting Merge Requests to the product in real time while pairing. The assigned Engineer will focus on MRs that make larger, more complex product changes, while the Product Designer will contribute smaller CSS changes, documentation, and design expertise.

The initial topics that teams will focus on during the experiment include:

TopicWorkflowEngineerProduct Designer
Auto DevOpsTBDTBDTBD
Kubernetes agentRun, deploy, manage, and observe a container-based applicationShinya MaedaMike Nichols
Install experienceTBDTBDTBD

How will we measure success?​

  • MRs merged: Total number of MRs merged with the Macro UX label.
  • Video walkthrough: At the beginning of the project, the Product Designer will work with the Engineer to create a video walkthrough that focuses on a specific higher-level JTBD and how the current user experience of that workflow supports it. At the end of the project, the Product Designer will create a video walkthrough that shows the improved experience.

Risks​

  • We don't know how much time will be required during the experiment for these pairings to be successful, so we can't predict the impact to participants' regular milestone work, OKRs, and so on.
  • The experiment will focus on fixing friction points identified during heuristic reviews, which means that we won't conduct user research. There is a possibility that we will inadvertently introduce new friction points.
  • The topics identified for the Q4 experiment are not items we hear about frequently in user research, so it's likely that during the experiment we will focus on areas that will not improve our overall product usability score as measured by SUS.

Best practice​

Macro UX will almost always affect multiple stages and feature categories. The premise of this experiment is that fixing one or two issues will not make a noticeable overall improvement to the workflow. To make an noticeable improvements, the idea is:

  1. Figure out the most critical user journey in the Macro UX workflow. When focusing on a specific workflow, it often becomes apparent that there are many ways to use a single feature. This is because, typically, a feature is built to be as flexible, customizable, and adoptable as possible for many different users and organizations. What's important here is to target the most likely path of feature usage, because that approach can expand the potential reach of an improvement.
  2. Document the current user experience as step-by-step walkthrough. Once the Macro Job is defined, documenting a step-by-step walkthrough is the simplest way to evaluate the current user experience. This information is useful for gauging how many manual interventions are required to accomplish the user goal, and it helps us to visualize existing pain points in the experience.
  3. Identify low-hanging fruit and fix it. Given that development resources are limited in this experiment, the pair should prioritize addressing critical and obvious pain points that can be fixed within 1-5 days. Larger problems that will take more than a week to solve should be deferred to a designated R&D group. One improvement idea is to reduce the number of manual interventions identified in the step-by-step walkthrough. Another improvement idea is to improve documentation (including in-context help).