Posts in "Pidoco News"

7 popular mobile navigation patterns

One of the biggest challenges in designing an app for a mobile device is the limited screen space. But worry not! It’s possible to meet the users’ expectations and to create a neat looking UI at the same time – with the help of different navigation patterns. We have selected 7 commonly used mobile navigation patterns for you and listed them below, including typical use cases as well as little prototype examples (linked in the images).


Overflow menu

Problem: The user wants to have quick access to additional information and options within the app.

Solution: Overflow menu. With the overflow menu, you can easily stow away extra options and functions that are not used very often, but are still relevant to the context. Often they come along as hamburger menu, three horizontal lines or dots. For instance, such menus include options for refreshing the mail inbox or creating a new contact or group in a messenger or accessing settings.


Quicky access additional information via the overflow menu

Overflow menu: Quickly access additional information via the overflow menu



Problem: The user wants to choose smoothly between various options within one view of the app.

Solution: Slider. With the slider, the user can easily switch between various options just by swiping. While dragging the slider from side to side, s/he can benefit from transitions between different selections and quickly get an overview.

Choose between different display options using the slider

Slider: Choose between different display options using the slider


Swipe views

Problem: The user wants to navigate between content of the app, but doesn’t want to go back or use an extra navigation button.

Solution: Swipe views. Using the swipe view, the user can quickly and easily swipe through the content of an app. As already known from a photo gallery, this is a handy method to go back and forth and switch from one app or content “tab” to another.

Swipe between app content without extra buttons

Swipe between app content without extra buttons



Problem: The user wants to jump between different views of the app, but doesn’t want to leave the current site.

Solution: Sidebar. The sidebar contains the secondary view of the app and e.g. additional options like a navigation list or chat or user settings. It’s a neat collapsible panel that is hidden and only slides over the main view or moves it aside when accessed. This sidebar is often combined with an icon such as a hamburger menu or settings icon (gear wheel).

Jump between different app sections without leaving the current view

Sidebar: Jump between different app sections without leaving the current view


Vertical navigation

Problem: The user wants to navigate between different areas within the app, but there’s only very limited space to display further details.

Solution: Vertical navigation. Like in a list, the user can scroll that vertical navigation which includes all the necessary information in a very compact way such as account details, settings etc. Often this navigation pattern is combined with a sidebar.

Navigate between and scroll through app sections with only limited screen space

Vertical navigation: Navigate between and scroll through app sections with only limited screen space


Sticky navigation or tab bar

Problem: The user wants to access specific options or menus the whole time while using the app.

Solution: Navigation and/or tab bar. If the user scrolls the app, the navigation or tab bar will remain in place at the top or bottom or maybe also at the side. This is especially helpful when overall information or important buttons should be visible all the time, for instance, in an address book, where each alphabetical section stays at the top when scrolling, or in a photo gallery that keeps the headline sticky.

Access fixed app content the whole time

Sticky navigation: Access fixed app content the whole time


Content based navigation

Problem: The user wants to choose between different options.

Solution: Content based navigation. With a content based navigation, supported by neat page transitions, the user only has to successively swipe the screen to make one simple decision at a time. For instance, a swipe action to the left means “no”, one to the right means “yes”. The decisions can be checked later in a different view.

Choose between different app options

Content based navigation: Choose between different app options



Want to share newer, more fancy or different mobile navigation patterns? Let us know and drop us a line at


Happy prototyping!

Prototyping the right way (introduction to effective prototyping – part 1)

This is the first of several blog posts on application prototyping. The series is aimed at prototyping beginners that wish to get a quick start into the field and gain a better understanding of what they should be paying attention to when prototyping.


What is prototyping?

Prototyping is a well-established product design and development method used in various fields from mechanical engineering to software development. Prototyping involves creating partial realizations of a planned product that are used to gain early insight into technical feasibility, user needs, and market preferences, by soliciting feedback from various stakeholders, such as end users, developers, engineers, marketers, and domain experts. The ultimate goal is to minimize risks arising from areas like implementation, production, market acceptance or even customer support by spotting potential problems early on.

Aside from reducing project risk due to their early availability, common additional advantages of working with prototypes include:

Iterative refinement: Since prototypes are often comparatively inexpensive to produce (they can omit certain functions or details or make use of cheap materials), you can create and compare several possible design variants or do multiple design rounds in order to refine the product design step by step with intermittent user feedback.

Time-to-market: One of the key challenges of software development is “getting it right”. Some of the most time-consuming activities occur at the end of the implementation stage and involve the correction of mistakes that occurred because of incomplete or unclear specifications. The more feedback and testing occurs during the design process, the more specification-solution gaps are discovered and filled, helping cut rework time.

Cost savings: Design faults that are caught at an early stage in the design process are usually much cheaper to correct. In software development, the difference between concept and implementation stage may constitute a factor 100 in cost.

Quality improvement: Multiple rounds of evaluation using prototypes can lead to dramatic improvements in product quality, which in turn may have a serious impact on support costs (e.g. fewer calls to the support desk) and market success (more customer acceptance).

Ownership: Prototyping allows users and other stakeholders to participate in the product design process, thus creating emotional attachment and goodwill towards the final product.

In this and the following posts, we will focus on prototyping of software applications, more specifically on UI prototypes, i.e. partial realizations of the user interface of a software application, such as a website or a mobile app. UI prototypes are usually concerned with the user experience (UX) in general or the conversion in specific, i.e. how efficient a website or app is at leading users to taking a desired action, such as purchasing a product or registering a user account.

