Any GitLab team member can tell you that iteration is often the most challenging organizational value to practice. Designing and shipping the smallest thing possible can often feel like it goes against our desire to beautify, polish, and perfect.
The major challenge is in scoping down the initial vision. Sometimes, we may have to cut scope so much that we do not feel we are shipping anything of value. We often feel a low level of shame that it doesn't look complete. We sometimes worry that perhaps even a paying customer will feel this pain too.
In a GitLab Unfiltered conversation about iteration between two GitLab product designers, they talk about our iteration value and some of the challenges teams experience while practicing it:
"What we try to do differently than other companies is that we try to make something embarrassingly small. Sometimes I feel that we get trapped in that thought. We become too focused on minimal. Then we've gone past the point of being viable for our business or valuable for our users."
At best, the goal of making a feature smaller can cause a low level of shame. And at worst, it can create tension on a team that worries about shipping an incomplete vision to customers.
When we try to deliver an MVC (or Minimal Viable Change), a challenging aspect is when the problem feels too large. Perhaps there is a clear boring solution, but the amount of time and resources needed to accomplish it is too large. We ask ourselves: "What needs to be cut while still providing immediate value and paving the way for scalable improvements?" We often address this question with our Product Development Flow, which includes steps to validate the problem or solution and test in advance to minimize the more significant unknowns.
Another challenge is keeping our eyes on the bigger picture while also creating MVC solutions. It's easy to focus on the trees we're trimming at the time, but this can cause erosion in the forest elsewhere if we cut them back too much. Collaboration amongst Product Designers and Product Managers in various stages is critical to ensuring we're not making choices that could have a negative ripple effect throughout the application.
As our team members phrase it, the solution to all of this is to think big, ship small, and learn fast.
Keeping MVCs as C's, not P's
We can balance smaller with viable if we define the MVC. MVC (Minimal Viable Change) is not the same as MVP (Minimum Viable Product). Thousands of little changes make up a product, and there is often more than one right way to solve a problem. An MVC is a singular yet mighty change that takes a step in the right direction to improving the product for the user.
A series of incremental, step-wise MVCs make a feature more complete. It can often take multiple releases to discern if this is the right direction. However, we can also learn more and at a faster pace along the way. The inverse would be to ship extensive features that take longer to build, which means we're less likely to learn quickly.
At GitLab, we currently release in a 1-month milestone cadence. That said, there are many opportunities to learn faster, and we employ a variety of methods to do so. Designers work with Product Managers (PMs) to incrementally de-risk feature ideas. We break solutions down into smaller experiments, all while considering the impact of these experiments both in the short and long term. Our approach requires both divergent and convergent thinking at any given time on an idea. We need to think big to know what small changes will make sense within the broader vision.
Think Big: Define the Vision
Thinking big helps us keep a high-level view of the overall product while exploring ways to learn from small, valuable features that we can ship quickly.
So, what does it look like to Think Big? We start with a known problem and examine how that problem impacts our users, the organization, and the product as a whole. The GitLab product development flow helps us balance being reactive to known issues while proactively identifying UX improvements. Before we begin to generate solutions for a problem we hear about, we first must weigh this problem against all others in our backlog.
This process of determining what to work on first can be a bit tricky at times. However, some of the criteria we consider when we prioritize include:
- New product category work
- Determining the next maturity state for a product category (e.g., viable to complete)
- The envisioned feature is large or introduces a significant change to the product's UX
- Understanding if a JTBD is relevant to why customers buy or use the product
- When targeting a new user or buyer persona
Once we've determined what we want to address first, ideas enter a phase known as Problem Validation. When a problem is known, our ideas for a solution also become more focused. An important signal to watch for revolves around whether we have a shared language about the problem, who feels it, and if we have a collection of reasonably small solution proposals.
Product and UX Research may work together to run studies, user interviews, competitor analysis, and other research efforts within the problem validation phase. We also review data from previous studies surrounding the category maturity and System Usability Score (SUS) results.
As the conversational thread coalesces around a viable range of solutions, we know what to do next. At this point, the idea may move into our Design phase, where we create wireframes and prototypes.
Solution Evolution
At GitLab, nothing should ever happen in a silo. If we are to think big, we need to be sure that we are sharing and collaborating on our ideas with others in the organization and even the wider GitLab community.
The Design phase is often a highly collaborative phase involving at the very least: Design, Product (for insight on business needs, strategy and priorities), and Engineering (to help determine the feasibility of possible solutions). Others involved may include Tech Writing, UX Research, Sales, Customer Success, the CEO, and GitLab community members.
This phase's challenge is not to let the conversation stall or the participants get into analysis paralysis. As the DRI (directly responsible individual) of this phase, the Designer often needs to select a path and move forward.
Lastly, the GitLab Pajamas design system is an excellent resource for providing a solid foundation for UI and design patterns. It reduces the time needed to think through solutions and create visual deliverables for those solutions. Again, thinking about the big picture of being consistent while exploring ways to move fast and ship small.
Once design solutions are in place, the idea can move into the Solution Validation phase to test and validate the MVC with users. Suppose users' feedback proves that the solution is right - meaning, it aligns with the business needs, and it's feasible. In that case, we can move into the Planning Breakdown phase, where it is weighted and prioritized by engineers.
Ship Small: Build and Ship
An aspect of GitLab's value proposition revolves around helping teams release faster and at a sustainable pace. Organizations will evolve their workflows to fit their context. Every process seeks to understand what customers need, deploy the solution, and learn. We utilize our product to its fullest extent to accelerate iterations that converge toward optimal solutions to real-world problems.
We strive in the Design phase to both understand the big picture and define the smallest MVC solution. We use tools like Figma to create prototypes and other deliverables. With Figma, engineers can view coded aspects of the design, saving time in translating design expectations during design hand-off.
Design and Engineering review the proposed solution and collaborate to:
- Ensure the MVC is as small as possible in terms of both the frontend and backend.
- Identify impacts on other areas of the product.
- Discuss possible performance issues.
- Decide whether to implement new vs. existing patterns and UI elements.
Additional design iterations could occur if the idea is still too large to deliver within a single milestone.
Learn Fast: Measure and Learn
Throughout the entire GitLab Product Development Flow, we're learning. We're not just uncovering what needs our users have. We're also learning about ways to improve our methods to make our process more efficient. Because we ship small, our learnings can and should happen quickly. We're always exploring ways to get feedback faster from our users and empathize with their needs. We also dogfood our product, which helps us to experience and identify the same usability and performance pains as our users.
Finally, we regularly:
- Have 1:1 conversations with our users
- Evaluate quantitative data
- Document and tag the qualitative feedback for future reference
- Take action on insights
Conclusion
Practice and theory don't always align. Sometimes, we'll realize later that we could have made something smaller or better. Instead of charging ahead with the plan, we take a step back and make the idea smaller. The ultimate goal of iteration is to release the smallest change possible to learn from real-world usage.
We also embrace contributions from team members and the wider community. In the words of Jeremy Elder: "In the cycle of iteration, there are multiple on-ramps."