Design & Research 2 | For: Birgit Bachler
Testing the Prototype and Asking Bigger Questions
In my last post I mentioned that I created a prototype for an online portal to help with the residence permit process. Recently I brought this concept into class and tested it with my classmates to see what they actually thought.
Putting my wireframes in front of real people was incredibly helpful. Since my prototype was mainly focused on the initial application process from your home country, the overall reaction was very positive. Everyone agreed that just having a clear list of required documents and knowing exactly how the whole process is going to happen takes away so much of the anxiety.
They also gave me some really solid suggestions for improvement. One big request was having clear language options and translation features so students can actually understand the complex legal terms instead of just guessing. Another major piece of feedback from people was to simply reduce the amount of steps in the portal. We discussed how to track serious deadlines and manage supporting documents, plus some other features I will explain during my final video.
DESIGN SHOULD BE APPROPRIATE
I want to talk more about that feedback regarding reducing the steps. It makes sense because people always say design should be easy to understand, quick, and have fewer steps. But the thing is, something I learned during my bachelors was that design should be appropriate.
Sometimes stuff is actually supposed to be complex and detailed, especially when lives or major life events depend on it. Look at the cockpit of an airplane. It is incredibly complicated and full of buttons, but it has to be that way because flying a plane is a serious, high stakes task. The residence permit journey is similar. It is a major life event. We cannot just delete steps to make it look cleaner if those steps are legally required. The goal is not to hide the complexity, but to make that complexity transparent and manageable for the user.
One thing I want to make clear is that this current prototype is solely focused on the user side. It is designed to help the students and ease their emotional load. But a real working service design cannot just exist in a vacuum. To actually make a system like this work, we would need to keep everyone in the loop. That means eventually understanding the other side of the screen too, like the magistrate, the MA35, and the embassy staff, to see what their constraints actually are.
This whole testing phase opened up so many bigger questions for me to follow up on in the future. As I dig deeper into this, I cannot help but wonder why this problem is even there in the first place. What is actually causing all these massive delays? Is this friction intentional, or is it just a byproduct of a really old and overwhelmed bureaucratic system?
I will definitely take a look into those questions down the road. But for now, my focus is on polishing this user facing prototype based on the feedback and getting my final video ready.
