Justinmind Blog

Wireframe & prototype apps and websites for iPhone. And the library is free for all the Justinmind users out there! Just download it.
We hope you’ll enjoy wireframing with our widgets. We try to include all the necessary elements and to make widgets as faithful as the original iPhone design! We hope you’ll like it, feel free to contact us if you want to add your own iPhone widgets, so all the community can enjoy your work.

iPhone widget library for Justinmind

See the library component list: Component List

Example of a iPhone prototype: See prototype

Download the iPhoned widget library and try it yourself: Download Library

Some big projects done with Justinmind Prototyper involve more than one person. Sometimes big teams work together to create something, and thus collaboration-management is a very important feature of our wireframe authoring tool.

Keeping the same design code throughout the project
Widgets and templates can be used to maintain the same styles, colours, events and structures which are repeated throughout several pages. The main designer can create the objects following the brand guidelines, and other users will simply drop them on their canvas, without any confusion of mistaken sizes, colours or deprecated styles. Also, it improves work, since things don’t need to be redrawn.

The filetypes for templates, masters and widgets are accepted in most Justinmind Prototyper versions, and are small, making them shareable by mail, network or even personal messaging systems. Also, most common media types, such as jpg and gifs, are accepted by Justinmind Prototyper.

Creating widget sets for determined projects
Let’s say you have a project with many, many screens, but just one designer. He can create the widget set that will be used, with specific properties, and several users can easily follow the guidelines.

There are widget sets for specific hardware and interfaces, such as iPhone or Android. With them, you can simulate all the UI of the phone in your computer, and specify the development of the software. You can always find more widgets at Justinmind.com.

Comments and requirements management
Not everybody’s comfortable with Justinmind Prototyper’s ease of use, but still have changes and modifications to do in the wireframe or prototype. Sometimes, the clients want to add their views and opinions, and they’re able to do that with JP Requirements Management feature. They can comment and link their comment to any specific feature. Also, they can specify features or requirements, and this can be related to any version of the software. Of course, these comments can be exported and organized in personalized .doc templates, for reports, summaries and analysis.

A team works better when it communicates better
Every manager knows the importance of being understood, and that details are organized and overseen. So, using Justinmind Prototyper to optimize teamwork is the best option to assure everything will run smoothly and within the deadline.

From wireframe to final development specifications, your team will work better with Justinmind Prototyper.

Those that already create a prototype before investing too much time in any problem already know: there are several blind spots and mistakes designers do unwillingly. And those can be avoided by testing and validating the wireframe through several phases, from drawing to high fidelity prototype.

Most of those are common, but some can be really difficult to detect without a test:

Users getting lost while navigating
You know all the content of your site. So, you’ll never get lost, and you always know where you are. You know the site by heart, since it was a wireframe. But should this section really be where you think it is? Leaving hints like breadcrumbs or having colours for different sections is important, but also is testing content categorization.

Blindspots
You think everyone will look at your red-and-yellow banner at the centre of the screen, don’t you? Sorry, they won’t. And it may also happen with other objects. Sometimes, designers and clients become so obsessed with a colour or a photograph that they’re sure everyone will pay attention, but due to several different factors, it doesn’t happen. Testing can uncover some of them.

Standards exist for a reason
It may happen that you have a great idea for a different navigation model, direction or structure. It may be a breakthrough, but also can be a big flop. There’s a reason because most sites today have two or three columns, the main one is bigger, and a big header with navigation on top: it’s become a standard, and everyone is used to look for them there. If you need to create something different, it can be great. But, please, test it until you’re sure users won’t get confused and leave your site empty.

What to do if I find a problem?
If you’re using Justinmind Prototyper, add a comment, and the Ux designers and product managers will know there are some mistakes. Correct them. Adjust. Test again. Rinse and repeat. It always works.

Keep it easy – overexplain if needed
Remember that not everyone come to your website from the homepage. With the increase of Google’s visitors, the number is always bigger. So, it’s important to explain to them what your site is about, and what to do when they get there.

Help your users. Think of them as a foreigner in your country. Although they want to be kind and start a conversation, you created the place, you know the rules and you must teach them (in a kind way, no one wants to be bossed around) how to behave in your website.

After finishing your project and presenting to the client, sometimes it’s needed to do usability tests with a prototype, to understand real users’ needs. So, you can export your hi-fi wireframe into HTML, or even test it remotely using Justinmind Server.

Before doing the test, is recommendable that you:

Prepare the test questions

