SiaaS(simulation as a service)
An innovative cloud service tailored for mission-critical application
IFTTT Product Design Framework
For this project, I used a design framework I coined IFTTT (if this, then that) Product Design. Its focus is on connecting logical points to decisions made at every stage of the product development process.
Wind River & SiaaS Products
Wind River is a company that specializes in developing software for the intelligent edge. The company was interested in creating a new virtual hardware simulation service product.
My Role
Lead Designer: I was appointed full design ownership over this product.
Problem
Wind River aimed to shift from relying on third-party back-end services and instead create products that would utilize their new proprietary technology in order to compete with other existing services, such as ARM's virtual hardware service. The main goal of this product would be to enable the simulation of a real-time operating system (RTOS) within a cloud environment.
Assumptions v.s. Hypothesis.
I began the project by questioning any major assumptions the Product Manager and I had about user behavior, making sure not to take them as facts.
I conducted a comprehensive audit of our closest competitor's new virtual hardware service, ARM.
3rd Party & Proprietary User Data
As the product was still in its early concept phase, I had limited access to proprietary user data that was directly relevant to this task.
Therefore, I had to rely on third-party competitor data from one of the only comparable products available in the market that targets the developer demographic. In this case, it was ARM's virtual hardware service.
Mapping The Journey
I collected data by identifying collaborative and conflicting information regarding typical user behavior, then mapped it in a high-level workflow.
No Dumb Questions
What do we assume about the user’s behavior(habits and expectations), and why do we assume it? After understanding this question, I can piece together the bigger picture and start to see what we don’t know and why we don’t know it.
Find The Pattern, Start The Conversation
After noticing the user's behavioral patterns, I shared a summary of the key points with the PM. From this point, we would discuss the product around this hypothesis and examine the soundness of the logic.
Re Working The Strategy
After discussing the hypothesis with my Product Owner, we finally felt confident enough to recontextualize the product's goals and MVP approach.
How To Design The Visual Execution
I created a design strategy based on the User Behavioral Hypothesis and our new Product Strategy. This strategy focused on design elements that would provide a high-value and intuitive experience within the vital area of the MVP product.
Run-Time Data Screen V1
Run-Time Data Screen V1
First Pass
Focusing primarily on the automatic project metrics section of the Product strategy, we discovered that the first version oversimplified the run-time data and lacked the context and value of the final result data.
What Is Most Important
After visually executing my first design strategy in the form of a mockup, I was able to identify some mistakes in the initial two steps. Therefore, I rewrote the design strategy to reflect the simplicity of the user's core needs. The user base placed great importance on quality over quantity when considering how this product could be integrated into their pipeline on day one.
Let’s Connect The Dots
Now that I have my direct and simple logic layout, I can start not just putting together mockup designs that "work" for the tasks that need to be accomplished but also designing a product by making very tactical and strategic micro-design choices centered around sound logic.
See It In Action
User Feedback Session
To develop the product concept further, we needed to get feedback from the users instead of just discussing it during our team meetings. To achieve this, I initiated a two-week-long feedback study involving four parturients. The objective of this study was to evaluate the core value of the product rather than its general usability.
Validation Of Hypothesis
After creating a prototype that represented our understanding of user needs, product needs, and design goals, we could begin seeking validation from users.
Building A Session Guide
I strategically formulated my questions to the participants in order to either validate or contest the logic behind the designs. To achieve this, I made sure to ask questions that addressed all the general themes, ranging from "Users require a sense of security while uploading files" to "Users are not concerned about the simulation configuration".
Trends V.S. Hypothesis
I quickly noticed patterns that either confirmed or refuted our initial assumptions and plans. The category became clear and easily understandable, and what truly mattered to the user in a minimum viable product was becoming increasingly evident.
Findings
I plotted the data on a dot plot and identified areas where the MVP experience scored significantly lower than others. I could easily identify the issues and determine why they were problematic.
Product Design Recommendations
From here, I can provide precise recommendations on the most suitable MVP product to achieve higher adoption and user retention rates by seamlessly integrating into the user's workflow.
Additionally, I can identify the features of the MVP where the company can allocate fewer resources and focus more on them in future updates.
What Did I Learn?
The user's main requirement was a system that could help them quickly run and rerun their builds. This would enable them to test their hypotheses and identify why their build is not working as expected. Providing such a product would offer the most value for an MVP SaaS product.
IFTTT Framework
By utilizing an IFTTT Product Design Framework, I could follow a logical process from my research to each element of the prototype design. Having a straightforward and linear process for evaluating product and design strategy will make it easier for future versions to avoid repeating the same mistakes and build upon the findings of the previous version.