From idea to reality: Embracing thorny challenges through prototyping
Expanding the stakeholder landscape
In sprint 3, we came to an exciting finding that monitoring sensor health is particularly important in life safety and environmental security applications. We realized we might have narrowed our target audience too quickly and early to facility management, and needed to identify the correct end-users. We broadened our stakeholder scope by involving CMU police department who oversees security cameras on campus. We also planned to talk to access control and security teams from other schools to explore opportunities to enable prompt detection of sensor health problems in large-scale deployments.
At the end of sprint 3, we identified a few key challenges faced by users that inQ must address to establish competitive advantages.
Embracing bold ideas
As we started brainstorming potential solutions for inQntrol with the user’s challenges in mind, we ran into a “Thoughtland”–where unrealized ideas remain trapped in our minds due to fear of failure. We realized that we were too fixated on modifying the product to meet user’s needs, assuming that they know what they want. However, inQ’s vision of managing all sensors through one platform is a forward move in the market, and our responsibility is to be bold with our ideas, rather than playing safe.
Through synthesizing previous interviews and research, more consistent insights from users began to emerge. To converge findings and generate new design directions, we conducted a rapid ideation session, and grouped our ideas into five main categories:
Users have relied on familiar software for decades. Can we ensure that inQ is intuitive and seamlessly integrates into their workflow to reduce the cost of switching?
Can we provide a “white glove service” to help users implement and configure new sensors in the software?
Could collaborating with other software be more beneficial for inQ than direct competition? What if inQntrol (inQ’s software) functions as a third-party plugin that offers more comprehensive insights into sensor management data.
Lack of manpower is the biggest problem faced by facility managers so far. Can inQ alleviate the workload on humans by providing smart grouping and prioritization of critical alerts to be addressed first?
Can inQ ensure interoperability among different systems and departments across the campus by providing a holistic report of sensor health and total savings?
Our plan is to further explore these ideas through low-fidelity models for pilot testing with users.
Pretotype. Experiment. Testing.
Pretotyping involves conducting low-risk experiments to validate initial ideas for solutions.
In sprint 4, our team employed pretotyping as a research through design approach to translate conceptual ideas into more concrete artifacts. Each team member took charge of one of the five directions and developed pretotypes to validate the demand and needs for proposed solutions. Through stakeholder interactions, this approach could help advance our understanding of the problem space and discover possibilities and gaps that we may have missed.
During pilot testing with our faculty advisors, we learn that through pretotyping, we should:
- Stimulate conversation with users in order to understand their mental models. Asking questions like: “what do you think should happen” can help users think aloud while interacting with the model.
- Focus on the value the solution brings to address users’ underlying needs rather than testing specific features or usability.
- Use parallel prototyping to open up conversations to obtain authentic feedback as users are presented with more than one solution to compare and evaluate.
For the rest of sprint 4, we decided to prioritize testing a few ideas with users to reduce their mental burden and facilitate easy conversations. Two of the ideas we want to validate are addressing alert fatigue and establishing role-based dashboards. To tackle alert fatigue, we plan to test an AI-based solution that groups alerts automatically based on different metrics such as time taken and money saved. We aim to understand if users find such alert groupings helpful in streamlining their workflow. Similarly, for the idea of setting alert thresholds, we want to find the best practice in reducing the number of alerts received. Additionally, we want to test the effectiveness of curating a personal dashboard to prioritize information for different roles.
From idea to reality
We are excited moving into Sprint 5! We plan on conducting more idea validation sessions with actual users. Meanwhile, we want to continue developing and parallel prototyping our pretotypes to validate all five directions. We hope soon we could converge on a clear direction and be fully prepared for the upcoming spring deliverables.
*The work and knowledge gained from this project are only intended to be applicable to the company and context involved and there is no suggestion or indication that it may be useful or applicable to others. This project was conducted for educational purposes and is not intended to contribute to generalizable knowledge.
*This project is not intended to contribute to generalizable knowledge and is not human subjects research.
