Expand your prototyping knowledge

Instant simulation: 3 reasons for visualizing and testing your applications before coding

It’s common nowadays to see designers, UX designers and information architects doing wireframes when they start doing a new website, but most of them stop right there. The text is presented in a big text format, or printed in several pages of photoshop printscreens. We need a bit of green consciousness and a more practical approach.

Justinmind Prototyper was built to ease this pain. You can wireframe, annotate, animate and generate documentation of a functional mockup. With a fully built prototype, you have most web functions with ease, by drag and drop. Then, it’ll be easier to get client’s approval, and to get all team working on the same project.

It prevents 3 serious problems that affects webdesign and application development:

The “I get what you mean” syndrome

The designer wants an object to do some kind of action, but it’ll take a long time programming. The client, unaware of the problem, approves. Then asks for changes. We know that any project that passes through several modifications ends up like Frankenstein. So, we recommend our users just present the final working prototype to the client, to get his approval, and then start coding and making high-fidelity design, photos and all. That’s the only way not to be trapped in an horror movie.

The “But the users didn’t understand this part” sickness

You are working full-time on a big project, tirelessly. After delivery, the client runs a usability test on paper. And comes with tons of modifications, because the users didn’t understand something which wasn’t meant to be used on paper. Paper testing is very important, but we must understand that it requires a lot of imagination for some users to comprehend what’s that wireframe. How to explain subtle movements, data modification or interactions with paper? It takes time, patience and imagination, but you can simplify the project with a hi-fi wireframe.

The “the wireframe was approved – do it like that” disease

A wireframe is not the layout, but sometimes the client or the boss sees it, and thinks it is. And here comes trouble. This container doesn’t need to be a box, but can be something else that comes up from the designer’s mind. But clients sometimes don’t get this. Or the account team. Or the planners. So, the re-work comes along. Changes and more changes. And the schedule is a long forgotten promise. And worse of all, you can end up with a project all made with some weird typography or wrong colours.

If you want more information about high fidelity wireframes and website prototyping, subscribe to Justinmind’s blog feed or drop us a line on twitter.

Victor Conesa

About the Author

Victor is the Product Manager at Justinmind. His specialties include business analysis, usability, requirements management and prototyping. When not busy doing that he is known to eat or sleep.

Comments are closed.