How would you design a ...?
I love these types of questions as they allow you to think freely and reconsider why things are done the way they are. A vision for a product is outlined in a question which is then broken down into smaller components and designed from the basis of first principles.
Caveat: If the question states a solution/product that needs to be implemented, then the ‘Why’ (1.a) is less relevant. However, these are nice questions to consider for a more general design approach. They help to identify pain points associated with a problem and remove anchoring towards a certain solution.
Procedure:
- Clarify the scope of the product:
- Why: Identify the pain points that the product is solving. Three common pain points that products can help to solve are:
- Time saving?
- Cost saving?
- Quality of life improvement?
- Who: Is the product aimed at the commercial or consumer market (or both)? Domestic or international market? High-end / Low-end Product?
- What: Are there any specific functional requirements (technical / non-technical) that must be in the product?
- How: What does ‘automation system’ mean in this context? Is this a service that connects an owner to a user or is it a service that allows users to share a single product? Are there any other goals for the product that I should be aware of? Is this for a mobile or web application?
- Layout your design approach:
- Reiterate on business goals / scope of the product.
- Identify the customer base and their user cases.
- Identify the problems that this product will solve for the cases.
- Brainstorm features and evaluate against business goals.
- Discuss the trade-off between features and summarise choice.
- List the goals and requirements: The scope was outlined in (1.) but this provides an opportunity to highlight any additional business requirements.
- Identify user groups and cases: Construct a two-column table with customers on the left-hand side and user cases on the right (there may be multiple uses cases for a single customer or multiple customers for a use case). Explain how the user groups differ and what makes them unique. Fill in the table and to save time, clarify with the questioner to see if they want you to focus on a specific use case/customer group.
- Identify the user problems: What use cases have you identified that the product does not address? Think about specific user groups and what values/limitations they will have towards the product. A third column can be added to the table to structure these problems. Only list the needs/ problems of the user groups at this stage.
- Identify solutions to the problems: Decide on a list of solutions to the problems that you have identified in (5). Are there any solutions that can solve multiple problems? Think of product features that match with solutions.
- Prioritise the feature list and identify trade-offs: Once you have a list of user needs you can begin to prioritise them against business goals or requirements from (3). One way to do this is to categorise the features under several headings: Overall Risk, Technical Cost (quality, time, difficulty), Customer Satisfaction, Business Consideration (revenue, budget, resources) and with one of three priority states: High, Medium and Low. Then pick the most suitable features explaining your thought process.
- Summarise the feature list and justify final choice: What user cases/customer groups do these product features satisfy and which business metrics have you considered to be the most important for the product.
Example:
- Clarify the scope.
- A: Is there a problem that we are trying to solve with the introduction of this product e.g. time/comfort by allowing a user to monitor a number of systems from a central control or a cost-saving system for tracking energy usage?
B: No specific problem, interpret it openly.
A: Okay, I am going to define the purpose of a 'home automation system' as a product that allows users control over an assortment of sensors.
- A: I am also going to tailor this product towards a UK market as a medium to high end product.
- A: Regarding the requirements of the product, are there any specific application that I should be aware of?
B: No, you are fine to proceed.
- A: For control over the system, is there a particular application format that you would prefer e.g. mobile or web based?
B: You can decide based on what you think is best.
- A: Okay, I will make a preliminary choice for mobile for greater accessibility benefits. However, I may change this when analysing the use cases/user groups later on.
- Layout your design approach.
- (Stated during an actual analysis)
- List the goals and requirements.
- A: To summarise my understanding of the question:
- Design an automation system. No specific requirements.
- Create the application for a UK market in the medium to high end.
- Design the system for a mobile based application.
- Identify user groups and cases.
User Group |
Use Case |
Consumers |
Cost saving to track expenses on energy bills e.g. gas, electricity. |
Time saving tool to reduce the need to manually perform tasks e.g. switching on lights. |
Security conscious approach for monitoring house when away e.g. work / travel. |
Businesses |
Groups interested in using a central platform to control and track utilities across multiple locations. |
Consumers / Businesses |
People interested in reducing their energy output for environmental reasons. |
Developers / Hobbyists |
People interested in using the platform to add their own sensors to the network. |
*As you can see we have multiple use cases for the same user group and multiple user groups for the same use case.
A: Is there particular user group or use case that you would like me to focus on from the table above.
B: Any of the groups are fine to focus on, apart from the hobbyist group as we are looking at a mass market appeal initially.
- Identify the user problems.
- The user groups/use case table with the problem column added.
User Group |
Use Case |
Problem |
Consumers |
Cost saving to track expense on energy bills e.g. gas, electricity. |
People don’t have an easy way of tracking utility costs. |
Time saving tool to reduce the need to manually perform tasks e.g. switching on lights. |
Certain household routines are costly in terms of time. |
Security conscious approach for monitoring house when away e.g. work / travel. |
No easy way to monitor property while away. |
Businesses |
Groups interested in using a central platform to control and track utilities across multiple locations. |
Central platform to analyse date trends does not exist. |
Consumers / Businesses |
People interested in reducing their energy output for environmental reasons. |
Energy use is hard to monitor across multiple platforms. |
* Note the removal of the developer group as we are no longer interested in it its use case.
- Identify solutions to the problems
- A: From the problem list identified above, here are the solutions and product features that will help to address the pain points for the user groups and use cases.
- Utility monitoring: This will be of primary importance for the consumer user group looking to save money/time. Such utilities could include: lighting, heating, water and AC control.
- Security: This system (e.g. cameras, motion sensors) will be of importance to the consumer group that is interested in the ability to monitor their property when they are absent. To accommodate this product feature, I am going to stick with my decision to develop the system as a mobile application primarily.
- Database: A system with a database to store multiple properties and cross analyse energy usage.
- Dashboard: A page with widgets to track trends in data would be useful for people interested in seeing how much energy they are saving (from an environmental position or cost saving perspective).
B: Looks good to me!
- Prioritise the feature list and identify trade-offs.
A: I am now going to categorise the features within several areas and decide on their importance:
Feature |
Overall Risk |
Technical Cost |
Customer Satisfaction |
Business Consideration |
Utility Monitoring |
M |
M |
H |
H |
Security |
M |
M |
H |
M |
Database |
H |
H |
M |
M |
Dashboard |
L |
L |
H |
M |
*H = High Priority, M = Medium Priority, L = Low Priority
- Summarise the feature list and justify final choice.
A: Based on the table above I have decided that the home autonomous system should include utility monitoring, security monitoring and a user dashboard. The database feature is more complex and is catered towards the business user group primarily. The product is therefore going to focus on the consumer market initially with three key features. An enterprise product containing additional features of greater interest to the business group could be launched as a subsequent product later on.
B: Thank you for the analysis.