ZTMesh
Role
VP, Design
Project Duration
2021-2024
Managed
2 direct reports
Business Model
SaaS • B2B
Overview
A revolutionary software solution that uses identities to unify on-prem, cloud, and remote devices into a single virtual overlay network for seamless, secure access and management.
Traditional VPNs and firewalls provide perimeter security against outside threats, but leave traffic inside a network exposed to cyber attacks. ZTMesh provides zero trust network access that enables point-to-point connections between authorized users and devices both inside and outside of your corporate network.
Goals
Create an identity and role-based access control list manager that simplifies and extends your networks security beyond its perimeter to each and every individual device in your organization.
Differentiate from market competitors through user experience without compromising on capabilities.
Design new methods for access control list management leveraging device and user attributes.
Challenges
Competition
Amazon
Cisco
Tailscale
Constraints
Budget constraints
Limited headcount
Very little lead time
Knowledge
No experience in IT technology.
Limited SMEs to bridge knowledge gaps.
Proposal - phase 1
Perform market research and compile a comprehensive list of must-have features, nice-to-have features, common pain points, and product successes.
Interview company SMEs to compile a complete list of likes, dislikes, highlights, and feature requests.
Create a design proposal based on market research and internal SME observation.
Use an agile design and development workflow for quick testing and validation.
Design Process
Process summary
Problem space
-
What is the business value?
Who are our users, what are their needs, and what tasks must they complete?
What does success look like for our business and users?
-
Observe your user’s in their natural environment. Keep the process organic for accurate findings.
Ask questions that are as open as possible.
The goal is not to validate your own assumptions.
-
Evaluate, interpret, and weigh findings gathered.
Create requirements.
Create user stories, user journeys, and other preferred guidance documents.
Solution space
-
Information architecture
Low fidelity feature flows
High fidelity compositions
Design system
High fidelity feature flows
-
Early feature concepts were built as interactive flows in InVision or as light-weight locally deployed builds for testing. After proven successful they are handed-off to dev for implementation.
-
InVision interactive prototypes or light-weight locally deployed builds were used to test early concepts.
After features were tested successfully they were handed-off to dev. They were then released to customers where we collected analytics, were given feedback, and conducted on-site studies.
Research
Visit my Design Management Resources page for tools and processes I use to unravel the Problem Space within the design process.
Understand
Feature breakdown
I worked with our CIO, IT team and TPM to form a high-level list of features and their corresponding requirements. Collectively, they had over a 100 years experience using a range of network management tools that included our top competitors.
Requirements were organized in Confluence and prioritized based on system dependencies and customer impact.
Observe
Independent research
I dove deep into competitor product tutorials and documentation. Product trials let me see how they approached complex sequences, interactions, responsive behaviors, and general behaviors.
Unaffiliated 3rd parties were the most useful. They crawled into the corners of the product the affiliated wouldn’t go. I heard more honest and candid feedback that matched well with my own personal experience with the product. They also covered more use-cases and features in depth.
SMEs
I scheduled work sessions with our IT staff to observe them build access control lists (ACLs), how they organized them, how they assigned them, how they managed users, how they managed devices, and various other tasks. During these observations I would ask why questions relating to the task they were performing and ask if there was another way or better way to do that task.
Define
Aggregate and Compartmentalize
Following my understanding and observation phase I was able to harden and refine the early list of features. My new formed perspective from my observation sessions provided new layers to the requirements. These additional details better prioritized our efforts and the interconnectivity between features.
It was now clearer to me how IT admins manage network solutions. I wanted to ensure those years of habits formed managing networks could transfer into our new product. At the same time, my goal was to make network management far easier, flexible, and scale in a way that removed large amounts of manual work.
Ideate
Solution Proposals
Visual distinction
Theme
All our top competitors used light themes. To stand apart from them, I advocated for a dark pallet. It would distinguish us from our competitors. I worked with marketing and formed an approved theme for our design system.
During my observations I noticed IT admins wearing blue-light blocking glasses. They were staring at bright white screens all-day every-day and it was causing genuine discomfort and pain. Personally, I always turn dark-mode on when available for the same reason.
Form
I wanted to further differentiate from our competitors that were using dense UI systems with hard. My design system had softened edges and more white space between UI elements and content clusters. Creating too much space could create UI problems for heavy tasks by pushing important material out of view and force users to scroll more too often.
Reviews
I have worked with these executives and team leads in the past. Getting useable feedback or approvals was 2x faster when presenting in higher fidelity. This included prototypes.
For consistent and accountable reviews I built a review process. This way it was clear where a design was in the approval process, who was required for sign-offs for each stage, and all decisions were formally documented. This level of accountability focuses review sessions when it is understood where and how feedback impacts the design process.
General workflow:
Backlog > Next up > In-progress > Concept review > Content/copy edits > Content/copy edit review > Content integration > Dev ready
Design system
Atomic design
All projects I have managed used atomic design. This methodology improves consistency and accelerates the entire product design lifecycle.
-
They are the building blocks of design such as buttons, lines, shapes, icons, text fields, text labels, etc.
-
A molecule can be created by combining two or more atoms. For instance, an input field and a button can combine to become a search form, which can perform the search function on the interface.
-
An organism is a collection of molecules that have been bonded together to form complex individual portions of the design such as a login page, form, etc.
-
Templates are the glues that combine the different organisms or individual sections to create a complete design. For example, the search form (organism) can be used as a template in the hero section of our home page to fetch user information. Multiple such templates, like a login form, carousel, etc. can co-exist to create an interface design.
-
Everything rendered on the screen at a moment in time.
This is where we test the design systems efficacy. By seeing everything in context, we can go back and tweak our molecules, organisms, and templates to better address the design’s genuine context.
Component documentation
Every designer in the world wants to generate their own unique mark on a product. This often translates into costly custom work for your development team. One of our teams largest constraints was budget. We were not able to higher an army of developers. Instead we had 2 front end developers that later turned into 3.
To increase the speed of our product development process I went on the hunt for existing component libraries. I presented multiple options to our dev team but they were most familiar and comfortable with the MUI system.
I provided our own spin on all MUI components knowing what they could and could not support.
Variants
Used to manage the type of a given components.
Example:
Button variants = Progressive, destructive, or alert.
Properties
Used to control attributes or properties within a component.
Example:
Properties = Label icon, label, or dropdown.
Tokens (variables)
Used to control component values such as corner radiuses font sizes, line height, letter spacing, color, padding, margins, and text strings.
Product features
Dashboard
The mobile ZTMesh client application and the ZTMesh management portal both needed to solve the same user goals:
Provide instant access to the most common actions, status on the ZTMesh environment applicable to the user viewing, and easy access to all other features.
Mobile
• Connect to ZTMesh
• Shared resources
• Secure internet traffic
• Primary navigation
Management portal
• Quick action - create tag
• Quick action - create policy
• Quick action - create token
• Help content
• Exposed primary feature menu
Users
The user home displays all user’s that have authenticated into the organizations ZTMesh. At a glance, portal admins can see every users name, attributes, number of associated devices, and assigned user tags.
Portal admins can customize the data displayed in the table and how the data is arranged.
Live search capabilities and advanced filtering makes finding specific users a breeze.
Devices
The device home displays all device’s that have authenticated into the organizations ZTMesh. At a glance, portal admins can see every device name, attributes, number of associated users, ZTMesh client used, device type, connectivity status, and assigned device tags.
New devices that have authenticated on the mesh are put in quarantine waiting for a portal admin to approve their access.
Portal admins can customize the data displayed in the table and how the data is arranged.
Live search capabilities and advanced filtering makes finding specific devices a breeze.
Gateways
Gateways serve as an entry and exit point for a network as all data must pass through or communicate with the gateway prior to being routed.
On the gateway home admins can quickly identify gateways names, host device names, routes, connectivity status, and if they are serving as a internet gateway.
Gateways are devices, but are managed separately due to their unique feature set and importance within the mesh.
Tags
ZTMesh leverages device and user attributes to build rule based tags. Tags are used to group users and devices. Tags are then used in policies to define their access to resources on the mesh.
There are two assignment models for tags:
Automatic
A tag that automatically assigns itself to users or devices where the tag rule is true.
Manual
These tags are manually assigned to devices or users.
Policies
Policies grant users and devices access to resources on the mesh. Users and devices are identified within policies via tags. This allows policy rules to scale organically impacting new users and devices as they authenticate onto the mesh. This prevents portal admins from needing to write new policies for unexpected devices and users.
Observability
Live charts provide portal admins with all the critical network data at their fingertips. The charts include gateways, users, devices, tags, policies, and token statuses. In addition portal admins can see an activity thread for policy updates.
Logs let portal admins dig out all events recorded within ZTMesh. Enhanced filtering makes it easy to lock in on specific event types, actors, or targets within a defined time span.