Alex F

When learning about new technologies, I take notes and keep track in an outliner/writing app.  This also applies to meetings, customer feedback and more.

I also often take notes in a notebook (and then put it in a writing/outlining app).  Here I have notes on a complex policy structure.  It is important to understand how something works in order to fully understand what may be wrong with it.

Notes on how SSL certificates are managed across applications within our application.

With 4 different policy types applied in various combinations to each individual host or groups of hosts, the potential for having 10s of 1000s all conflicting within a system is very real.  To understand the system I needed to map out policy relationships.

With 4 different policy types applied in various combinations to each individual host or groups of hosts, the potential for having 10s of 1000s all conflicting within a system is very real.  To understand the system I needed to map out policy relationships.

With 4 different policy types applied in various combinations to each individual host or groups of hosts, the potential for having 10s of 1000s all conflicting within a system is very real.  To understand the system I needed to map out policy relationships.

This maps out the general policy workflow along with typical tuning points (right hand side)

TOC from a policy report for stakeholders discussing the problems from a specific customer, where points of conflict can occur, and low-level details of a new policy engine that will fix and simplify (SSEF)

Some screen shots of problem areas in the products legacy policy UI

Intro to policy deconstruction

The appliance configuration options structure for a single appliance.  The goal was to bring the configuration options for ALL appliances in the ecosystem into 1 UI.  As you can see, for a single appliance the configuration options were spread across 6 different UI areas.  It was important to understand this structure before we rebuilt it to include more appliance types and 4 times more configuration options.  This was a structure and method that was confusing and not scalable at all.  But if you do not understand how it currently works, then you cannot accurately provide answers to "the 5 whys."

Mapping out potential workflows for common configuration tasks.  This helped understand what types of workflows would have to be supported across all appliances and where workflows might be replicated or consolidated across all appliances once management all came under a single appliance UI.

Visually mapping out current appliance configuration options and workflows.

Visually mapping out current appliance configuration options and workflows.

Visually mapping out current appliance configuration options and workflows.

Mapping and cross-referencing Section 508 guidelines and requirements with WCAG 2.0 and internal Cisco disability guidelines along with descriptions and examples for each requirement (software only, not hardware as it did not apply).  This allowed me to not only understand the individual requirements but map them across standards, assign team responsibility for each requirement (UX vs UI, for example), and eventually provide this as a reference and compliance guide for all of the UX teams across the Cisco Security Business Group.

And early persona.  I was tasked with redoing these personas.  My refinements occurred in further steps in the Design Thinking process, where you can see how they developed over time.