• If it’s an eCommerce site, you’ll need the users to buy something.
• Maybe have them fill a form and submit it correctly.
• Ask them questions about information on the site: ex: “how much does the book Hamlet costs?” or “does this site ships to England?”.

Note that these tasks should be the ones users will do more frequently, and pay attention to their mistakes or if they don’t understand something. If it happens to them, may happen to other users.

Do not include hints, or help them complete the tasks. It’s important to understand what users feel difficult to do.

Start with the easier tasks. It helps them improve confidence, and sometimes users get nervous when they cannot complete the first task. Reassure them that there’s nothing wrong if they make mistakes. It’s their job to find the potential mistakes, anyways.

Remember always that when a user fails a usability test, it’s a win situation: you can correct something that can be very harmful and dangerous: investing time and money in a bad usability website.

Finding users for a usability test
It’s important to find potential users to your site. Do not test your social network for old ladies with your graphic design friends. They use computers and have different tastes, goals and approaches to a website.

It’s not needed to test with more than 5 people, according to some researchers. Most of the conclusions with more people are repetitive and come to the same results, so 5 is considered the magic number.

During the test of your wireframe
There’s no need to help the users. If the user cannot complete the task alone, it’s ok. Note that down, and reassure him that there’s no problem. Everything users do may be important, from what they do to what they say during the test. Note that down. After the test, ask users why they’ve done something you didn’t understand.

After the test
Tell them it’s important to understand the tasks they couldn’t do, and then improve the site. Explain them how it was designed to work, because you can find more conclusions there.  They must know their feedback is important.

Get all the conclusions and write a report of changes that should be done to the prototype, and, if possible, test again.

It may sound contradictory, but going straight from wireframe to code is not the best way to finish your project early. Normally, clients make several changes when they see the actual design, with colours and real text. Many of those are structural changes.

Structural changes are never easy to make, because they can affect all the project. So, if you have a prototype, it’s easier to change things and don’t have these modifications destroying everything.

Prototypes are like rehearsals of a play, or a movie: you can do them any way you want, modify, edit, test, and after everyone agrees, you do it smoothly and perfectly.

Probably, some co-worker will say a prototype isn’t necessary. Or maybe a boss, who wants to save money. But they will be the first ones to start changing the project, the scope, the budget, the features of the site. And as you add them, it will become a huge mess. Big projects that fail often go this way.

Explain to them that the site is a building, or a statue. You can first draw it, then you’ll create a model, with soft objects, like clay or wood. Re-do it bigger. Change things, see if everyone likes. Then you get marble, or diamonds, or any kind of object in which you don’t want to do any alteration. This is the way to a masterwork. If you want to change the stone pillars of a huge building, you’ve got a problem. If it’s only a model, there’s none. And it costs just a fraction to change a pebble from here to there, comparing to a big rock.

Never underestimate the headaches a badly planned project can bring. People say that every minute spent planning means two minutes you save re-doing something. So, next time you start a web project, or software development, think twice before skipping your prototype phase. Every detail specified, every feature tested and approved means you won’t have to re-work that later.

Got a new project? Justinmind Prototyper until you got the final ok. Then you get your coding skills, your graphic design, your real text edition, your effects. Because you know changing code is hard, but wireframing with Justinmind Prototyper is easy.

There is a tendency nowadays of doing HTML prototypes for client presentation or to test projects. This is a more realistic approach to paper, but it’s very much more time consuming. Justinmind is a tool made to join together the functionality of a HTML wireframe with the ease to use of diagram tools such as Visio and Omnigrafle.

There is not a conflict between HTML wireframes x paper. Both have problems: not everyone has HTML knowledge, it’s time consuming and people tend to spend more time checking for HTML mistakes than for thinking about the final product. Paper is not the real thing. Cannot simulate very important situations, and don’t work in several tests.

With Justinmind Prototyper it’s possible to generate this HTML just as if it was a diagramming tool. The final code should be created after approval, but it minimize changes and reduce production costs. This way, you’ll have:

• An added value to the client, who’ll see something very much alike the final project, with interactions and maybe a mockup of the final layout.
• Improved client communication. The client will be able to see his web or program working. He’ll understand the links, the effects, and will make his changes before coding phase.
• Communication through demonstration means that every specification will be clearer, leading to a smoother coding phase.
• Dump the poor ideas before. It’s better to lose an hour creating a prototype of that functionality than loose a week coding something that won’t get to the final project.
• Simplified implementation. When everyone knows what to do, and everything’s well documented, the final phases go easy and smooth.