Prototyping is a key element to the success of the well-accepted iterative development process and usually consists of creating and evaluating several iterations of successively refined prototypes that evolve based on new insights gained along the way.

User Centered Design Process

Refining designs using multiple rounds of creating and evaluating prototypes (iterative user centered design process according to ISO 9241-210 standard).


Take, for example, a new mobile medication reminder app for senior citizens. Key features might include an automatic reminder when pills need to be taken as well as adding a new medication to the schedule by simply taking a picture of the packaging and setting the frequency and/or time. Leaving aside all technical and financial risks (e.g. can we build a system that will be able to identify a medication based on a simple picture taken, within our target budget?), you might start with just a simple sketch on paper, show it to lead users from the intended target audience to see if they understand the app and can easily use it (i.e. whether the product is “usable”), then work the feedback into the next version and test again. For this next round, you might already move on to a digital representation with some more details using a prototyping tool. In later versions, you might add more detailed visual design elements to test user preferences and assess whether potential buyers would actually be willing to pay for your app.

Early-stage prototype of a medication reminder app

Early-stage prototype of a medication reminder app

Prototyping isn’t a rigid process, though. It must be tailored to the specific needs of the project at hand. In the next sections, we’ll explain how.


How to use prototypes?

There are various prototyping techniques for different purposes and different stages of the design process, each offering their own advantages and each with certain limitations. Prototyping is done in a certain project context and is usually a trade-off with other tasks in terms of time and money spent. You should decide on a case-by-case basis how much effort you want to spend on prototyping in order to ensure that your prototyping activities will yield an overall benefit. In general, you should spend as much time as necessary, but as little as possible. If the overall project risk is small, prototyping should not eat up a lot of your budget. If, on the contrary, there are lots of uncertainties in your project, you should plan on prototyping more.

The following two parameters can be adjusted in each prototype to make the best use of available resources such as time an money:

Scope: Prototypes only represent a certain part of the product. In software development we can distinguish between horizontal prototypes that comprise several or all features at the same architectural level (such as UI prototypes) and vertical prototypes that consist of a fully functional implementation of only one single feature including the UI, logic and data levels. In addition, prototypes can of course selectively focus on only a certain subset of all features that pose a design challenge and omitting those that are obvious.

Fidelity: Prototypes usually use a certain amount of abstraction to guide attention to the most important aspects of a design problem. This means that prototypes usually omit certain details. Especially in the early stages of product design prototypes are often less detailed (low fidelity or low-fi), focusing on the overall concept or on specific risk factors. For example, an early-stage prototype of a mobile app may entirely abstract from visual design (e.g. colors, fonts) and focus solely on the layout of each screen. Abstraction often helps understand issues better since the amount of information that needs to be processed is lower. Of course, abstraction may also lead to an incomplete understanding of an issue or over-simplify a complex problem, so it is sometimes necessary to use very detailed prototypes (high fidelity or hi-fi). There are several dimensions of fidelity, including among others visual details (black/white vs. grey scale vs. color) or responsiveness (interactive vs. static) or data type (lorem ipsum text vs. dummy data vs. real sample data).

Interactivity: Prototypes can be static representations that merely give a visual impression of the user interface or allow the viewer to interact with them to get a sense of the look and feel. Interactions can range from simple clicks or taps that bring up the next screen (much like a slide presentation) to sophisticated simulations of system behavior that distinguish between various triggers (e.g. swipe gesture vs. double tap) and are able to precisely show how the future product would react to them (e.g. transitioning to the next screen by fading the old one out). This can be important when running user tests to identify potential usability issues.

Material & Tools: Finally, prototypes can be produced in a variety of ways. The biggest difference is between so-called paper prototypes, which are more or less sophisticated visual representations drawn on sheets of paper and possibly cut out to obtain tangible “interactive” elements, and digital prototypes that can be used on a computer or handheld device and as such are much closer to the final product. Digital prototypes can be created using anything from a design tool to specialized prototyping tools or can be directly coded or even done in a presentation tool like Powerpoint. This last parameter is primarily a question of preference or contextual restrictions (what tools do I have available, which tools am I comfortable with, are my testers onsite or do I need to “send” the prototype) and will not concern us further.

When you are working on an entirely new app, you may want to think about the general user flow and look at the bigger picture at first. In this case your scope should be relatively large, perhaps covering the most important user stories, but you will probably get away with omitting certain details at the screen level (low fidelity) and not worry about your prototype being interactive. In fact, these details may be entirely inconsequential at this stage. If, on the other hand, you are trying to work out how a certain feature should work at the interaction level, a single screen or two with lots of details and exact simulation of system behavior might be what you need, so your scope should be extremely focused while you will be working towards a higher level of fidelity and interactivity.

Of course, each parameter has a scale and depending on how these parameters are set, we can distinguish different types of prototypes:

Sketches (hand-drawn, low-fi, static): Sketches (also sometime referred to as “scribbles”) are very early, rough (low-fidelity), hand-drawn static representations of a future product. Usually, they are preliminary outputs to a first concept and used for ideation rather than actual feedback. While we list them here for completeness, we would argue that they are not really prototypes, since they are too far from being a “partial implementation”. Sketches can, however, be the basis for paper prototypes.

