Mehmet Enes
Change language
Contact

Problem

An everyday task where the existing object or process makes the work harder than it needs to be.

Solution

Study how the task is actually performed, design an alternative around that observation, and test it as a physical prototype rather than a drawing.

Context

TÜBİTAK 2204-A includes a technology and design field. Entries there are judged on whether a real need was identified, whether the design answers that need, and whether the result was actually built and tested. A convincing rendering is not enough. Something has to exist and work.

This project was submitted in 2025 and was awarded in the technology and design field.

Approach

The starting point was observation rather than invention. Before proposing anything, the task was watched as it is normally carried out, and the specific points where it goes wrong were written down. Design work that skips this step tends to solve a problem the designer imagined instead of the one people have.

From those observations came a short list of requirements, kept deliberately small: what the design must do, what it must not cost or weigh, and who has to be able to use it without instruction. Everything after that was measured against the list.

Concepts were sketched, then modelled in CAD, then printed and held. The gap between a model on screen and an object in your hand is where most of the real feedback came from. Dimensions that looked fine in software turned out to be wrong once the part existed, and each revision was driven by that kind of physical finding rather than by preference.

What I built

The deliverable was a physical prototype together with the documentation the competition requires: the need analysis, the requirement list, the technical drawings and the record of the design iterations with the reason for each change.

The prototype was built to be handled and tested, not to look finished. Choices about material and manufacturing method were made for what could be produced and revised quickly at this stage.

What I learned

Constraints improve design. The requirement list, written early and kept short, ended up doing most of the deciding — when two options were both attractive, the list settled it. I also learned that iteration is not failure. Each version that did not work removed one wrong assumption, and there was no way to remove those assumptions except by building.

Note: this entry is a structural placeholder. The competition record is accurate; the technical write-up still needs the owner’s own detail.

Recognition for this project

Let's build something

Open to research collaborations, engineering teams and competition partnerships.