Easier to convince people of the value of a project
Not a long time ago, when people asked for a layout of anything printed, they received something drawn, painted with ink, glued, copied and pasted with scissors and several other objects. Then came digital desktop, which changed forever graphic design. Now, before buying a great project, you see a mockup of the printed version, with almost final quality of colours, shape, etc.

Why selling a website with a static page?

We know coding can be hard, and much more for applications, but that can be simulated to near-real experience nowadays.

You have to build one car to test, then mass produce it
When a car factory builds a car and have it tested, this prototype can be approved, modified or abandoned. They can also be virtually built and simulated with software nowadays, can’t they?

That can now happen to websites and programs.

An HTML prototype is like a real built car. It’s hard to create, but it shows all functionality to perfection. If it works, they’ll build more. A prototype created with Justinmind Prototyper is like a virtual car: you can test almost everything, and simulate to the bones, having all the advantages, but with much less effort.

Every project plan has some elements in common. Before starting to create the prototypes, drawing wireframes or hiring coders, it’s important to:

1.    Define what you will do
2.    Divide it in small tasks
3.    Define who’ll do each part
4.    Assign an amount of time to each one of them (start and finish dates)
5.    Create a way of measuring progress
6.    Register tasks finishing dates
7.    Tasks needed before a given task begins
8.    Create a timeline
9.    Assign someone to control and manage everyone’s activity

Avoid failing the project by careful planning
There are several reasons why projects fail, and most of them can be avoided by careful planning.

Not enough time or money: Without proper scheduling and budget control, it’s easy to have a project dismissed due to lack of resources. Besides, even when they not fail, the final project can be sloppy, with bugs or dysfunctional if this kind of planning fail. That’s why it’s very important to have everything that’s needed clear on every team member’s mind before starting.

Poor communication: A client asks for a simple website, and then wants to add functionality that’s hard to implement; the designer makes a wireframe awful to code; the coders say it’s impossible, but it isn’t. Everyone saw that situation sometime, and most of the time it’s a problem of communication. Websites and software can be pretty complex sometimes, and words aren’t very specific to describe them, or jargon can be very hard to understand for non-technical people. It’s important to always speak clearly and make sure that everyone understands what’s being expected and required from them.

Inadequate testing: Most of the time, due to problems in timing. Since launch date is so close, people decide to simply launch it, and then fix the errors. Sometimes it works (as Google Beta apps do), but others they fail miserably. Testing should be done, and it’s even more crucial for first time launches.

Lack of quality: Those come often from time management problems. Not enough time to test, to guarantee that everything is just as it should be, so we’ll correct everything as the problems come. Sometimes works, sometimes it’s a trainwreck.

All of those problems should be avoided with careful planning.

Have you ever created an early project plan, or a simple wireframe — maybe to get approval for the project — only to find it unworkable when you started tracking progress? With the right start, you can ensure that the plan you create at the beginning of your project is an effective management tool throughout the project.

The first step is to understand all the requirements. In this stage, you’ll need to gather everyone involved in conceptualizing what’s going to be done, and write that down. You can draw a simple wireframe and sketches of the final project too.

Business Analysts and Project Managers are vital for this, and also Key Users, to understand what they need and want from the final product. We recommend a team of 5 people maximum, to avoid empty discussion and eternal meetings.

They’ll get together and write the first list of requirements needed, as much detailed as it can be. The Requirements list will be a briefing of the project, for developers, designers and coders.

Understanding the audience
The users of the projects must be studied. The usage, too. How people will use it is very important and can decide the success or fail of any development project. It is very important that your project is useful and severs a purpose for your selected audience.

People are not equal, and not everyone use software or websites the way you do. It’s important to step on the users’ shoes and understand their thinking, needs and values. After all, they are the ones who’ll use it.

This is why we recommend to have key users involved in the planning phase, and, if it may be, future or potential users.

Creating killer content
It is very important to think about what really interests people and how will they react to what you are offering them. Earning peoples’ attention is normally a one timer: if they don’t get interested in the first time, it’s probable they won’t be a second one. So, think about your users and amuse them.

Designing for human beings – help people
Some people just cannot focus enough on design, on thinking how form and function interact and how people interact with them. There are several unconscious and sub-conscious elements that can change users’ perceptions about a website or a program, and simply helping them find the specific button, or understanding how the program works, or even simpler: having the application have a pretty look. The design can improve a lot with the use of wireframes. Nowadays, there’s no excuse for having a poor looking app.