Paper prototypes (analog, low-fi, static to semi-interactive): Paper prototypes are easy to create and don’t require any specialized tools. Paper, pencils, scissors and some tape or glue are usually sufficient. They are also very flexible and can quickly be redesigned on the fly, even during a user test or workshop. On the other hand, they can only offer a very limited idea of the interactive behavior of a product (e.g. menus can be simulated by rolling out a folded strip of paper with the menu items written on it by hand) and cannot be easily modified, i.e. changes require creating a new prototype (or part of it). Usually they are hand-drawn and low-fidelity, unless printed designs are used as basis.

Wireframes (digital, low-fi, static): Wireframes are relatively easy to create, but do not include any visual design (low-fi). They are static representations of the product that focus on the layout of each screen and how the screens relate to each other. Wireframes are usually created using a graphics/drawing tool or specialized wireframe tools like Pidoco that are often more efficient or easy to use and allow for easy adaptation of the wireframes to changing requirements and user feedback.

Interaction/UX prototype (digital, low-fi to medium-fi, interactive): Interaction or UX prototypes simulate the human-computer interaction, i.e. how the application reacts to user inputs. They are interactive digital representations of the product and as such usually require more effort and time than, for example, simple wireframes, even though they usually do not include full visual design. Specialized tools are recommended, although sometimes readily available office software can do an ok job.

Design comp/mockup (digital, hi-fi, static): Mockups are static representations with near-finished visual design, but without interactivity. They are typically relatively time-consuming to create and require specialized graphics tools, which is why they tend to be used towards later phases in the design process when basics like structure and layout of the application have been sorted out.

Hi-fi prototype (digital, hi-fi, interactive): Hi-fi prototypes combine advanced visual design with simulated or even implemented human-computer interaction. Due to the high level of detail they are very time-consuming to create, but may evolve from earlier prototypes by linking up existing mockups or adding visual details to interaction prototypes. Hi-fi prototypes require specialized tools or can be implemented programmatically using HTML or other programming languages if such skills are present within the design team.


When to use which type of prototype?

Here are some common scenarios where prototypes can be helpful and some recommendations on how to get the most out of them.

Internal communication within the design/development team (exploration)

How can a prototype help?

Capturing an idea – especially an innovative one – in words, so that others can easily understand it, is often very difficult. Words evoke associations and it is likely that ten listeners will form ten different thoughts in their head. A visual representation in the form of a prototype helps manifest the idea and prevent misunderstandings in the early design phases. In addition, prototypes are “tangible” design artifacts that allow for a hands-on experience long before the final product becomes available for testing. Finally, they also help document progress and foster better discussions, since laymen can easily join the discussion, even if they don’t understand the design lingo or have no tech background.

What should the prototype look like?

The focus here is on exploring the design space, discussing ideas, coming up with – often innovative – solutions to key design problems, and expanding the solution space with controversial or unconventional approaches. Since these internal discussions occur among people familiar with both the general subject matter and design process as well as the specific project, prototypes can be less detailed. This means, you can work with a lower level of fidelity, working with placeholders instead of real images and copy, or omitting, for example design elements like branding or even color altogether. You should focus on core design issues and avoid wasting time on obvious parts of the design. By setting the right scope for the prototype, you can not only save time, but also focus the discussion on certain topics while steering clear of things you currently do not want to speak about. Interactivity can plan a role at this point, but often static or simple “clickthrough” wireframes will do the job.

Low to medium fidelity prototype

Low to medium fidelity prototypes or wireframes are great for early-stage internal communication


What to watch out for?

It is easy to get carried away with your idea, especially when the prototype allows you to quickly make headway. But the entire idea of a prototype is that it can still change according to feedback (or even be scrapped entirely). So, don’t get too attached to your initial prototypes – they will change! Attachment may easily lead to improper decision-making. As a hint, try to keep it simple in the beginning: don’t spent too much time, don’t go into detail, use low-fidelity prototypes. And be open for honest feedback. It (almost) always makes your product (and your team) better.

Fidelity: Low – medium

Scope: Focused

Interactivity: Not a must


External feedback, e.g. usability testing (evaluation)

How can a prototype help?

Prototypes are concrete representations of the future product, which can help gather more reliable feedback from real users. Seeing a prototype and/or interacting with it gives a potential user much more context than just an oral or written description. In particular, a prototype helps validate or invalidate implicit assumptions the test subject may have about the final product.

What should the prototype look like?

The goal of gathering external feedback is to detect usability problems or to answer a specific question (e.g. “which navigation option works better?”), sometimes openly, sometimes implicitly through observation of users completing assigned tasks. Therefore your prototype should be optimized to answer that question. Depending on how familiar your test subjects are with product design, how much opportunity there is for explanations (are you doing a moderated or unmoderated test?), and what your test goal is, your prototypes should be self-explanatory and detailed enough for the evaluating person to understand them. Include as much detail (fidelity) and interactivity as necessary, but keep it as focused as possible. E.g. if you are trying to get feedback on the user flow of an app (scope), don’t bother with minutiae of the individual screens and keep the interactivity simple. If you are trying to figure out the best way to design a specific feature, don’t bother with unrelated features, but do take time to model the details of specific interactions if they matter. In general, if you are testing design variants, only vary one variable at a time – otherwise you will not be able to gauge accurately, which variation caused the difference in results. On the other hand, include all options (affordances) that may distract or mislead the user, if you are testing your design for usability issues. If your question depends on the visual design (e.g. color codes or button contrast), include visual details. If branding (e.g. logos, brand colors, specific UI elements) is critical, include it; if your question is independent of branding, leave it out to save time. In general, for a real usability test, we recommend starting with a simple low-fidelity interaction prototype and adding visual fidelity to the extent required.

