Integrating a prototyping phase into a software application development lifecycle means you can avoid these three common design and development mistakes.
Don’t get us wrong. Paper prototypes and static wireframes are great. We’re big fans of kicking off any application design and development process with a flurry of low fidelity wireframes and some rigorous usability testing. But a successful application design process has to go further.
A good application design project, whether for a web or mobile app, has to include a high fidelity prototyping phase. During this stage of the design process, you can prototype, annotate, animate and generate documentation of a functional UI mockup. A strong high fidelity prototype makes it easier to get client approval, improves team collaboration and helps you avoid these 3 common application design and development mistakes.
Wireframes and prototypes: what’s the difference?
Hold up. First things first, let’s break down the difference between low fidelity wireframes and high fidelity prototypes.
A wireframe is the distilled framework of your app or website. Wireframes are static and low tech: they’re made up of basic shapes, content blocks, image placeholders, etc. A low fidelity, click-through wireframe is often grayscale with a basic UI aesthetic and a focus on information architecture.
A high fidelity wireframe, or more properly an interactive prototype, is an advanced prototype that includes animations, interactions, real data, gestures and transitions. They’re essentially web and mobile prototypes that look and feel like the finished product.
3 common application design and development mistakes
Back to those application development errors that designers can fall foul of. Let’s take a closer look at the problems and their solutions.
Problem 1: The client doesn’t get your design, and you don’t get your client
Hand on heart, the client-designer relationship is always going to have sticky moments. But one sticky moment you definitely want to avoid is a total communication breakdown about a design’s functionality.
This happens all too easily. You walk a client through a static wireframe, explaining functionality as you go. They agree and you think “great, on to code!” Then when the client sees the finished product, turns out that wasn’t what they wanted at all. The narrated walk-through failed to express the properties of UI elements and their functionalities. Eventually the application undergoes a plethora of modifications and ends up looking like Franken-app.
The solution: This mistake is pretty easy to avoid. Present nothing less than the final hi-fi prototype to the client, complete with transitions and interactions. If it’s a mobile app prototype the client will even be able to test drive the UI’s gestures on their own device (if you’re working with an advanced prototyping tool like Justinmind, that is).
Getting client feedback on the finished prototype is the only way not to be trapped in an horror movie.
Download Justinmind today and build incredible web and mobile prototypes!
Problem 2: Users aren’t smart enough to understand your design. Allegedly.
User testing is an essential part of the application design and development process. After all, how are you going to know if you’ve built something useful if you don’t see your application in action with users.
So you might think that any user testing is good user testing. But testing the paper representation of a moving, reactive app is like having a conversation with a tailor’s dummy – it might look kinda like a real person, but it sure as heck feels different.
Paper testing has its place, but it requires a lot of imagination for users to comprehend what that paper sketch will look like translated onto their iPhone or browser.
The solution: You could sit there and narrate every single transition, navigation path, gesture and animation of your user interface. Or you could design those effects into an interactive prototype and do the user testing on the prototype.
Many prototyping tools are integrated with different user testing tools, which means you can share your interactive designs from within the prototyping tool, and get almost instant feedback from user testers round the world.
Problem 3: “The wireframe has spoken and must be obeyed!”
As any design team knows, a wireframe is far from the final word in the application design process. In fact, wireframes should change: they’re there for teams to learn from and discard.
Clients, or even bosses, don’t always get that fact. Their logic might be, “if you spent time doing this you can’t just throw it away. You have to stick with it”. This is particularly true for legacy industries that are struggling to adopt agile practices, for example.
If this happens, schedules can go out the window and, worst of all, you can end up with a project full of some weird typography or the wrong colours.
The solution: Make it clear to all stakeholders that a wireframe is a work in progress. In fact, the dirtier your wireframe the easier it is for non-designers and developers to understand that this is not the finished product. Keep wireframes grayscale, use only image placeholders, and eschew on-point branding.
3 common application design and development mistakes – the takeaway
The application design and development process is rarely perfect. Something will always pop up to challenge the team. But by leveraging prototyping tools correctly and using design phases intelligently, you can avoid these slip-ups and improve application design across the team.