Disclaimer: my work as a UX Designer is Forescout falls under NDA.
While I am not allowed to show you screens and interfaces, I can disclosure the activities and workflow I applied throughout the projects I worked on.
While I am not allowed to show you screens and interfaces, I can disclosure the activities and workflow I applied throughout the projects I worked on.
What I'm working on
I'm part of a cross-functional team working on parts of eyeInspect, which provides in-depth device visibility for OT networks and enables effective, real-time management of a full range of operational and cyber risks.
My main focus so far was on the Asset Baselining capability and Network scanning features.
The challenges to face being a UX Designer for such a product are:
- the ability to understand a very technical domain (related to OT infrastructures and ICS networks)
- how to make complex sets of data simple to read and analyse
- adapt the interface to user needs and to be human-centered, so to ease the goals and jobs of the Analysts and Network owners
- how to make complex sets of data simple to read and analyse
- adapt the interface to user needs and to be human-centered, so to ease the goals and jobs of the Analysts and Network owners
An Example of My Process
Research and Info Gathering
All the Whats start with the set of golden questions in mind: Who? Why? How? To do that, I start by recognizing who are the people playing main roles inside the project. I start looking for:
- gatekeepers, holding the information I need to work with;
- internal stakeholders, having other sides of the business in mind and (most probably) an opinion on the goals of the feature/product, as well as functional requirements;
- users, identifying who's going to actually use what I will design.
- internal stakeholders, having other sides of the business in mind and (most probably) an opinion on the goals of the feature/product, as well as functional requirements;
- users, identifying who's going to actually use what I will design.
I usually start by having conversations with them through structured and unstructured interviews. I collect the info received into study documentation (useful to gain knowledge into the domain) and process the feedback using different frameworks (e.g. Jobs To Be Done, Validation Matrix).
This way I can have a better understanding of what stakeholders actually want to achieve, regardless of the words spent on it, never forgetting the words of professor Theodore Levitt: “People don't want to buy a quarter-inch drill bit; they want a quarter-inch hole”. Part of my activity is also give priorities to the collected feedback: how relevant is one goal towards another? Is there a feature (or part of a feature) more valuable for the user? How can we convey the maximum value for both users and enterprise?
(Brainstorming session to discover challenges and opportunities related to a new feature development)
Understanding Personas and User Flows
Before starting to sketch any idea, I try to imagine the actual process the user will go through in order to reach their goal. Initially, the flow is very generic and abstract, but through every iteration it becomes more and more specific and tangible.
Circling from the outer, unspecific to the very detailed version of it, helps me to discover holes and potential challenges in the earlier stages of the design, keeping the reworking at the bare minimum.
Building Personas helps me to have a grasp of the typical user, with their peculiar pain points and goals to achieve. It enhances the liability of the flows and the possibility to center the real value that the feature can convey.
(User flows examples for a new feature)
Wireframing, Prototyping and Presenting
Once I collect all the info and data I need, and answered all of the important questions related to functional requirements, I start sketching low fidelity freehands (usually with the aid of Invision). This first draft is presented and discussed with developers (Backend and Frontend), my Product Owner and stakeholders. This process may be repeated several time to adjust the design and the interactions, refining them to the best (and feasible!) version possible.
Once a satisfying version of the design is reached, and team and stakeholders have agreed upon it, I refine it into a high-fidelity version. The real prototype comes next, and it is also usually the version of the design I will propose to the users to interact and play with through testing.
(Low fidelity prototype in Sketch of a new feature)
Documentation is everything!
Writing documentation is one of the main activities I focus on after design itself. May not be the most exciting one, but it is the base for a strong hand offs to developer and to backup design decisions. It is also fundamental to track what was decided (and why!) to be sure the feature development is really future proof and not person/designer-related.
Documentation writing is mainly based on Information Architecture production. Some examples:
- How to display content
- How the navigation is going to work
- How interactions are taken care of
- Alignment to Design System
- Content and info grouping
- UX Writing
- How the navigation is going to work
- How interactions are taken care of
- Alignment to Design System
- Content and info grouping
- UX Writing
Testing, testing, testing
May it be with internal users, stakeholders or real customers, testing is a omnipresent step. It may appear to be the final, but in a process of design iteration it is not much the case! I apply different techniques to test the feature or part of it, and the nature of the part tested influences much the type of technique I will use.
Some examples:
- Card sorting, to understand priorities in a complex set of information to display in a given (and usually limited) space
- Usability testing, to check wether what I designed makes sense to the user, its limits and challenges
- A/B testing, especially applied on copy
- Contextual inquiry
- Usability testing, to check wether what I designed makes sense to the user, its limits and challenges
- A/B testing, especially applied on copy
- Contextual inquiry
Gathering lots of data without putting them at use is pretty useless. That's why an important part of the testing phase is actually to structure the amount of feedback received into something that internal stakeholders can easily digest. My goal is to ease their decision process by making complex set of data easier to be read and processed.
Is this the end?
Of course not! As I said, the process is iterative and does not have a specific end...until it reaches its best version the team is comfortable to deliver to the user, in order to bring value to the product and to the brand.
