Wireframes
Faced with tight timelines and limited resources for initial user research, I leveraged the engineering team as proxy users, as they are both the builders and the primary users of the 'Mec' product. Through close collaboration and co-design sessions, I used wireframes to provoke thought and challenge assumptions, distilling their ideas and feedback into user needs and aligning the team on requirements.
Establishing the mental model
I began by mapping core user tasks: Host Info, File Navigation, Actions Execution, and History. Recognizing that engineers spend much of their time in development environments, I adopted an IDE-like layout. This provided a familiar, high-density interface that reduced the learning curve for complex host investigations.
Mapping the workflow
Through audits of available actions and system walkthroughs with engineers, I mapped the end-to-end execution flow within the host environment.
I then translated this flow into wireframes, ensuring the interface supports their whole execution flow.
Through mapping out the workflow, I realized a lack of consistency between host and folder/file actions. I unified the experience by treating "Host" and "Files" as parallel entities within a tab system, having different entry points to action executions.
Stress-testing Usage Patterns
After aligning on the general layout and execution flow, I moved beyond single-execution flows to explore how the design held up in complex, real-world investigation scenarios.
Multiple executions on a single file
Testing previous design in multiple executions, I realized users were jumping back and forth between "Actions" and "History." I iterated on a version where Execution Details became a standalone component visible in both views, keeping the user in the flow.
Multiple executions of the same action