Well this is not a new question and this is not the first view upon this subject. Even though am I writing this blog!
I believe this subject deserve a new view! Seen from the perspective of the smart phones and tablets. “Mobility first” is the current mantra and mobility is changing the paradigm within IT business.
I think that I will give some statement just to set the scene of the mobility paradigm.
The user is the king.
We have to give the user something that he wants. If we create ugly apps with complex user experience, the user won’t use out app, they will find another app and make it work for them. This is also the reality for the Enterprise App, if the employer don’t supply you with nice workable apps for employees mobile devices, they will try to circumvent your apps and gain access to the enterprise data using less controlled channels.
Simplicity is the ultimate sophistications
As many great minds have stated simplicity makes great product. With mobility the focus within an app is important, don’t try to make one app cover all our tasks. Mail app will handle mail; calendar handles your day and so forth. It is fine on a desktop to have outlook handling your mail, calendar, contacts, tasks, notes and more. Not on a mobile device.
Bad design kills the app
The user, enterprise as well as consumer don’t want a bad design! There is of great designed app with excellent UX and this is what we want. It is not like all App’s should look like a game, but we do have great design on mail app’s
Prototyping speeds up the communication between the designer, the user and the developer, it also makes the communication better in the way that the end-user and designer gets a way of understanding and responding on the product that the development team are producing. Prototyping also fits nicely with the SCRUM project model as all the parties including the end-user is a part of the iterations within the project.
There are a lot of prototyping tools! What tool to use is completely up to the project or the company! The tools can be divided into some categories that typically are used in different phases of the project.
This is properly the simplest method but it is efficient. It is as close to free you can get. You buy a role (100 wide) brown paper for package warping, some tape and some nice fad whiteboard markers. You invite all the key parties to the meeting and prepare the meeting room by removing all the furniture, setup one or two lanes of brown-paper on the walls. On the meeting you draw the screens with the flow to get a complete storyboard on your paper.
Start project With this kind of tools you can create screenshots and present this screens for the end-user. Some of the tools have the possibility to present on a mobile device and act by changing view when interacted.
4 gen. tools
There is a lot of tools that you can use to make the screen using components that are or looks /acts like the real component. There you can create functional prototypes, which sometimes even have data access.
With high-skilled developers it is possible to create the shell of the app using the development tool. This gives the most rich experience of the prototype, but is might also be the one that takes the longest time.
Brown paper and screenshots is simple to use, and don’t have any major faults build in. the biggest risk is that the end-user, designer and developer still miscommunicate around the functionality. 4 gen tools and development tools handles the functionality as well as the design although the graphical design have the same challenge as developing the final project. But the major risk is when the development start, to discard the prototype and star from the top with a new project, if you just continue you will properly bring a lot of chaotic code as the progress of a good prototype usually is a product of a lot of iterations where some ware on the wrong track.
Yes you should prototype even more when developing mobile apps, B2E, B2B or B2C it doesn’t matter we all want great apps. The don’ts are the same as it always have been for prototyping. Don’t use your prototype code in the final product.