Prototypes for user tests should be optimized to answer the specific research question at hand.


What to watch out for?

Prototypes are not the final product and hence require the recipient to use some level of abstraction. If possible, give the test subjects some background as to what the goal of the prototype is, e.g. are you looking for feedback on layout, conceptual questions, the user flow, a comparative rating of different solutions to a design problem, or the visual design of the product. Also, tell them the limitations of the prototype so they know what to expect. Prototypes are great for focusing on certain aspects of the product design, but if you don’t tell the testers what feedback you are looking for, you risk getting the wrong kind of feedback – or flat-out rejection. In general, focus on a small number of questions or tasks. (Find more information on user testing here.)

Fidelity: Medium – high

Scope: Depends on question at hand

Interactivity: Simple – Detailed (depending on test case)


Requirements engineering (specification)

How can a prototype help?

Enriching a specification with visuals helps keep risks and overhead at bay. A written specification can never be complete (at least, it would have to be excessively long) and therefore often forces developers to make assumptions or guess the intention of the author, leading to potential missteps, or ask lots of questions, which takes time. A picture, on the other hand, as the saying goes is worth a thousand words, due to its richness of information. Therefore it can convey lots of information in a very concise manner.

What should the prototype look like?

The goal of a prototype used for specification purposes is to give the developer(s) a detailed picture of what they need to produce. Prototypes should be complete, but there is usually no need for a finished design, as this is typically provided separately by the designer. In particular, the prototype should contain all details necessary for implementation, such as the layout of the screen (where possible with exact dimensions), any graphics inputs (such as logos, image files, etc.), links between screens, as well as behavior of the system following any possible user input. If interactions play an important role and are not obvious from the UI or contextual information, you should include them in the prototype. No specification will ever be complete, but you should try to minimize the amount of potential questions the developers will need to ask or guesses they will need to make during implementation. Your scope should be complete, but do not waste time prototyping screens that are basically copies of others; rather include references to other screens, which will also help the developers discover patterns and make their life easier. Remember, that the prototype will usually be accompanied by a written requirements document as well as a set of visual designs that will complement the specification, but check to make sure what information you need to provide in the prototype. A low-fidelity prototype may be entirely sufficient if visual design assets are delivered separately and referenced correctly in the prototype. Often, it is helpful to annotate the prototype to add information that is not readily visible, especially if you are sharing only screenshots of the prototype instead of the interactive prototype itself.

Prototypes serving as specification

Prototypes used for specification purposes should include additional information for the developer


What to watch out for?

Don’t try to put everything into the prototype when you don’t need to. For example, don’t include visual design, if you know that there will be separate design files delivered. Rather, reference the files if you already know their names. All else would be a waste of your time.

Fidelity: Low – medium

Scope: Complete (but avoid redundancies)

Interactivity: Detailed (unless obvious from context)


Selling your ideas to decision-makers (presentation)

How can a prototype help?

Designing a great product is a real challenge. Convincing someone to buy a new product or sign off on a new idea can be just as hard. Prototypes can help you impress decision-makers because they basically allow you to travel in time to a point where the final product is already available, giving your audience a much better understanding of the full potential of your idea or product.

What should the prototype look like?

The goal here is to convince people to take an action. Either you need approval to move on to the next step in the design process or you want a client to give you the go on your design idea, or you may want to get a customer to make a purchase decision. Usually, decision-makers are busy and therefore impatient people. They may not have a lot of time to waste on understanding the goals and/or limitations of your prototype or abstract from the visual representation. Therefore your prototypes should be more visually refined (medium to high fidelity) and give a good representation of the final look and feel, i.e. include enough detail in the interactions to make them feel realistic. Since in a presentation setting (unlike in a user test), you tend to be in full control of the situation and therefore can tailor the scope of your prototype to the specific scenarios you want to highlight or show off. Make use of this advantage in order to spend your time most effectively and avoid wasting time on parts that nobody will ever look at.

Navigation flow of a high-fidelity prototype

High-fidelity prototypes are great to sell a future product or just an idea


What to watch out for?

Hi-fidelity prototypes may lead inexperienced viewers to assume that the product is almost finished and that it can be delivered soon or without much additional cost. Make sure not to raise unwarranted expectations. Explain that this is still a prototype and which steps are still required to leverage the full potential you have been showing off with the prototype.

Fidelity: Medium – high

Scope: Focused

Interactivity: Detailed


Summing it up

In this first of four posts, we took a look at what prototyping is, how it can be useful in various stages of the design process, and how to decide what your prototype should look like during certain project phases and to achieve certain goals.

In our next post we will be looking at how to turn paper prototypes into digital assets and use them for further research. So check back soon.


This blog series on prototyping was created in cooperation with Prof. Dr. Birgit Bomsdorf, University of Applied Sciences in Fulda, and is based on experiences gained from various prototyping projects as well as from lecturing and researching in the field of Human-Computer Interaction. It is a work in progress and we will keep updating and adding things. If you are missing something, have questions or want to share a different opinion, feel free to leave a comment.

How to … work with a grid system in Pidoco

A little while ago, we introduced our new grid feature. The grid feature was inspired by the wide use of grid systems in design and development and helps you

  • quickly build complex layouts within a prototype,
  • easily create multi-device layouts, and
  • set up a clean structure throughout the entire prototype.

