- Scarcity of full-stack experts in BLE+Mobile+scalability: are you able to find, recruit and -most critical- enable such people? There are a number of experts in electronics who already worked a lot with Bluetooth EDR and BLE at firmware level. They come from the makers community, IoT products, or professional RF and electronics engineering in general. They are in the generic family of software developers, but only a very few of them are also used to develop smartphone apps and scalable back-end infrastructures. These two are completely different jobs, despite being required to strictly collaborate and design together. To state it in other words, a developer who owns all the skills, will most likely create something “usable AND feasible AND scalable”. Counterwise, three developers strictly specialized each one in a single discipline, would create something “usable OR feasible OR scalable”, depending on who has the strongest endorsement. So, sure you can include all the professional skills in the same team, but these should belong to the same individual, in order to develop apps with the high quality UX that it is required to reduce the friction and get really adopted.
- Scarcity of experts in multi-disciplinary team organisation: who is experienced enough to be that leader? This is something nobody can study, or buy: it is about self discipline and huge field experience in massively adopted digital products. Designing and developing such a digital product (the contagion tracking app), means the team must continuously explore and balance at least these implications: diffused design patterns, laws, public opinion and communication, politics, economic impacts, scalability, hardware, software, graphics, coordination with other international teams. Just to mention a few. The leader of such a team, is usually connected with the very top of the organization, in order to have a good overview of the entire perimeter of the domain. In the current case, the design domain is at least nation-wide, if not continent-wide. So the team leader should be a government board member, or someone very close to it. In our experience, there is absolutely no other way to organise such a digital team. But pay attention: the team leader must be also a field expert in multidisciplinary team recruitment, organisation and leadership. There is not a single case of successful delegation of these tasks, in management literature, since the raise of digital companies. To put it in other words, we often see such public projects led by someone with great political experience managing a team of experts of the field. If sometime in the past this pattern eventually worked, it won’t this time. We need an expert first, with some political skills and support too. A unicorn, maybe. But it will be crucial for this project to succeed.
- Too high friction for a single interaction: how would you make citizens give up so much of their habits, all at once with a single click on the app stores, without supporting the adoption with progressive and redundant nudges? Out of our experience, political cost apart, the imperative installation (and proper use) of the app, wouldn’t work, even when safety is implied. It would rather introduce all kinds of opportunistic behavior or resistance in the users. Counterwise, when digital companies want you to do something you don’t want, they work on a digital ecosystem.
In the ecosystem the user will find her own preferred (or less frictional) interaction, and her own good reason to enroll. Those reasons could be: being asked in the right timing, or in the right scenario to understand a benefit, or being induced by social dynamics, or in exchange for a reward, or out of a gamified experience. Just to mention some few, very common, approaches that governments haven't demonstrated to master yet. There are literally tons of books on this topic, no need to invent.
- Citizen trails everywhere: every BLE advertisement signal is detectable even if the data payload is encrypted. We need frequent signals to reliably detect contacts. But, if the signals are too frequent, those would be like trails. This would enable third parties to follow and track people without any technical need to notice. Theoretically, someone can deploy custom BLE devices, to monitor public spaces, and use those to locate people inside. Although the IDs in the signals are continuously changing, the precision of the proximity tracking allows to easily re-associate the same smartphone to a new ID, as it would come from almost the same previous location. This could work at least in mid-crowded spaces, like public spaces and streets, where people are distanced by more than 2 meters. It is easy to envision digital marketing practices, like the retargeting, extended also to the physical world. Retargeting is that thing that allows online merchants to follow you everywhere after you clicked once on an item: can you imagine this to the windows you look at, or the people you crossed by, an hospital ward, a private business meeting? Sure, a law could try to deter such a practice, but it would be very hard to find transgressors. We strongly suggest thinking about how to: 1) blur the BLE advertising signals, at least by slightly scrambling the intensity; 2) give up some more of the smartphone’s battery autonomy, by increasing the repetitions of scans, and reducing the repetitions of advertisements. Still, we don’t know if updating the smartphone’s operating systems is enough.
- Difficult development in distributed teams: How would you implement a “continuous integration development lifecycle” (CI), on multiple hardware and platforms, without gathering developers together? Test automation is mandatory to create products at the experience grade you enjoy from Silicon Valley’s giants. But it is very hard to implement a continuous integration when hardware features are implied and you cannot physically touch the device: you cannot simulate so realistic radio signals. Even harder if you are still exploring their format: this app wouldn’t work in emulated devices during development, either Android and iOS. Setting up this project requires much more experience, invention and tools maturation than simple reference apps.