CLIENT: Intigua
ROLE: One of two designers, working in tandem with the client's internal team of engineers.
TASK: Redesign the core screens and functionality of the initial platform. New features, and feedback on design flaws of their existing system required a fresh design both visually and how content and processes are organized and executed. We focused mostly on wireframes, layout design, and restructuring user flow for new features and tasks.
Learn to Speak IT.
The first part of this project required understanding a very IT heavy feature spec doc.
This involved an open dialogue with the internal team to clarify terms, processes, and the relationship between certain functions.
It often involved spending large amounts of time creating user flows and paths to generate the necessary questions and clarifications needed to continue.
“What is the distinction between Sharing vs. Permissions?
Are permissions a mandatory aspect of creating a service?
Are restricted zones readable (assuming they are not changeable or editable)
If you’re not replacing a zone are there any additional features needed to create a new zone?
If you are replacing and existing zone, are you inherently replacing the nodes on ALL zones? Is it one-to-one mapping? Selectable?
At end of rollout, is deleting old zones a confirmation/choice or automatic?
Does this confirm that everything is OK to move forward - or can there still be issues with replacing zones that are not discovered until it is time to modify/delete replaced zones?
What is the relationship between nodes and services? Nodes are “managed” by services, however it seems like services are a subset of nodes (as in, a single node contains many services)
Possibly missing: Ability to save a list after already sorting from browse view, rather than only being able to create a list? Use case is someone creates a set of nodes from a sort/filter that is interesting, sparks their idea to save as a List.”
User Flows
We began by creating simple, high elevation user flows and presenting them to users and internal members of the team. By working our way from broad to more specific user flows, we were able to ask good questions to better understand the software and create a more efficient design.
After creating dozens of flows that we could easily move around and re-think, we began to bridge user paths together and created more finalized flows of each new feature and how they fit together.
Sketching
Sketching potential dashboard patterns and interactions was an effective way of continuously learning how the software and processes were used by IT administrators. Rough sketches provided a way to get quick feedback and produce multiple designs for review, critique, and learning.
Wireframes
We created sets of wireframes that worked under a consistent left-sidebar menu, and showed how some of the core features and processes could be executed in the context of this layout and design.
These screens demonstrate a solution for a design flaw that forced users to select many servers one-by-one to perform an action on them.