Chapter 3
Designing for Humans
Cisco Digital Network Architecture was engineered to meet three distinct sets of requirements:
Business requirements (which were discussed in the first two chapters)
User requirements (which are discussed in this chapter)
Technology requirements (which are discussed in depth in the chapters that follow)
When it comes to networking technology, it is not uncommon for user requirements to be an afterthought. However, with Cisco DNA, Cisco made a deliberate and conscious effort to consider user requirements at each step of the development process, by leveraging principles of design thinking. Since this design-centric approach is fundamentally different from those taken in the past, it bears explicit mentioning as a separate chapter.
As such, this chapter discusses
Design thinking philosophy, principles, and framework
The Cisco design thinking journey for Cisco DNA
Cisco DNA user archetypes
Technology Versus User-Experience
In 2015, the executive team sponsoring Cisco Digital Network Architecture made an important decision: this new architecture was to be built by applying the principles of design thinking. Design thinking is a human-centric approach to innovation that was first taught by Stanford University in the early 1980s as “a method of creative action,” and later adapted for business purposes at the design consultancy IDEO. Design thinking provides a framework to help teams build products that solve real problems for regular people. Specifically, design thinking is about discovering real human needs, and creating solutions that address those needs, with the overall goal being to “surprise and delight” users.
This design-centric approach was both new and radical for most of the Cisco architects and engineers working on Cisco DNA. In fact, the Cisco DNA architecture team was sent “back to school,” specifically to the Stanford d.school (a.k.a. the Hasso Plattner Institute of Design), to become immersed in design thinking and culture, which they were then tasked with sharing across their respective teams.
As Cisco architects began their training at the Stanford d.school, one of the first and vitally important lessons impressed on them was that user experience is just as important as technology. This ran contrary to the genetic makeup of the engineers, who typically consider technology to be first and foremost. However, to make the point, the instructors cited a famous example: the GE magnetic resonance imaging (MRI) scanner.
Doug Dietz led the design and development of GE’s MRI systems, which in every way were technologically superior to other medical imaging systems of their day, primarily because of their use of magnetic fields (versus the x-rays used by CT scans) to generate detailed internal images.
However, one day Doug was on hand at a hospital to see his new machine being put to use and was horrified to see a young girl reduced to tears as she was being prepared for an MRI scan. The young girl was so distraught that she had to be sedated by an anesthesiologist. It was only then that Doug found out that as many as 80 percent of pediatric patients required sedation when undergoing MRI scans. Clearly, the technological superiority of the MRI did little to assuage the terrifying user experience of most children.
Troubled, Doug attended the Stanford d.school and began studying design thinking. He also began observing and gaining empathy for young children in medical centers, speaking at length with them, as well as their doctors, volunteers, and staff, to better understand their needs, concerns, and challenges.
He soon hit on a key insight: these unfortunate sick children missed out on a lot of “adventures.” This empathetic insight led him to develop a prototype of what became the “Adventure Series” scanner. While making no changes to the scanner itself, Doug and his ad hoc team applied colorful decals to the outside of the machine and every surface of the room to present an adventure to the young patient, complete with a script for the machine operators. These adventures include, for example, a pirate ship, as illustrated in Figure 3-1, where the operator tells the children they will be sailing inside of and have to lie completely still while on the boat, after which they get to pick a small treasure from a chest on the other side of the room. Some doctors also participated in the adventure, dressing up in full pirate costume, much to the delight of their pediatric patients. Doug and his team put together nine additional adventures centered on their MRI machines.
With the MRI redesign for kids, the number of pediatric patients needing to be sedated was reduced dramatically, to less than 5 percent in some hospitals. This lowered medical risk for these young children, as well as allowed more patients to be scanned each day. Overall patient satisfaction scores went up to 90 percent.
They key takeaways of the case study were that superior technology in itself doesn’t necessarily translate to a good user experience, and a poor user experience can actually prove to be a barrier to adopting superior technology. This lesson provided meaty food for thought to the Cisco DNA architecture team.
Design Thinking Philosophy and Principles
Technology, solutions, and data tend to change over time; however, intrinsic human needs do not. People, therefore, are the most constant variables in the design equation.
As a user, you don’t always notice when design is done well, because when form meets function, you simply go about your task and then move on with your day. However, you do notice when something is designed poorly, because it is confusing or frustrating and it gets in the way.
As such, design thinking focuses on empathizing with users and understanding what they need up front, so as to build products they’ll love to use—products that are both useful and usable.
This philosophy has historically been the domain of designers. But design thinking is a universal framework that helps everyone across the organization understand users, empathize with their needs, and collaborate to solve complex problems with confidence.
At its core, design thinking is about solving problems efficiently, effectively, and elegantly. Optimally, design thinking lives at the intersection of human needs, business requirements, and technology solutions, as is illustrated in Figure 3-2.
Design thinking includes a series of principles, such as
Put the user first: To create better solutions, connect with users as often as you can. Their experience is your focus; improving it informs all that you do.
Keep it simple: Strive to produce the most simple and effective product for your users.
Never stop evolving: Evolve your products alongside users’ needs.
Find proactive solutions: Anticipate issues before they arise. Your solutions should provide just the right amount of attention, so they’re never in the way but always around.
Dare to delight: It’s the little details that make the most impactful designs. Sweat the small stuff so that customers want to come back for more—and tell all their friends too.
Build together: To do this effectively, teams must regularly come together to create each tool, platform, and product in alignment.
Cisco Design Thinking Framework
The Cisco Design Thinking framework adapts classic design thinking best practices to the unique context of Cisco’s global workforce, heritage, technology portfolio, management culture, and partner and customer relationships. The result is an original Cisco Design Thinking framework that is innovative yet familiar, forward-looking yet approachable.
There are three phases to the Cisco Design Thinking framework, as illustrated in Figure 3-3 and described here:
Discover: Strive to deeply understand your users and what they need, so you and your team can document a clear Opportunity Statement.
Define: Identify, document, and prioritize the problems to be solved based on the opportunity at hand and articulate a crisp Problem to Be Solved Statement.
Explore: Come up with a variety of potential solutions for the problems to be solved. Your objective is to identify one or more solutions to delight your target users, solve their core problems, and claim the opportunity.
These three core phases are contained by two guard rails that are fundamental tenets of the Cisco Design Thinking framework:
Validate with users: You must constantly validate your ideas and your conclusions with real users. Anything worth acting on—and investing in—is worth gut checking with your target audience.
Make things: It’s not enough to explain your ideas to your users. You must make things to illustrate your ideas and give your users something to react to, validate, or reject.
The three phases of the Cisco Design Thinking framework are expanded in the following sections.
Discover Phase
In the first phase of Cisco Design Thinking, the priority is getting to know your users. By empathizing with users and truly understanding their core needs, current frustrations, and related pain points, you can uncover the valuable opportunities that drive true innovation.
The two main activities in this phase are data collection and insights synthesis. Once you gather information from your users, begin piecing together your observations in a way that starts to explain their behavior. Through user data, develop a clarifying narrative about your actual users and their everyday challenges.
The Discover phase seeks to answer the following questions:
Who are your users? What do they need? What do they value?
Try to learn something new about how they see themselves and the world. Validate your findings with users to ensure that you captured their needs and values accurately and thoroughly.
What do your users need to accomplish?
Dig in to understand the motivations behind their behavior. Why do they choose a particular tool? What does it seem like they really want to do?
What is their experience today?
Observe your users in action. Understand how your users currently deal with challenges, especially when completing specific workflows while using specific tools. When and where exactly do they get frustrated with the current experience? Why? How do current solutions fall short? By recognizing an unmet need or obstacle, you discover clear opportunities to make your users’ lives better.
It’s easy for biases in the Discover phase to alter the trajectory of the rest of the process. Therefore, it is important that the users being interviewed broadly represent the user base and that questions asked are open ended, so as to allow users to describe both their immediate and latent needs.
It’s virtually impossible to predict where key insights will arise, and as such it’s important to thoroughly document findings and data points, as they may allow insights to surface later through analysis. Always focus on user needs and problems. Invest in empathy rather than ideation, and to try formulate—and reformulate—needs and problems from the user’s perspective.
Opportunity Statement
The Discover phase includes many valuable, and sometimes lengthy, conversations with customers. Although these conversations are very beneficial, they may be challenging to summarize. However, a distinct and concise result is needed from this phase in order to proceed to the Define phase. Specifically, the end result of the Discover phase is a crisp Opportunity Statement, which includes the following elements:
[CORE USER] needs to
[PRIMARY NEED] because
[USER-VALIDATED INSIGHT].
Today, [EXPLAIN HOW CURRENT SOLUTIONS FALL SHORT].
For example:
A network engineer [CORE USER] who responds to policy change requests in a complex security environment needs to know how a policy change will affect and be affected by the rest of the security environment before it’s deployed [PRIMARY NEED], because even if they can easily write rules to capture the business intent, they aren’t confident the change will have the intended effect [USER-VALIDATED INSIGHT] due to all the things that make their environment complex, including
Residual policy that’s built up over time (as they don’t clean up rules unless someone puts in tickets to remove them)
Out-of-band interactions with other parts of the security environment
The need to keep adding policies because there are always new threats
Today, they perform human analysis, deploy changes, and rely on rollback to correct errors and unintended consequences. Best case, they proactively test and roll back. Worst case, they rely on their end users to report errors and negative results. This error-prone process is expensive, risky, and often results in customer and user dissatisfaction [HOW CURRENT SOLUTIONS FALL SHORT].
Define Phase
Once you have documented the opportunity, there are likely many problems that were identified and need to be solved. But which ones matter most to your users? The goal of the Define phase is to prioritize three—or fewer—clearly articulated problems that your solution will address on behalf of your users.
The Define phase seeks to answer the following questions:
What are your users’ biggest challenges?
Document the main frustrations and pain points your users experienced and expressed in the Discover phase.
What are some less obvious user challenges that can be inferred?
People often have a hard time identifying the root causes of their challenges, because they tend to accept their current condition as unavoidable. How might you and your team reframe your approach to identify deeper, more insightful problems?
What must our solution absolutely do?
Here you hone in on your solution’s top priority. There usually is a related secondary problem you need to solve as well. Is there anything else you should address?
Have our users validated these problems?
Review your problem statements with users to ensure you have captured them as completely as possible. This helps you and your team get clarity about how users would interact with your proposals.
The main activity in the Define phase is creating a validated Problems to Be Solved Statement. Progress toward articulating this statement may be done by telling a new story—one where the user’s life has improved because they have your high-level, unspecified solution. By constructing and telling the user’s before-and-after story, you’re forced to consider their reaction to the new world and whether it matches your intention. Through the telling and retelling of this story, you’ll quickly identify any holes or irrelevant details in your ideas. This helps determine what’s necessary for your new concept to be successful.
Keep in mind that this high-level narrative is just an iteration meant to uncover which problems to prioritize. It will almost certainly be transformed in the Explore phase—if not completely reinvented.
Problem to Be Solved Statement
This statement directly relates to the Opportunity Statement from the Discover phase, helping you prioritize which key user problems your solution must address. You’ll use this output to guide your creative ideation in the Explore phase—and as a gut check to make sure your concepts explicitly solve these problems.
Most often you will have only one or two problems to solve; in stretch-goal circumstances you may have three. However, attempting to tackle four or more problems at once is a formula for frustration—or worse.
A Problem to Be Solved Statement includes the following elements:
As a result of this, our solution absolutely must
[PRIMARY PROBLEM TO SOLVE],
while
[SECONDARY PROBLEM TO SOLVE],
plus if possible,
[TERTIARY PROBLEM TO SOLVE].
Continuing the previous network security opportunity, a Problem to Be Solved Statement can be defined as the following:
As a result of this, our solution absolutely must
[PRIMARY PROBLEM TO SOLVE]
allow users to see how rules managed by one part of the security environment interact with other parts (such as firewall policies interacting with Internet policies),
while
[SECONDARY PROBLEM TO SOLVE]
enabling them to understand rule behavior before it is deployed,
plus, if possible,
[TERTIARY PROBLEM TO SOLVE]
automatically generate the correct API scripts once the rule was verified and validated so it is easy to deploy across the network.
It’s tempting to try to address each and every pain point in your Problems to Be Solved Statement. It’s also tempting to be vague and open-ended in your Problems to Be Solved Statement. Both of these temptations result in vague, uninspiring prototypes in the Explore phase. As such, it is recommended to limit each solution to solve a few direct, focused problems, so as to facilitate the building of a direct, focused prototype. This way, you and your team focus on doing something important really well, rather than partially solving a broad range of less critical issues.
Explore Phase
At this point, you have a clear sense of who you’re building for, the opportunity at hand, and the key problems to be solved. Now it’s time for the team to start identifying creative solutions.
The key to the Explore phase is to ensure that the solutions developed explicitly solve the prioritized problems documented in the Define phase.
The Explore phase seeks to answer the following questions:
How can you creatively solve the problems you’ve identified?
Time to ideate. Perhaps have individuals come up with their own ideas first. Then share them with the group. Build upon each other’s concepts. Then decide which solutions directly solve the user problems as a team.
What’s the quickest way to test each idea?
After expansive concept generation, create tangible concepts or prototypes. Put these concepts out into the environment, measure response, and let the best concepts win. Aim to set up as many quick experiments as you can to help shape the end-state solution.
Do you have evidence to support the chosen solution?
Testing with real users is critical. If you don’t validate prototypes with users, you run the risk of designing beautiful solutions that lack crucial elements that makes the solution impractical for real life use. Capture direct user quotes and interaction details that prove that your product does, in fact, solve their problems and satisfy their needs.
The main activities in the Explore phase involve ideation around solving your users’ problems, and rapidly building and iterating until you validate the ideal solution. These activities include (but are not limited to)
Brainstorming creative solutions
Brainstorm as many ideas as you can within a defined period of time
Share the ideas among the team
Build on these concepts together
Prioritize the best ideas or features
Sketch low-fidelity concepts
Make your ideas tangible with quick sketches
Use sketches to begin validating ideas with your users
Pick the most promising idea to develop into a prototype
Create interactive prototypes
Create a prototype that shows the key value for the user in a simple flow
Validate with users
Meet the user one on one, ideally face to face
Watch the user walk through your prototype(s)
Validate whether or not the solution works
Note how to improve the solution in your next iteration
By the end of the Explore phase, your team has the opportunity to create high-fidelity prototypes of the proposed solution. This can be a wireframe, a clickable prototype, or a physical mockup. Identify precisely where the proposed user experience solves the problems you defined in the Define phase. And if it doesn’t clearly and completely solve the problem for your users—iterate.
The most common struggle in the Explore phase is that many people are afraid of pitching “dumb ideas” in front of their colleagues. Others lose heart when users don’t love their solutions right off the bat. Just remember, good ideas can come from anywhere. And when you fail fast, you learn even faster. Finding out what works—and what doesn’t work—helps inform your decisions. So you can take significant steps toward a winning solution with more confidence. If you find you’re getting off track, don’t be afraid to pause, step back, look at the bigger picture, and reset.
The Cisco Design Thinking Journey for Cisco DNA
Having outlined design thinking principles and phases, the balance of this chapter focuses on how Cisco applied its Design Thinking framework to Cisco DNA, and the insights, opportunities, and key findings that were revealed along the way.
Cisco DNA Discovery Phase
Cisco began by conducting dozens of in-depth expert interviews with a wide cross-section of its customers, partners, and, in some cases, competitors. To maximize neutrality and minimize bias in the interviewing process, the majority of these interviewees were “blind” in that they were unaware of the party sponsoring the interview (in other words, the interviewees were being asked questions by a neutral third party rather than directly by a Cisco representative). During this phase, over 60 in-depth interviews were conducted by customers and partners representing some of the largest players in the following industry verticals:
Banking and financial services
Manufacturing
IT companies
Pharmaceuticals
Retailers
Service providers
Universities and research centers
In addition to these interviews, Cisco regularly meets with its advisory boards of customers, including the Enterprise Technical Advisory Board (ETAB), Mobility Technical Advisory Board (MTAB), etc. These boards similarly represent Cisco’s largest customers in various industry verticals and provide ongoing feedback and direction for product and technology development so as to meet their evolving business requirements.
Also, teams from Cisco spent time onsite at customer sites performing ongoing observations of how they design, build, and run their networks and the challenges they face in doing so.
Beyond onsite observations, the teams also performed extensive data analysis. For example, while working with Cisco IT, the Cisco DNA team analyzed and correlated over 1455 change management requests and 11,500 incident tickets opened during a six-month period.
During this Discovery phase, as Cisco sought to better understand who its users are along with their unmet needs and pain points, several network personality archetypes began to be manifest. These include (but are not limited to)
The front-line (tier 1) network engineer (shown later, in Figure 3-4)
The firefighter (tier 1–2) network engineer (shown later, in Figure 3-5)
The expert (tier 3–4) network architect (shown later, in Figure 3-6)
The planner (tier 3–4) network engineering manager (shown later, in Figure 3-7)
The point of this exercise was not only to identify the various roles within the networking department, but also to define the responsibilities, needs, motivators, and pain points of each role of network engineer, all backed up with direct customer quotes.
The Front-Line Engineer
The front-line engineer, as illustrated in Figure 3-4, is generally the first individual to handle a trouble ticket, and is usually the least experienced to do so. Front-line engineers typically have received very little training for their role, but at the same time are held under a lot of pressure to perform. Obviously, the more issues that are resolved at this entry-level tier the better, and resolution rates range from 10 percent to 75 percent of issues at this stage—illustrating that the customers who invest more in training, tools, and resources to support their front line reap corresponding benefits from doing so.
Overview:
Entry level
Starter salary
Less skilled
Outsourced (sometimes)
Remote (often)
Responsibilities:
Entry-level support
IT or network generalist
Power user as remote hands (on site)
Commonly outsourced support
Rigidly follows a script
Opens trouble tickets and routes to other teams
Needs & Motivators:
I need a smarter ticketing system for which issues or alerts are routed.
I’m motivated to interpret and document the reported issue with accurate content and context.
I’m motivated to validate or re-create the issue to better understand the issue.
I need a reliable knowledge base to resolve simple fixes.
I need to trial and error some basic troubleshooting techniques to rule out issues.
I need a proper escalation path based on business severity, impact of scale, and issue topic.
I need a knowledge base to be connected to the alerts I’m getting from the tools.
I’m motivated to resolve the issue call as quickly as possible.
Pain Points:
I’m penalized if I don’t put accurate content or enough context into a support ticket.
I’m penalized if I miss symptoms or never get to the root cause.
I’m penalized if I don’t use the right tools (which I don’t know how to use).
I’m penalized if I don’t escalate to the right expert due to misinformation or limited triage.
I’m penalized if I don’t escalate in a timely fashion.
Quotes:
“Noise gets filtered by the network operations center.”
NOCs are “Typically trained monkeys looking for red lights”
“Users always complain that it’s a network problem, but 60 percent of problems end up being application and/or user issues.”
“~10 percent of issues are resolved at tier 1.”—low-end quote
“~75 percent of issues are resolved at tier 1.”—high-end quote
Front-Line Engineer Opportunity Statement:
The front-line engineer needs to trial and error some basic troubleshooting techniques to rule out issues because “users always complain that it’s a network problem, but 60 percent of problems end up being application and/or user issues.” Today, front-line engineers aren’t trained on how to use troubleshooting tools and they are penalized if they don’t use the right tools or miss symptoms or don’t get to the root cause.
The Firefighter
The firefighter, illustrated in Figure 3-5, represents the first level of escalation. When front-line engineers cannot solve a problem, firefighters are the next set of engineers who lay eyes and hands on the problem. They are typically better trained and have more experience than their front-line counterparts, but often share a common complaint that many of the issues they deal with should have been resolved at the first tier.
Overview:
More experienced
More training
Better compensation
In house (more often)
More responsibility, increased access
Responsibilities:
Primary fixer for simpler T1–T2 issues
Basic monitoring and troubleshooting tools
Outside NOC (mostly)
Most problems resolved at this level
Needs & Motivators:
I need a smarter ticketing system that routes issues or alerts with the right context.
I need tools to work out of the box without too much customization.
I’m motivated to assess the issue severity, scale, and impact to escalate it to the right expert.
I need faster communication and effective collaboration with the right experts for severity level 1–2 issues.
I need a tool to allow me to drill down as deep as needed to resolve issues.
I need a tool to provide an accurate topology picture to supplement documentation, which could be wrong.
I need a tool that’s customizable around summary views—a summary each for servers, routers, helpdesk, etc.
Real-time status and events are important.
Pain Points:
The severity filter is too loose and unreliable.
The tools are fragmented and provide no correlation logic.
I receive too much raw data and not enough insights.
I have to deal with too many issues that should have been fixed at tier 1.
Quotes:
“I don’t want to be a data scientist, I’m a network analyst.”
“Documentation isn’t always correct—I need tools to reliably discover and provide me with correct network view.”
“Tools must be multivendor; otherwise there are too many to touch.”
“Tell me if an event is normal.”
“~15 percent of issues are resolved at tier 2.”—low-end quote
“~70 percent of issues are resolved at tier 2.”—high-end quote
Firefighter Opportunity Statement:
The firefighter needs tools to provide accurate, timely, and detailed information so as to allow him to drill down as deep as needed to resolve issues because network documentation is not always accurate and trustworthy. Today, firefighters have to make use of fragmented tools with no correlation logic, which provides them too much raw data and not enough insights.
The Expert
The next level of escalation is typically to the expert, illustrated in Figure 3-6. These architects have the most training, certifications, and experience, but are also the individuals who are trying to focus on forward-thinking planning and thus often resent the constant interruptions that these escalations present. An additional challenge is that much of their expert knowledge is “tribal knowledge” that would be helpful to disseminate to lower support tiers, but is often difficult/impossible to do, as it’s largely undocumented.
Overview:
Most experience
Certifications
Most training/education
In house (always)
Most responsibility: network design and plan
Responsibilities:
High-level alerts and business impacts
Sophisticated tools and tribal knowledge
Scenario planning for complex problems
Big-picture and real-time monitoring
Coordinating large-scale fixes
Multivendor resolution
End-to-end visibility
“The buck stops here”
Needs & Motivators:
I need to first confirm if it’s indeed a network issue because it’s often misrouted to our group.
I need to simulate the problem with actual data points to assess the issue severity, scale, and impact.
I need to interpret the surface symptoms and issues to get to the root cause.
I need faster communication and effective collaboration with the right experts for severity 1–2 issues.
I need a quick fix or permanent workaround for immediate needs.
I need a good orchestration tool across multiple devices.
I need better capacity planning, visibility, and prediction.
Pain Points:
Too many issues that should have been fixed at tier 1 are coming to me.
I’m constantly disrupted from my project work to do troubleshooting.
I spend a large number of time proving it’s not the network.
Quotes:
“It would be great if you can take experience and bundle it into software.”
“What we’re doing now is unsustainable and is tribal knowledge.”
“IT still needs expert eyes to look at tools together with the tribal knowledge to resolve issues.”
“The network operations team needs to spend money to understand the trends in order to do things proactively going forward.”
“At least 50 percent of my time is being spent proving it’s not a network issue.”
“~15 percent of issues are resolved at tier 3.”—customer average
Expert Opportunity Statement:
The expert needs to simulate the problem with actual data points to assess the issue, severity, scale, and impact because he spends a large amount of time proving it’s not a network issue. Today, experts spend more time than they should troubleshooting issues (which approximately half of the time turn out not even to be network issues); their “tribal knowledge” would benefit lower tiers of engineers to root-cause or rule-out potential issues earlier in the process.
The Planner
A final role to consider is the network engineering manager, illustrated in Figure 3-7, primarily responsible for planning future network deployments. They spend considerably less time troubleshooting the network and are more interested in baselines, historical trends, analytics, and capacity planning.
Responsibilities:
Major capacity planning
Network design and architecture
Writing procedures
Creating trainings for all tiers
Daily health reports
Historical trends and analytics
Tools and process improvements
Market trend research
Needs & Motivators:
I need better visibility and analytics about my network performance, availability, and users to address issues proactively instead of just reactively.
I need to stay ahead of market-leading products and case studies to evaluate what’s applicable to us.
I need to upgrade to more robust and correlated tools that enhance my company’s network needs.
I need a tool to audit that what has been implemented conforms to what was intended.
I need better capacity planning tools that also do prediction.
Pain Points:
I have to wait around a lot on other groups to get their pieces done.
Planner Opportunity Statement:
The planner needs better visibility and analytics about her network performance because she is looking to solve problems proactively (rather than reactively). Today, planners are forced to wait on other groups to get their respective work done, as they lack the tools and access to gather and analyze the needed information themselves.
Cisco DNA Definition Phase
Having identified key users and their needs, pain points, and opportunities, the Cisco DNA team proceeded to the Definition phase of the Design Thinking framework so as to identify the key problems to be solved.
Data soon revealed that the majority of budget and time being spent by network IT departments was on change management (~50 percent of both OPEX and network engineer time). Change management was a time-consuming process, where deploying a new service could easily take six months to a year, including six to eight weeks of testing before deployment. Furthermore, the change management process was identified to be highly prone to human error.
Change management was thus examined further, with the next step being to take inventory of change management requests and examine these to see where the most time was being spent. Specifically, 1455 change management tickets from Cisco IT were analyzed to this end, as summarized in Figure 3-8.
From the graph in Figure 3-8, it became evident that the majority of time and effort were spent on a very few tasks, specifically 55 percent of time was being spent on managing just three types of network changes:
Access control list (ACL) updates
Hardware upgrades
New lab configurations
The data was further analyzed so as to be able to subdivide how many changes were standard versus how many were the result of new initiatives; the results are summarized in Figure 3-9.
As seen in Figure 3-9, nearly two-thirds of the changes made were standard changes and only about one-third of the changes were the result of new initiatives. This high degree of standardized changes presents a significant opportunity for automation to provide substantial operational savings to the networking department.
Standard changes (versus nonstandard) are also broken down further according to network platform type, as illustrated in Figure 3-10.
From this analysis, a Problem to Be Solved Statement evolved for base automation, specifically:
As a result of this, our solution absolutely must automate standard changes, while supporting new initiatives, plus if possible, automate nonstandard changes, subject to an approval process.
Similarly, in the area of monitoring and troubleshooting, common needs kept surfacing and resurfacing, as summarized in Figure 3-11.
Not only were customer needs clustered together into common themes, but so too were customer pain points, as summarized in Figure 3-12.
These needs and pain-point clusters were also correlated with Cisco IT case data, where over 11,500 trouble tickets were analyzed to see where typical IT departments spend their time troubleshooting, as shown in Figure 3-13.
As shown in Figure 3-13, the top five areas where Cisco IT is spending time troubleshooting are
WAN
Security
Applications
Wireless
Access
With all these data points as guidance, the Problem to Be Solved Statement for network analytics emerged as:
As a result of this, our solution absolutely must know the performance of (wired and wireless) clients, network devices, and applications, while synthesizing and correlating large volumes of data, plus if possible, guiding/automating root-case analysis.
Cisco DNA Exploration Phase
As the Cisco DNA team progressed to the Exploration phase, they used a variety of techniques to continually gain customer feedback on their solutions. These included storyboards, mockups, workshops, and Early Field Trials.
Storyboards and evolving mockups were continually presented to customers for feedback, as well as Early Field Trial (EFT) software. At times there was quite a bit of internal resistance to sharing early software builds with customers (due to quality issues inherent to these early builds); however, the objective of receiving ongoing customer feedback overrode these concerns, and helped identify additional quality issues along the way.
Nonetheless, the Design Thinking exercise only helps the product teams to identify what the customers want them to build. The massive exercise of determining how to build out the architecture to support the overall solutions remains, and will now be covered in subsequent chapters.
Summary
This chapter introduced design thinking, emphasizing the need and value of addressing the human needs of users by showing empathy to the pain points they experience as they use products and services.
Cisco Design Thinking philosophies, principles, and framework were all introduced, including the Discover, Define, and Explore phases of the Design Thinking cycle. With the objectives of each phase outlined, the focus of the chapter then switched to Cisco’s specific experiences in its application of Design Thinking for Cisco DNA.
Key user archetypes were explored, including the front-line engineer, the firefighter, the expert, and the planner. Similarly, the biggest problem areas to be solved were identified via data analysis, including the automation of standard networking changes and the monitoring of clients, network devices, and applications.
By using the Design Thinking framework, and continually looking to customers for input and guidance at each step of the way, Cisco has embarked on a new approach to engineering networking solutions. It’s an approach that has certainly caused a fair share of discomfort within the product and engineering teams at Cisco, as it represents a considerable deviation from what had previously been the norm for decades. However, this new design-thinking approach is well worth the effort, as it positions Cisco to better meet the needs of its users by showing them more empathy at every stage in the design and engineering process.
Further Reading
Kelly, T., and D. Kelly. Creative Confidence: Unleashing the Creative Potential Within Us All. New York: Crown Publishing Group; 2013.
Getting Started with Cisco Design Thinking—A Practical Guide to Solving Complex Problems Together. Cutler, Matt and Rant Riley. c. 2017 Cisco.