DesignOps at Cisco Umbrella: Tools & Process

In my article Six months as a DesignOps manager, I discuss how I think of DesignOps having three main pillars: process and tools, team, and delivery. This post is about the first pillar.

You might be wondering, why combine process and tools into a single pillar instead of having two separate ones? My own personal opinion is that they are so deeply intertwined that it makes no sense to split them. A process is, according to the Oxford definition, “A series of actions or steps taken in order to achieve a particular end.” — tools are the devices that help us get there.

Process and tools at Cisco Umbrella

Planning phase

In my experience, a strong planning phase that involves product designers as a part of a cross-functional project team is a sign of a mature UX practice and a predictor of project success. Many designers out there are still trying to make the case for UX involvement in this part of the project lifecycle that, depending on the organization, could typically be driven by product management or engineering.

At Cisco Umbrella, partly thanks to the promotion of Design Thinking as a framework, we are at a place where this is well understood by most teams. A project unit made of a product manager, a product designer, and an engineering lead collaborate during the planning phase to understand customer needs, define opportunity and problem statements, and ideate possible solutions.

Examples of activities carried out during the planning phase are customer interviews, product usage analysis, user journey maps, and brainstorming sessions. If the team is co-located, these activities involve whiteboards, Post-its, and Sharpies. In the case of distributed teams, tools like Milanote and Mural have proven useful to us.

Execution phase

This is what UX/product designers are traditionally known for. Once the requirements have been defined, the prototyping process begins. In our case, we used to start with low-fidelity prototypes to minimize the investment before we were able to test. Now, thanks to tools like Sketch and the work done by our awesome designers to come up with a library of Sketch symbols, we are able to create high-fidelity prototypes quickly while maintaining consistency across the board. We use Invision to create workflows and simulate interactivity at this stage.

For testing, it all starts with a test plan. The designer puts together a list of questions to be answered, tasks, and success criteria. We typically mix moderated testing via customer calls with unmoderated testing via UserTesting.com. Once the test results are processed, we are officially in the build-learn-repeat cycle that can take several iterations.

Once the team has a high level of confidence in the design, it’s time to implement. This is where the designer-engineer hand-off occurs. During the hand-off, the designer typically walks the engineer through the design and then provides redlines or specs using the comment functionality in Invision (we have also been experimenting with Invision Inspect). The same way designers have the Sketch library, engineers have the DPL (Design Pattern Library) consisting of re-usable React components that speed up the implementation process. The designer and the engineer keep in contact throughout this stage.

When the engineer completes the implementation, the designer reviews the result and comes back with requests for tweaks and fixes. We call this “style pass”. Designers who are savvy in HTML and CSS are also able to provide possible solutions along with the requests by playing with Google Chrome’s DevTools. These requests are then prioritized accordingly by the project team.

Top challenges

Of course, no process is bulletproof, so these are some of the most common problems we encounter along the way.

1. Planning the planning phase. Not all projects need a multi-week planning phase. The level of investment should be driven by how defined the space is and market pressure to launch. The problem is that sometimes this is hard to determine at the very early stages before kicking things off.
2. Distributed teams. This has become easier as tools have gotten better, but it’s still something we need to work around, especially when team members are spread across multiple time zones.
3. Access to customers. Our large customers are easier to access thanks to our account managers, but they are usually the buyer and not the user. This changes as we look at the lower end of the market — the buyer is often times also the user, but we find it harder to get them on a call. We just hired our very first Research Coordinator so hopefully, we will make progress here soon.
4. Testers’ domain knowledge. When recruiting random testers from the Internet, we use a screener that can get us pretty close to our personas, but some features just require advanced knowledge of cyber-security and that is hard to find in the wild.
5. Keeping libraries synchronized. Like I mentioned above, designers use a Sketch library and engineers use a React library — this is only effective if the components are the same in both. Synching these two parts of our design system is a key area of investment for DesignOps.
6. Differences of opinion on prioritization of UI fixes . There is general agreement around the fact that functional bugs are a higher priority than style bugs. There is also agreement around the fact that the interface plays an important part in the general quality standard for the product that creates customer trust. However, when deadlines are tight and there is pressure to launch, this tends to create friction between design and the rest of the team.

Conclusion

This process and these tools are the product of years of trial and error and iterating on lessons learned. There is always room for improvement, but overall they work for our organization and our team.

Do you follow a similar process? What tools do you use? Have you experienced similar challenges? I’d love to hear about it.