Basically, the grid consists of customizable columns that contain all your site’s content and help you align elements easily. A “snap-to-grid” function makes aligning even easier.


1. The grid system in Pidoco

Working with the grid is simple: Just open a page of your project and click the “Show Grid” link above the canvas. The grid icon next to the link opens the dialog that lets you adjust your grid settings: You can set the number of columns, the gutter width between columns (to give the columns some padding), as well as the margins on either side of the grid. Finally, the grid width serves to define the total space available to your design and acts as an overall container that is centered relative to the device screen (much like the container concept in common grid frameworks). A grid preview right underneath the settings helps you choose the right values. Smart defaults will get you started right away.

Activating the grid in the Editing Panel

Activating the grid in the Page view

Since you may already be used to working with grid systems, here are some recommendations for settings corresponding to defaults in widely used grid systems you might want to use.


2. Working with the 960 Grid System

One of the most common grids is the 960gs. Optimized for “modern monitors” that “support at least 1024 × 768 pixel resolution”, this grid layout is still often used because its base number of 960 is highly flexible, being divisible by 2, 3, 4, 5, 6, 8, 10, 12, 15, 16, 20, 24, 30, 32, 40, 48, 60, 64, 80, 96, 120, 160, 192, 240, 320 and 480. The “container”, which holds the actual content of the website, is split into either 12 or 16 columns.

The 12 column grid (source: under CC Attribution-Share Alike 3.0 Unported)

The 12 column grid (Source: under CC Attribution-Share Alike 3.0 Unported)


2.1 Using 12 columns

You can recreate the 12-column layout of the 960 Grid System exactly by using the following grid settings in Pidoco:

  • Columns = 12,
  • Grid width = 960px
  • Margin = 10px
  • Gutter = 20px.

This is what the 12-column grid looks like on a 1024 x 768 pixel screen.

Using the 12 column grid on a website project

Using the 12 column grid on a website project


2.2 Using 16 columns

To work with the 16 column variant, you can use the following settings:

  • Columns = 16,
  • Grid width = 960px,
  • Margin = 10px,
  • Gutter = 20px.


3. Working with the Bootstrap Grid System

Another commonly used system is the Bootstrap grid system. This grid system takes into consideration that modern devices come in many forms and shapes ranging from very small screens (like on smarphones) to large widescreens (like many current laptops) and allows developers to easily plan for responsive scenarios with a “mobile first” approach. Depending on the target device size, there are five grid tiers with increasing container width (the container width describes what portion of the screen is actually reserved for the content and essentially corresponds to the grid width in Pidoco):

  1. extra small (XS): device width of less than 544px, no container width,
  2. small (S): device width between 544 and 768px, a container width of 576px,
  3. medium (M): device width between 768px and 992px, a container width of 720px,
  4. large (L): device width between 992px and 1200px, a container width of 940px,
  5. extra large (XL): device width of more than 1200px and a container width of 1140px.

The Bootstrap grid system assumes an additional margin of 15px on either side of the content, so the effective container width actually comes out to  be 30px wider than the specification lists, e.g. 1170px for the XL variant. If you work out the exact numbers for, say, a 12 column grid, you will find that this results in half-pixel dimensions (e.g. 97.5px in XL). Modern devices deal with this through their rendering engines, but since Pidoco only uses full pixels for projects, you need to approximate the default grid tiers. Here’s how…

To use the XL grid size (container width including margins of 1170px) in Pidoco projects, we recommend the following settings:

  • Columns = 12,
  • Grid width = 1164px (a little less than 1170px),
  • Margin = 15px,
  • Gutter = 30px.

This example shows a website project on a 1366 x 660 pixel screen. The result are 97px columns – 67px plus 15px margin on either side.

Using the Grid XL on a website project

Using the Bootstrap XL grid tier on a website project

You certainly will have noticed that is does not exactly fit the default column width of 97.5 px as prescribed by the Bootstrap specification. That’s why we approximated the settings with a column width of 97px, resulting in a grid width of 1164px and thus a deviation of 6px compared with the Bootstrap container width of 1170px. (Note: We recommend erring on the side of less space when designing, but if you would rather have 6px more, just set the grid width to 1176 px.)

And this is what it looks like:

Example prototype using the bootstrap XL grid

Voilà: An example using the bootstrap XL grid


That’s it! You have successfully applied a customized grid to your Pidoco project!

Do you need help? Then do not hesitate and drop us a line via or Facebook and Twitter.


Happy Prototyping!


New Release: Smart Duplicate, Interaction Highlights, Improved Grid

To spice up the summer, we have just released some new features and improvements. Here’s what’s new…


#1 Smart Duplicate

Tired of copy/pasting multiple repeating elements to fill your screen? With our brand new “smart duplicate” feature, it is much easier to create a series of tabs, an image grid or a row of buttons. Simply duplicate, and Pidoco will do the positioning for you. Of course, you can adjust where necessary.

Quickly duplicate and align elements

Smart duplicate: Pidoco does the positioning for you


#2 Interaction Highlighting

Ever wondered which elements are clickable? Wonder no more. With the new “interaction highlighting” you can simply press the Ctrl key and all elements with interactions attached will light up. Keep the Ctrl key pressed to open multiple target screens in new tabs.

Interaction highlighting: Accentuate the interactive elements in the Simulation View

Interaction highlighting: Easily find links and interactions in the simulation view


#3 Improved Grid

We updated and improved the grid feature which we introduced earlier this year. Now, aligning elements feels much smoother and is faster than ever before. Give it a try!

