Process
In this evaluation, I look at my modular dock system as a tinkering material from assignments 3.1 and 3.3. While the final concept is a high-end modular hub system, I also reflect on what I learned from building and testing the LoFi LEGO prototype. That matters because the prototype helped me understand not only what the system could do technically, but also how it feels to use, connect, change, and explore. The interoperability assignment also changed how I see the concept. It is not only a modular dock, but a system that can connect to different surfaces, objects, and other tinkering materials.
Affordance: Self-guiding
I think my design is quite self-guiding, although not completely. What helps is that the system has a clear logic: there is one base hub, and the rest are modules that click onto it. That makes the overall structure understandable. The repeated connector language, the magnetic alignment, and the fixed shape of the modules all suggest how parts belong together. During the LEGO prototype, I noticed that this was one of the strongest parts of the concept. Even in a simplified form, it was fairly obvious where the modules should go and how they could be rearranged. This was also shown when I gave it to my sisters to play around with, without giving any instructions or explanation.
The interoperability assignment strengthened this further, because the adapter still keeps the same connection language on one side, while opening the system up on the other side to surfaces and objects. So even when the system becomes more open, it still keeps a recognisable internal logic.
At the same time, the system is not fully self-explanatory, because understanding the technical meaning of the modules still requires some knowledge. A user may understand how to connect a block physically, but not automatically know what the block does, when to use it, or what the limits are. So I would say the design is physically self-guiding, but conceptually it still needs support.
Affordance: Preciousness
My design feels quite precious, and I think that is an important weakness from a tinkering perspective. Because the concept is based on high-speed electronics, power delivery, and safety, it would likely become an expensive and carefully engineered object. That makes it feel less like something to freely mess around with and more like something you should use correctly.
This creates a tension in the design. On the one hand, I wanted it to be modular and reconfigurable. On the other hand, I also wanted it to be safe, premium, and reliable. Those goals make the object less open to rough experimentation. I think users would probably feel comfortable clicking modules on and off, moving them to other surfaces through the open mount adapter, or extending the system with modules such as an Arduino connector, but not necessarily opening the electronics themselves, modifying them internally, or taking risks with them. In that sense, it supports tinkering more through recombination and interoperability than through 'hacking'.
Novelty / "seed power"
I think this is one of the strongest qualities of my concept. The idea came from a very personal irritation: not having the right adapter and being frustrated with oversized, ugly, or unreliable hubs. Because the starting point is so recognisable, the concept is easy to understand. At the same time, I think it has strong seed power because it quickly leads to many possible directions.
Once I had the base idea of "a hub you can build yourself," a lot of new module ideas followed naturally: USB, Ethernet, display outputs, wireless charging, audio, wireless connectivity, extension links, and, later, the open mount adapter. Another logical step would be an Arduino connector module, so the system could also interface with sensors, actuators, and other mechanical hardware and software. That tells me the concept is not just one object, but a system that can grow. For me, that is a good sign that it has seed power (one idea generates many others).
Low threshold / High ceiling / Wide Walls
For this criterion, I think my design is strongest in high ceilings, reasonably good in wide walls, and weaker in low thresholds.
The low threshold is not very strong because the concept is quite technical. Even though the interaction itself is meant to be simple, the system still involves complicated ideas like power, bandwidth, compatibility, and safety. That means a beginner might not immediately feel comfortable with it. Compared to more playful building systems, my concept asks for more prior understanding.
The high ceiling is much stronger. I can imagine the system growing into a very advanced setup with many modules, different workflows, and professional use cases. It does not run out of possibilities very quickly.
The wide walls became stronger for me through the interoperability assignment. Before that, the concept mostly stayed within the world of desk setups, connectivity, and peripherals. With the open mount adapter, the system can be attached to different surfaces, objects, and spatial setups. And with a possible Arduino connector, it could move even further into experimentation with mechanical hardware and software. That makes it feel less like a fixed dock system and more like a platform that can be used in different contexts. So I would still say the threshold is not very low, but the walls are wider than in the earlier version of the concept.
Feedback / Iteration speed
I experienced this criterion in two different ways. At the level of physical interaction, the feedback was quite fast. When I made the LEGO prototype, I could quickly test whether a module attached clearly, whether it felt too tight or too loose, and whether the order of modules made sense. That gave me immediate feedback. In that sense, the concept works well for rapid iteration.
The interoperability assignment added another layer to this, because I was no longer only thinking about how modules connect to each other, but also about how the system can be placed, mounted, or repurposed in relation to other objects and surfaces. That kind of experimentation also gives quick feedback. You can immediately see whether something clips, mounts, hangs, or fits where you want it.
At the same time, I am aware that if this were developed into a real product, iteration would become much slower. Real electronics, high-speed data transfer, thermal issues, and safe power distribution are not things you test as quickly as the shape of LEGO parts. So I would say the concept supports fast iteration in the early conceptual and interaction stages, but slower iteration in the later technical stages.
Ecosystem support
Right now, ecosystem support is still limited. Unlike systems such as littleBits or micro:bit, my design does not yet have an existing community, tutorials, project library, or established user base. In that sense, it is still quite dependent on me as the designer explaining how it works and what can be done with it.
At the same time, I do think the concept points toward ecosystem thinking. It is modular by nature, it can expand through multiple module types, and with the interoperability adapter, it can connect to other materials and systems. If I were to add something like an Arduino connector module, the concept would not only have its own internal ecosystem, but could also plug into an existing tinkering ecosystem around electronics, sensors, and hardware/software experimentation. So the design has ecosystem potential, but not yet an actual ecosystem. I think that distinction is important.
Price
My design would probably be expensive, and I do not think I should avoid saying that. Because I am aiming for quality, safety, reliable connections, and modern standards, this would not be a cheap tinkering material. That makes sense for the kind of product I imagined, but it also raises the barrier to experimentation.
I notice that price connects strongly to preciousness. If something is expensive, people are naturally more careful with it. So while I think the concept could be desirable, I also think the cost works against its openness as a tinkering material. It would likely feel more like a premium modular product than an accessible everyday tinkering kit.
Onboarding / unboxing clarity
I think the onboarding is fairly clear, but it could be better. The strongest part is that the system has a natural starting point: the base hub. That gives the user an anchor. From there, modules can be added one by one, which already creates a kind of built-in sequence.
Still, I also notice that I designed many modules quite quickly, and that could become overwhelming for a first-time user. If someone opens the system and immediately sees lots of options, they may not know where to begin. So I think the concept would benefit from a more staged onboarding approach, for example, a starter version with only a few modules first. That could begin with the base hub and one or two familiar modules (plus the open mount adapter), and only later introduce more open-ended pieces such as an Arduino connector. That would make the first experience clearer and less intimidating.
Instruction / visual language
I feel this is an area where the concept has potential, but is not yet fully developed. The repeated module form, the visible connections, the status screen, and the idea of indicator lights already create the beginning of a visual language. I think that helps the system feel coherent.
At the same time, I have not yet fully designed how the system would communicate more complex information. For example, how does a user see the difference between power and data? How do they know which combinations are safe? How do they tell what is beginner-friendly and what is advanced? And, if the system starts connecting to other surfaces or external hardware through adapters, how is that communicated clearly? These are important questions, and I think my current concept only answers them partially. So the visual language is there in form, but still needs development in communication.
Embedded scaffolding for the process
This is probably one of the weaker aspects of my design at the moment. The system supports use, but it does not yet strongly support learning through tinkering. In other words, I designed a modular object, but not yet a full process around it.
What is missing are things like prompts, beginner challenges, guided first experiments, or ways of helping a user move from simple use to more exploratory tinkering. This also connects to the feedback I got during Session 3 and Session 4. People understood the modularity, but questioned how tinkerable it really was. I think that feedback was fair. Right now, the concept is better at supporting configuration than experimentation.
At the same time, I do think the interoperability direction gives a better basis for defending its tinkerability. Once the system can be mounted to different surfaces, attached to surrounding objects, or connected through something like an Arduino module to external hardware and software, it becomes more than a configurable product. It starts to become something people can adapt, repurpose, and use in unexpected setups. That is where I think its tinkering potential becomes much stronger, even if that process still needs more scaffolding in the next iteration.
Composition / decomposition / reconfiguration
This is clearly the strongest part of the concept. Almost everything in the design revolves around this property. The whole idea is that the user can build a setup by combining only the modules they need, removing them again, replacing them, or rearranging them depending on the situation.
I think this became especially visible in the LEGO prototype, because even though it was simple, I could already test attaching, detaching, and reordering. The interoperability assignment strengthened this aspect even more, because the open mount adapter made it possible to think not only about rearranging modules within the system, but also about placing them on or against other surfaces and objects. A possible Arduino connector would extend this even further, because then reconfiguration would not only happen physically, but also through different hardware and software combinations. So in terms of composition and reconfiguration, I think the concept works very well.
Reflection
Looking back at my design, I think it is strongest as a modular and reconfigurable system with strong seed power and a clear internal logic. It invites building a setup out of parts, and it can grow in multiple directions. At the same time, I also see more clearly now why my classmates and teacher questioned how tinkerable it really is. The concept supports modular use very well, but it does not yet fully support open-ended experimentation in the way some classic tinkering materials do.
At the same time, I do think the interoperability assignment helps me defend that it still can be tinkerable. The concept is no longer only about attaching one tech module to another. Through the open mount adapter, it can connect to different surfaces, objects, and environments, and through a possible Arduino connector, it could also interact with mechanical hardware and software. That shifts it from being only a modular dock toward being a platform for recombination and experimentation across contexts.
The biggest tension in my design is that I want it to be both safe and premium, but also exploratory and flexible. Right now, the first side is more developed than the second. Because of that, the concept risks becoming "a very well-designed modular product" rather than "a truly playful tinkering material."
For me, that is the most useful outcome of this evaluation. It shows that the next step should not just be adding more modules, but making the system less precious, more approachable, and more supportive of experimentation. In other words, I should not only ask, "What can this system do?" but also, "What can people discover with it, connect it to, and build around it?"