Wie evaluieren Sie Prototypen vor der Implementierung?

In my experience starting with a prototype is too late in the process. You better start making PRETOTYPES: non-functioning prototypes to validate the concept first before investing in (expensive) prototypes. FAKE IT BEFORE YOU MAKE IT!

This is the most important - and the most often botched - step of the process. You want to be as specific as possible about what problems you want to solve, what business functions are REQUIRED to do your business long term, and what the MINIMUM FUNCTIONALITY is for you to market-test your idea. There are numerous prototyping solutions out there today, from simple free wireframing tools like Windows Paint, to complex, partial-function prototyping platforms like Figma. Any custom functionality your business requires should be prototyped and tweaked before you build it and let it loose in the wild. Most importantly, you want these criteria to be simple and easy to understand: make your roadmap and then STICK TO IT!

Both contributions, as expressed above, have some element of agreement to the nature of protyping as a whole (i.e. manifesting ideas tangibly) e. g.: 1. One cannot begin to solve a problem, if, they don't have a clear understanding of what the problem is and/or of why it needs to be solved. Prototyping, is a great means for explorating and analysing ideas, without the need to be rigid with ones design thinking, once a problem has been defined. 2. To effectively arrive at the prototyping stage (once a problem has been defined), one must be open to "play" creatively and to explore ideas ('pretotypes', if, needs must) to effectively consider what design directions to take, to meet the needs of users, to begin resolving the problem.

A great example is the first TESLA. In 2003, the founders of Tesla had an ambitious idea—an all-electric 2-door sports car—and a challenge—Tesla was unknown as a carmaker. To convince potential buyers to order its car, Tesla created a pretotype of what the car would look like. Lotus supplied Tesla with a ‘glider’ Elise—a car without a powertrain—filled with models of key components like batteries and AC motors. Yet with a trivial investment, Tesla was able to show prospective buyers a very close proxy for the final design. To validate the business potential, Tesla asked, 'Will you put down a $5,000 deposit to have it built to order?' From this test, Tesla secured several hundred deposits—a great result to reassure their Investors.

A lot of analysis! In the low Fidelity stage my team looks for the experience from beginning to end. The way it’s going to flow, the functionality, the accessibility the technical feasibility and any guardrail issues. Does it tell the story? This is how we build the framework. When we move to high Fidelity prototypes, we look at the UI, object placement, proper controls, accessibility, colors and branding, standards. There’s much debate over whether a UI designer needs to know front end code. I say absolutely yes. In my shop all we get to look at is Prototypes, a flat design. So to properly test, without running to Dev team every time, my team needs the knowledge on how’s its going to behave on back-end.

In my experience, first-time product owners always skip or mess up this step. They build the bare minimum that fits their vision, but then something shiny catches their eye, and before you even have steady user growth you're rebuilding a piece of the UX in hopes of matching some other team's success...without validating that your customers even WANT the changes you've made! Give your users time to use a feature before you make changes to it. If there are glaring holes, you'll hear about them, especially if you make sure that trusted friends, family, and partners are the first people to test things out. Sometimes the best option is to not change anything because your customers aren't slowed down by your original implementation.

In my experience, as much as people love to give feedback, they also love to know what you'll do with the feedback. So as you communicate next steps, it's critical to be specific. How does each piece of feedback align to the overall strategy for the product? Is the feedback about core functionality? Or is it about a nice-to-have? How is the feedback being prioritized? This helps bring clarity and sets expectation about which feedback will make it forward, how and when.

Having a 3rd party evaluate your findings or analyze the data can be very helpful in providing an alternative viewpoint or perhaps missed outcome or opportunity. I find it most helpful to choose a couple people, one from my specific field to see things I might have overlooked and to validate my findings. The other person I like to choose is from a neighboring field or career that sees things from a different but complimentary perspective. They usually have great insights that add a lot of new value.

An often overlooked part of prototyping is to determine how much of the evaluation process relies on people outside of your company. Are you building a prototype to address a large backend issue that has a closed loop for efficiency and cost evaluation or, something public that requires careful A/B testing or campaign metrics? Even if the problem is clearly identified and you know what the prototype is trying to solve, the evaluation process will be very different and this should be baked into the prototype design to mitigate wasted time and resources.