Easy alignment: Smoothly place elements with the improved grid

Grid feature: Smoothly and quickly place elements with the improved grid


Let us know in the comments what you think!


By the way, we run monthly usability tests. If you’d like to join, just send us a quick email to and we’ll be happy to provide you with more information. Stay tuned for more!


Happy Prototyping!


PS: Not a Pidoco user, yet? Why not register for a free 31-day trial today?

7 Common Mistakes While User Testing

Users complete realistic tasks using your website or app, comment on their actions, moderators guide them, observers watch and listen, others take notes. That’s how a usability test is typically set up. Its purpose is to identify problems regarding the usability, find out how satisfied the participant is, and collect data for making informed design decisions. That’s in an ideal world… But even if you follow best practices like those found at, there’s still a lot that can go wrong. Here are seven common mistakes during a usability test you shouldn’t make.


#1 Testing the user

The most important point at the beginning: You are testing the usability of your website or app – not the user! The participants of your test should be aware of that. Why? You want honest and reliable feedback, and the best way to get this is to make your testers feel at ease – at least as much as possible. They should behave as naturally as possible. After all, you are trying to get insights into real-life situations. Usability tests by their very nature put participants in an artificial and often slightly uncomfortable situation. So the first step toward meaningful test results is to overcome this unnaturalness by reassuring your testers that they can do no wrong during the test. Otherwise, you risk that they will feel insecure or won’t be honest and speak out their real thoughts.

