Back in July, our team set out to build an assistive device that could improve the lives of people with certain medical needs. We decided that our project would be a system that could tell if someone has fallen down, and automatically get them help if they need it. With an aging population, and many elderly people electing to live independently, people falling and becoming injured is certainly a growing problem. Based on our research, it looked like all medical alert devices on the market still required the user to press a button to summon help. But a fall can easily cause a situation where a person might not be able to do this, due to unconsciousness, broken bones, etc.
Incidentally, it seems that Apple agrees with our assessment - the Series 4 Apple Watch, which was only announced yesterday, has this exact same functionality! Of course, it does a lot of other things too, and is in a slightly sleeker form factor, but we are pleased that the problem is being taken seriously and companies are taking steps to help solve it.
While our project was a success in terms of meeting the objectives that we set out at the beginning, we definitely hit some roadblocks along the way and have learned some good lessons about how to approach projects in the future. Firstly, and perhaps most importantly, was the discrepancy between our initial plan and reality with regards to how long things were going to take. We set out to have everything built by, at the latest, mid-August, and it actually took much longer. Thankfully, we *did* include a significant amount of "extra" time in our plan, and we were still able to complete everything prior to the deadline. But this did mean that we had to set aside our ideas for testing it more rigourously in real-world situations, and rely on fewer tests. The takeaway from this is that when budgeting time, a good rule of thumb is to make your estimate and then double it.
Secondly, there was some confusion over group roles. With only two people working on the project, this was not too much of an issue, but it did mean that sometimes one of us was waiting for the other to take charge and figure out a meeting time or set a specific goal. In larger teams, it is imperative for everyone to have a well-defined role, and for one of those roles to be "leader".
As we are both embarking on a final year design project for our college course, this was an incredibly valuable learning experience. We want to thank Element 14 and its partners for providing this opportunity, and also thanks to everyone who has been following along with these blog posts! Here's to many more projects in the future.
Sincerely, Kyle Buchanan and Dan Merluse
Top Comments