Ideation of Hardware Design

Used Research Methods:

Relevant Research Questions:

• What technological solution at the Fontys Strijp TQ building can be used to stimulate the productive feel of the building users?

After understanding on top level how the user would reach from A to B and iterated on the screens they would be interacting with, the last step of this phase was to understand what hardware the buddy device would use and in what way the hardware would be combined in one whole cast and kept intact.

from A to B - from the desk to the charging station

⚙️ Process

Workshop: Co-Creation

In the previous stages, I discussed with the client the options for hardware. Initially, we wanted to build the whole device from scratch, using Arduino, OLED Display and physical buttons. However, we decided that it would be more beneficial to use a phone instead of Arduino and OLED, in order to save time in the building of the hardware and to keep to have more freedom for creating fast prototypes.

Having in mind that the buddy face was going to be a smartphone and the rest of the information gained in this phase, I created a requirements list that the hardware should follow:

Requirements:

1. The buddy should have 4 physical buttons that have to be at the desk and not necessarily at the charging station.

2. The buddy has to know when it is being charged and (preferably) when it is at the desk. (in Scenario Flows I have covered an option where the buddy knows only when it is at the charging station and the desk should be an input from the user)

3. The buddy has to incorporate three hardware pieces - charger, physical buttons and phone in such a way that moving from the desk to the charging station should be as easy for the user as possible.

I started thinking of possible ways that the three components can be incorporated into a cast (that could be 3D printed). As an inspiration for the cast, I had ideas that would keep the buddy simple until the moment that the physical object is brought to the charging station. I believed that this would inspire people to go often and see their buddies appear in the virtual world.

inspirational images for casts

Workshop: Thinkering

There were two options possible:

1. Moving Cast & Phone - the whole device stays in the cast so that the cast is moved

2. Moving Phone - the cast staying always on the desk and the phone is the only part that is moved to the different locations.

As for charging, I discovered different options that would prevent the plugin of the phone to the socket:

1. Magnetic cable adaptor

2. Magnetic charging plate

charging options

In combination with the charger and the buttons, I created four possible variants for incorporating all components into the device cast:

1. Moving Cast & Phone

   1. Magnetic Cable Charger

   2. Magnetic Pate Charger

2. Moving Phone

   1. Magnetic Cable Charger

   2. Magnetic Pate Charger

In the images below I have shown how the four solutions look and work. (click the image to expand).

1.1 Moving Cast and Phone - Magnetic Cable

1.2 Moving Cast and Phone - Magnetic Charger Plate

2.1 Moving Phone - Magnetic Cable & 2.2 - Moving Phone - Magnetic Charger Plate

Stepping Stones: Comparison Chart

All solutions had their pros and cons. In order to make my decision I created a comparison chart with different criteria I was deciding upon (for example - 3D print design freedom, user-friendliness, durability, etc) You can see the full comparison here:Comparison Chart for Hardware Casts

With the help of the chart, I concluded:

1. Moving Cast & Phone was harder to figure out how to connect to a charger (which was always going to be at the charging station). Those options needed more specific requirements for the cast. (Image 1.1) needed a specific side opening that would be the magnetic connection point for the cable. On the other hand, (Image 2.1) needed not only specific cast measures but also a specific positioning on the charging plates. Based on a comparison chart I did this solution (2.2) was quite good for the user, but it was harder to develop. Another negative perspective was that carrying around the cast could be harder than carrying the phone only. That and the precision needed to connect to a charging plate made it unfeasible for the time being.

2. Moving the Phone might look less convenient for the user at first sight but it was more feasible at that stage of the project. Moreover, I already mentioned the aspect that the cast might be more fragile and bulky than a phone.

Therefore, at that stage, it was better to get hardware for option 2: Moving the Phone

✅ Results & Conclusions

Showroom: Co-Reflection

I showed the designs and my decision (to proceed with 2: Moving the Phone ) to my client and explained what I needed as hardware components. He used the input I gave to research compatible hardware and ordered it for me. See the hardware here: Purchased Hardware Components List.

In the list, the physical buttons are only three because those were the only programable ones. That meant the flows from User Screen Flows needed to be updated in the future.

👣 Next Steps

Because of the fast-moving time, I decided to do not to update the User Screen flows at this stage, mainly because I wanted to have a testable simplified prototype at the end of the project. I knew that I needed to have a dedicated research and learning curve for the software implementation (and most probable learning curve). This decision was discussed with the client and therefore it was decided that the project should continue to the next phase so that there is enough time for high-fidelity prototyping.