Test your product, not the user. (Source:

Our advice: cross out the term “user test” in your papers and in your mind. Everywhere. Maybe even start your introduction with “We’re not testing you, we’re testing us.” It’s a usability test! Plus: make your participants feel comfortable. If possible, visit them in their natural habitat instead of using a usability lab. All you really need is at least enough space for all your test participants (test user, observers, moderator) and recording setup. Or you could consider a remote test, allowing your test users to stay right at their desks, especially if your users are located somewhere else.


#2 Testing too much

Setting up a test is exciting, especially if you have lots of new features coming up or want to test different design versions. But don’t try to test everything at once or fitting every possible task into one session! Otherwise it’s likely that you will either tire out your participants or run out of time and don’t get the desired test outcome. Also, consider who you want to recruit for your test: Not everybody in your target audience may be able to afford to spend the time. The typical test session has a length of 60 to 90 minutes at most and contains 2 to 3 test scenarios. So you can’t test everything at the same time. You need to stay focussed!

Focus on roughly 3 test scenarios to avoid testing too much. (Source:

To avoid struggling during the test session, good preparation is needed: Create a list of all the things you want to learn from your test prioritizing the most important tasks and questions (see #3). Items with a lower priority can go to an extra list for later consideration if there’s still time left towards the end of your usability test. Prepare some extra minutes to have some time left rather than running out of time.

Another good way to avoid overwhelming test users is planning to run a longer usability test and break it up into several sessions focussing on different aspects.


#3 Asking the wrong questions

Many usability tests start out like this: “Take a look at this homepage and tell me what you think.” or “Take a moment to look around the site.” Don’t waste precious test time on artificial questions like these. You are trying to simulate real conditions in a usability test, but real people don’t come to your site to just browse around. Instead, you are giving away critical insights as you are allowing users to familiarize themselves with your site before the real test has even started. No, people who will use your website or app for real will do so with a specific objective in mind. So you need to make sure to test your design against those objectives. In particular, you should focus on the “red routes” – tasks that are critical for the users and/or the organization and thus should be as smooth as possible. This will also help you stay within the allotted session time (see #2).

Another type of question to avoid are leading questions (e.g. “That new button looks nice, right?” etc.). Instead of learning from the testers and hearing what they really think, you will hear what they think you wish to hear. Instead, ask open-ended questions (e.g. questions starting with W words – what, when, where).

Test your questions to find out if they perfectly fit the test. (Source:

Finally, be careful how you answer questions the participant might ask you. While you can’t (and shouldn’t) prevent your test users from asking questions, try to answer them with another question. Otherwise, you might be led to compromise the outcome of the test by giving away answers or introducing a bias (e.g. “Clicking here will guide you back. What did you expect to happen?” etc.). Don’t tell them the answer. Instead, ask them for their experience or let them articulate their first impression or expectation. For instance you might respond to a question with something like “What do you want to do?”, “What can you do here?”, “What do you expect to happen?” etc.

To minimize questions from participants in the first place, you should test your questions in advance (see #4).


#4 Failing to do a trial run

To avoid getting sidetracked and ensure comparability of results across test sessions, it is best practice to create a detailed test outline that includes all the important tasks and questions you want to ask, often even the introduction text to read out. A commong mistake, however, is to not test your test. Just like you are testing your website or app, you should do a trial run of your usability test. Even if you have prepared a detailed test guide and feel well-prepared, there are lots of things that can go wrong under real-world conditions. Just a few examples: The tasks you prepared may be unclear to participants, requiring spontaneous explanations that may lead to giving away too much information. Or tasks may simply take longer than expected, putting you and the testers under pressure. Or even worse yet, your equipment might not work the way you expected so you may end up leaving participants waiting or not being able to record things or run the test at all. Or you may have overlooked an inconsistency in the test outline that may trip you up. Better to catch that before the actual test!

Use a guideline and run a pilot test. (

That’s why you need to do a pilot test to determine how long the test will take and if your planned structure makes sense. Finally, once you have created your test guide and made sure it is well-structured and works, stick to it. Don’t digress from the scenarios and questions you prepared for the test session.



#5 Focusing on what they say

A common method in usability testing is “think-aloud”, i.e. asking the test participants to speak out what goes through their head as the interact with a system and try to solve the tasks given to them. While this type of commentary may give you valuable insight into the user’s state of mind, relying on words can be dangerous. Why? Because what participants say may subjectively be true, but objectively lead to wrong conclusions. First, studies have shown that users are poor at introspecting into their own motivations, so asking the user things like “Why did you do this?” may produce faulty answers. Second, we may get tempted to add questions like “How much would you pay for this product?”, which may work with a large sample, but not yield reliable guidance with the typical test pool of 5-8 participants. Finally, users may feel obliged to be nice to you when really they want to bang their head against the wall out of frustration with your site.

Pay attention to the actions, gestures and mimic of your test user. (Source:

To avoid this scenario, focus on actions rather than words. Grant participants enough time to express their thoughts and perform actions during the test session, even if this takes a little while, maybe even longer than you expect. Often the participants have a specific mimic or make a gesture. Pay attention to them. Note where participants hesitate, where they seem to be searching for options. Don’t ignore it. Especially, if you’ve already run multiple tests and maybe noticed some patterns, every experience matters! Just because people stop at the same point of a test doesn’t mean it happens for the same reason. Be objective and treat every tester equally. Remind your users to speak out loudly and try to gather as much information as possible, but don’t be misguided by what they say.


#6 Interrupting the usability test

Preparing a test guide is best practice, as we already saw, but it is not sufficient. A common mistake is to interrupt the flow of the usability test by inserting unrelated questions. One example is, to ask participants for ideas for alternative design solutions. Usability tests are supposed to help you uncover problems. To do so they focus on problem behavior, e.g. by giving the testers tasks to perform in order to achieve a specified goal (remember, usability is defined as the “extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use”). If they fail, this is critical information for you. But if you then ask them what type of design would have helped them succeed instead of continuing to evaluate why they failed, this will switch the entire discussion, interrupt the flow and likely limit your chance of getting to the actual root cause of the issue.

Avoid unrelated questions that may interrupt the flow. (Source:

Stick to your test guide and avoid interrupting the flow of the test session with questions your participants are actually unlikely to be qualified to answer – most users haven’t studied design and don’t know what options are even available. Instead, test different alternative solutions to begin with. This will help you identify design approaches that work and those that don’t.

Of course, you should also try to avoid other distractions that may interrupt the session, such as background noise, technical issues or unrelated questions, e.g. by setting aside some time at the end of the session to address questions by the participant or observers.


#7 No documentation

It’s always about saving time. So often people ignore documenting their findings during a test session, but also mentioning which methodology has been used. Why take notes, if you can have a meeting afterwards, especially if there are other observers in addition to the moderator? But in fact, it should be possible to easily and quickly recap the test session and results need to be visualized for those who didn’t participate in the usability test. Without proper notes you risk missing important results, significantly reducing the value of your test overall. For instance, if you want to figure out how long it takes the user to complete a task or whether she was able to complete the task at all and how many attempts were necessary to do so, you need good data. That’s why a permanent record of the findings is essential.

Document the findings to distill actionable recommendations. (Source:

To avoid ending a usability test without proper documentation, make sure you have a designated person for taking notes during the session. You can also incorporate space for notes right into your test guide. It might also help to print out screenshots of important parts of the test to keep track of the context of your observations. After each test, schedule some additional time to go through your notes, consolidate findings from the other observers and add any additional information you might have forgotten to capture during the test. Ultimately, you want to produce actionable recommendations for the next design iteration that are based on real user behavior.

Pidoco & AppCooker at UXcamp Europe

UXcamp Europe is one of the largest BarCamps for User Experience Professionals uniting more than 500 UX enthusiasts from all over the continent and beyond each year in Berlin, the heart of Europe. Last weekend it took place again for the 8th time in summery Berlin at Erwin Schrödinger-Zentrum (part of the Humboldt University). Organized by a superb team of volunteers, it featured a wide range of insightful discussions, workshops, presentations and demos from the participants in as much as 10 parallel tracks. As usual, the organizers managed to create lots of room and opportunities for exchange and networking outside the conference room, be it in the shade of the large umbrellas near the barbecue stand or in the adjacent café.

A beautiful summer day at the UXcamp Europe

A beautiful summer day at UXcamp Europe

On Saturday, we had the opportunity to hold a workshop titled “Bring your iPads® – Prototyping On The Go”.  Using AppCooker, a professional app for prototyping on the iPad®, as our example, we had a vivid discussion on the pros and cons of mobile prototyping and the many opportunities it offers in the app design process. We designed mockups for an iOS event app on the fly with the workshop participants and had fun coming up with ways to improve the process from paper to digital prototype. It was great to speak to many of you and receive such valuable feedback. Thanks to all who attended!

After two days of UXcamp, meeting so many creative minds and enjoying the camp’s atmosphere, all that’s left to say is once more: Thanks for the great organization! Thanks to all the campers! Thanks for a great UX weekend!

See you next year!

Pidoco acquires AppCooker

Today is a great day. We are excited that the iOS prototyping and mockup app AppCooker will join Pidoco and strengthen our offering. The acquisition was announced this weekend at the UXcamp Europe conference, one of the largest BarCamps for user experience professionals with 500+ active participants from around the world that has been taking place in Berlin since 2009.

AppCooker: Prototyping on the iPad®

AppCooker: Prototyping on the iPad®

AppCooker is a professional prototyping app for the iPad®, which enables software designers and developers to create mockups of future iOS and watchOS® apps directly on the iPad® for presentation and pre-development testing purposes. The app was developed by Hot Apps Factory, a mobile software company based on the French Riviera, which specializes in the preproduction process of making beautiful iPhone® and iPad® applications.

The takeover is part of our vision to allow all stakeholders of the app design process to participate in prototyping activities across devices. We believe that existing as well as new users will benefit significantly from the acquisition. AppCooker will remain available as a stand-alone app to users via the Apple App Store® and will also serve as a basis for new products.

How to … create a slideshow or carousel

Slideshows or carousels are a neat eye catcher on a site and great way to present different information on limited screen estate. Additionally, they allow users to gain a quick overview of your offering and switch between different topics. With Pidoco, you can easily simulate slideshows and carousels using the “Extended Interactions” feature. And here is how it goes …


1. Setting up the project

To build our slideshow we will use several copies of the same page that will only differ in the section representing the slides. Here’s my project which represents the website of a small art museum. Let’s start by building the page that will contain the slideshow. Here I added some headlines and a text block, but note that I left some space in between for the slideshow. This will be the “frame” for our slide show.

Adding the fixed content to the start page

Adding the fixed content to the start page


2. Creating the slideshow

Now, let’s add the slides to our project. To add the slides, we will make a few copies of our initial page – we need one page for each slide (since my slideshow will consist of three different images, I will make two copies, so there will be three pages in total). To do so, we click the “Duplicate” button in the context menu.

Cloning the start page to create the slideshow

Cloning the start page to create the slideshow


Now we can start editing the slide: Open the initial page and add an image for the slide, as well as any other content you want to show on the first slide. I used an image, some text and a headline. In addition, I added a “Start slideshow” button to the first slide. Note that this puts the user in control of the slideshow, rather than starting it automatically when the page loads.

Editing the first slide

Editing the first slide


Do the same with the other two pages to create slides 2 and 3. To ensure consistency, all slides should have the same size and look.


3. Adding interactions

Finally, let’s set up the interactive part. To make the slideshow move, we will add several interactions to the start button. To do so, select the button and open the “Interactions” tab of the context menu. To use more than one reaction, click on “Add reaction” in the right column of the Interaction dialog. To initiate several subsequent slide transitions with just one button click, we can use a delay with each page transition. I chose 5 seconds for both transitions.

Using interactions to change the visibility of the slides

Using interactions to change the visibility of the slides


Note: Since all page transitions are counted from the first button click, the first transition will have a delay of 5 seconds, the next 10, 15, 20, and so on.

Hint: You can also build a slideshow using layers instead of several pages, by putting each slide on an individual layer and using an interaction that will display and hide the slides in the right order. In this case, however, you need to remember to order the layers such that the next slide is always displayed “on top” – or hide the slides that are not active with every new slide that is displayed.


That’s it! You have successfully created a slideshow! Do you need help? Then do not hesitate and drop us a line via or Facebook and Twitter.


Happy Prototyping!

Aligning interests: New release features customizable grid, icon colors, better zoom

We’re celebrating the arrival of spring time with a new release. Here is what’s new…


#1 Customizable grid

The new grid feature supports layouting your screens. The snap-to-grid function makes for an easy and precise arrangement of assets on the canvas. What’s more, you can customize the grid to suit your layout: Simply adjust margins, gutters and number of columns in the grid settings. A grid preview helps you choose the right values while smart defaults help you get started.

Using the grid to individualize the alignment patterns on your screen

The customizable grid helps align elements on your canvas


#2 Icon colors/icon search

Following a frequent request, we have added a color option to all icon stencils. And there’s more: Individual icons can be found via the Quick Search feature. Just type what you’re looking for and the matching icons will be displayed in the stencil palette.

Screenshot of icon color picker

Icon colors can make prototypes more realistic


#3 Improved zoom 

Sometimes you have to zoom your screen to better view your canvas. We have improved the zoom feature to easily let you see the current zoom level and make it easier to return to normal view. Simply click the current zoom level to reset to 100%!

Resetting your zoomed page

We constantly strive to improve Pidoco, but without you that wouldn’t be possible at all. So we can’t thank our test users enough for their loyal support and feedback.

If you wish to join our monthly usability tests, just send us a quick email to and we’ll be happy to provide you with more information. Stay tuned for more!


Happy Prototyping!


PS: Not a Pidoco user, yet? Why not register for a free 31-day trial today?

Pidoco accepted into BERLIN INNOVATION platform



We are very proud to announce that Pidoco is now officially part of the new technology platform BERLIN INNOVATION which was initiated by the Technologiestiftung Berlin (Berlin Technology Foundation) and is funded by the state of Berlin, the Investitionsbank Berlin and the European Union. Showcasing creative, cutting-edge products, services as well as processes made in the German capital, the platform presents a distinguished collection of Berlin innovations with the goal to establish Berlin as a major innovation hub and provide information to businesses investors, state-owned companies and the general public. With a clear structure, the platform gives insights into innovation projects, supports networking and collaboration, and provides businesses with access to new solutions.

The acceptance of Pidoco into the platform highlights the innovative character of the software-as-a-service product as well as the business potential that rapid application prototyping offers to organizations that invest in modern design and development processes.

For more information have a look at