Technology – it cannot be possibly done
We all know the story of the beetle that cannot fly, according to aerodynamic laws. However, sometimes project fail because someone thinks that creating something is possible, or can be easily done, but actually takes too many work hours or too many people involved or some technology that’s not currently available to all. So, it’s very important to plan everything and discuss with technicians and experts to understand what’s going to be done.

Project Management – following the plan
Even when we get a map, sometimes we get lost. Why? Because somewhere during the travel, we forgot to keep track of where we were. This is to show how important it is to control the evolution, the iteration cycles, the steps and accomplishments. They’ll avoid the feeling of being completely lost, of not knowing where you are and how you got there in the first place.

We suggest some basic designing steps to increase speed and facilitate the creation of your wireframe:

1 – Use some sort of grid. For example, 960 framework. This is very commonly used by developers, and give some sense of proportion to your project. It may also help the coders further on. There’s a template of 960 framework on Justinmind’s blog.

Most designers have their own rule of thumb to dispose objects on a blank page. You can also create your templates and import guidelines from your company, client, etc.

2 – Create containers for your objects: headers, navbars, buttons, etc. Just drag them and drop them where they’ll stay. It’s going to help you further on.

Containers can be invisible, too. They help, for example, to hide everything at a click, or to replace content for other content.

3 – When you have everything on its right place, create a template and move your objects there. Then, you can start creating your pages and adding content.

Templates can be very useful when you need to create several similar pages. You put the structure there and it’ll be repeated in every screen you want. You can define which template to use in a determined screen by right-click and defining Properties.

4 – The objects that appear very frequently can be masters or be created directly on the template if they appear on all pages. For example, if you’re creating a website that has the navbar and header on all pages, you can create it on the template and only insert the links once.

Masters can appear anywhere on your screen and change position, while templates are fixed. Another advantage of Masters is that they can be broken in objects, and edited (for example, if you want this specific object to be green, but equal to others in every other aspect).

5 – Create your links by dragging the objects to the pages, or vice-versa.

Bidirectional linking can really help your project. Drop your screens over the links, or the links on the screens in your Screen Panel.

6 – Optional, just for the designer: Change objects properties to match your layout. We recommend inserting the images at the end, to reduce memory usage while working. This will transform your low-fi wireframe in an interactive mockup.

It’s better to first put the content inside the project, define what goes where, and then create the look. You can also replace containers for images, logos, pictures or special visual effects. It is also possible to embed HTML snippets and code.

Symptoms:

• Communication problems between team members.
• Lack of comprehension of project requirements.
• Several changes, discrepancies between versions, modifications throughout the development phases.

Use it when:

• Exploration of an end-to-end conceptual design is possible within a week
• You need to reduce the risk of further clients’ modifications requirements.
• You need to increase the understanding between different team members.
• Testing should be done, but you don’t have enough time to code and develop the entire application.
• You want to test different design/layouts/interface solutions.
• Requirements:
• Skills to use – analysis, conceptual design, information architecture, user-experience, data architecture
• Things to produce – prototype, logical data model, storyboard, process map

Advantages of this method

• Avoid re-work: changes and modifications can be very hard on your team, and can cause stress, discussions and drain of time and resources. With the changes done during prototyping stage, the project can be coded in one single stage.
• Avoid software bugs: one of the main causes for bugs is that when some component is changed, affects other parts unknowingly, so avoiding modifications can prevent software errors.
• Control of modifications and versions: With Justinmind Prototyper’s Requirements Manager, it’s easy to know who suggested each modification, when, and in which iteration, thus keeping a register of those changes, and who is responsible for what.
• Documentation: Justinmind Prototyper generates documentation in several formats: docs for registry and control, HTML for sharing among partners and for testing/presentation, CSV for data, etc. This way, your information can always be editable and shareable.
• Clear communication: With a prototype, it’s easier to explain an idea, how it works and how it should be coded; avoiding the famous misunderstandings that sometimes can hinder a project. Besides, it’s drag and drop intuitive philosophy makes prototype creation easy for any person, even though they have no coding/programming skills.

Throughout this guide, you’ll understand how a project can be done with Justinmind Prototyper.

Justinmind Prototyper is a solution for this. You can simulate with a hi-fi mockup almost any properties your final software/website could have. Clicking, data collecting, movement links, etc. This way, nobody will be confused, requirements could be easily specified, things could  be tested and the projects could be approved by the clients even before coding.

When everyone knows what they’re doing, and how things connect and interact, it’s easier to get the project done, and reach your goals. Using a hi-fi wireframe, you’ll be able to reduce costs and time expenses, improving work quality.