How to … create an overflow menu

Navigation patterns are the key to make the most out of the precious screen space on a mobile device. Many different navigation paths can be used and not long ago we had a look at the 7 commonly used patterns and typical use cases. You can quickly create these navigation patterns with Pidoco. Today, we’ll take a look at the overflow menu.

The overflow menu is best used to stow away a large number of additional options or menu entries that are not often used but still necessary. For the navigation in mobile apps with very little space that’s a good way to keep the screen clear. Usually, this navigation pattern is found in a navigation bar at the top of the screen and is connected to a hamburger menu. To open the menu, just tap on the icon.

And here’s how it goes …


1. The project setup

To visualize that navigation pattern, I created a mobile app that contains a navigation bar at the top of the screen which includes an overflow menu. The app offers different movie genres you can access via the start page with a tap on the colored rectangle. Additionally, you can select the movie genres on any screen via an overflow menu. If you’re curious, here’s a preview of my finished project called “Watch it!”.

1.1. Creating the start page

To build the app, we need multiple layers and pages. For my project I added 1 page that serves as the start page. With a click on “+ New layer”, I created a layer that contains the overview of the available movie genres. Here I added differently colored rectangles and icons representing one movie genre and activated the layer (Here called: “Watch it! – content”). You can link these elements later after you created the overflow menu. It’ll work the same way.

Creating the start page of the mobile app


1.2. Creating the navigation bar

Having built the start page, we continue with our navigation bar. To do so, we create a new layer. The navigation bar will be located at the top of each page and contains the name of the app and the icon which is connected to the overflow menu. Here I used the icon with three lines and added it to the left.

Building the elements of the navigation bar including the icons for the overflow menu.


2. The overflow menu
2.1. Building the basic structure

In total 6 different movie genres are available and a tap on the icon in the overflow menu directs to the respective content. That’s why we need one layer for each category. So we click on “+ New Layer” again, add stencils and activate the layer. Here I added some text and an image placeholder as well as a red triangle to make it look like a playable video.

Adding content to the layer

Hint: Save time by multiplying that layer and only change details like the headline etc. for each layer. Just go to the Project view and select “Clone element” from the context menu.


2.2. Creating the overflow menu

To build our overflow menu, we create a new layer by hitting the “+ New layer” button in the layers panel and it opens where we add the content of the menu. Here: I added the same 6 icons representing each movie genre.

Adding an icon for each movie genre to the overflow menu.


2.3. Adding interactions

Having built all the layers, we go on adding interactions and start with the first entry of the overflow menu. A tap on an icon displays the respective content of the selected movie genre. So we use the following interaction pairing: When the user clicks/taps then show page and we select our start page as it serves as our app basis. Then we add another reaction and use change layer visibility, select the layer to be displayed (Here I started with the first entry “Action”.) and set the visibility to “show”. Since we can jump between the entries of the overflow menu, all the other layers that contain a different movie genre as well as the layer showing the overview (here: “Watch it! – content”) and the overflow menu itself need to be invisible. That’s why we add more reactions and use “change layer visibility” for each one of them and set the visibility to “Hide”.

Making the overflow menu interactive using multiple reactions.

Hint: Open the interactions panel in the right sidebar, highlight all elements of your overflow menu, and then click on “Apply these interactions to the selection”. Then you only have to change the visibility of the layer that is associated with each menu entry.

Copying the same interactions to multiple elements.

Copying the same interactions to multiple elements.

There’s also the option to close the overflow menu without selecting a movie genre. To realize that we add an action area to the right of the overflow menu and span it across the remaining screen width. Then, we add the user action “clicks/taps” and the system reaction “change layer visibility”, select the layer that contains the overflow menu and set the visibility to “Hide”.

Making the overflow menu disappear without a selection.


2.4. Connecting the overflow menu with the navigation bar

Finally, we connect the overflow menu with the hamburger icon of the navigation bar which is displayed at the top of each screen. A tap on the icon makes the menu appear or disappear. That’s why we open the interaction dialog for that icon, select a tap action, use “change layer visibility” and select the layer that contains the overflow menu. But this time we set the visibility to “Toggle” so it will be shown or hidden with only one tap.

Access and leave the overflow menu with only one tap.


3. Simulation

Voilà! To test your overflow menu, just open the Pidoco app on your mobile device (available via Google Play or the App Store) and start the simulation of your project by selecting it from the project list.


That’s it! You just finished the your mobile app that includes an overflow menu.

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


Happy Prototyping!

How to… work with multiple reactions. Part 2: Mobile apps

Recently, we launched the first part of the series on working with multiple reactions and together created an online store with an automatic carousel and an adjustable shopping cart. This time, we’ll build a mobile app and make the most out of limited screenspace while still creating impressive prototypes. In Pidoco that magic happens with the use of extended interactions.


1. The project setup

Let’s have a look at today’s example: a mobile app that lets you click through images, like them and create a favorite list. To give you a little inspiration, here’s what my finished project looks like. The app called “Live there!” includes a tab panel with several images of rentable houses on the start page. Those images can be liked, and additional information is displayed with a tap on “Show more”. Reservations can be requested and a click on the heart icon adds the selected house to the favorites list. All the liked images are listed on the page “Favorites” and of course can be edited and removed from there again. A small overlay on that page gives additional information simulating a feature update and disappears after a few seconds again.

And here is how it goes …


2. Building the app frame

We start with the basic structure of the app by adding the content to the start page that is supposed to be sticky. Here I used a status bar at the top, added a navigation bar from the pre-designed templates and added some text and a few icons.

Adding static content to the start page

Hint: We’ll need several pages for the app – one for each navigation bar entry, one for the calendar and one for each real estate image that will be displayed with a click on “Show more”. The quickest way is to duplicate the page in the Project View.


3. Use case: Like images with a double tap

Goal: Double tap on the image of the real estate to like it, and the white heart turns red.
Ingredients: 5 layers are needed: one layer for the image panel itself and four layers to switch the like status for the images. Each image needs one layer for the status “liked” and one layer for the status “unliked”.

Step 1: Creating likeable images

Having built our app basis, we now create the image panel on the first layer with a click on “+ New layer” and then add two image stencils to it – one for the image on the left, one for the image on the right. We can combine the two images in one layer. As the panel with the first two images has to be displayed by default, we check that layer (here called “Image 1+2”) in the layers panel.

Next, we need a second layer to add the “unliked” state of the left image. Here I used a heart icon without fill color and placed it at the upper right corner of the image. As this is the default setting of the image, we activate that layer in the layer panel.

Creating the layer for the unliked content

Finally, we add the third layer to show the “liked” state of the image. You can copy the content from the previously created layer and only change the heart icon to a filled heart by clicking on “Change” in the context menu and selecting the right icon. Here I changed the color from black to red.

Creating the content for the liked images

On layer four and five, we do the same as in layer two and three for the right image.


Step 2: Adding interactions

All that’s left is adding interactions to the images to make the heart change from white to red after a double tap. Each image can have one of two states: liked or unliked. So we open the interaction dialog of the image (right click) and add the an interaction with the trigger “double clicks/taps” and the reaction “change layer visibility” for the layer “Image left – Like” with the visibility set to “Toggle”. This will make the heart with the red fill appear, but we also need to hide the empty heart, so we add a second “change layer visibility” reaction with visibility set to “Toggle”, but this time for the layer “Image left – Unlike”. Voilà – done.

Using double-tap actions to favorite the images

Repeat this step for all the other images that you want to add to the app.


4. Use case: Auto overlay

Goal: An overlay pops up after the page has been opened and disappears after 5 seconds.
Ingredients: Here only 1 layer and one page are necessary.

Once more, we need a new layer which contains the overlay that shows up for 5 seconds after the page “Favorites” has been loaded. Here: I added a grey rectangle and some red text. To make the overlay appear on page load, right click on the page to open the page context menu and in the “Interactions” tab add the following interaction: When the user “loads the page” then “change layer visibility”. To make the layer disappear automatically, we add add a second “change layer visibility” reaction, set the visibility to “hide” and specify a delay of 5 seconds.

Building an overlay and make it automatically disappear


5. Use case: Swipeable favorite list

Goal: With a swipe gesture, previously liked images can be removed from the favorites list.
Ingredients: In total, 4 layers and one page are needed – one to display all liked images, one to show a text when there are no favorites yet, one layer for one and another layer representing two favorite images on the list.

We start off creating the layer that contains the list with all possible entries of the “Favorites” list. Here I added a heart at the beginning of the row, an image and some explanatory text. The entries can be removed from the top to the bottom with only one swipe gesture. For that swipe gesture we add an action area covering the area in which the swiping is intended (e.g. the space at the right side between the image and the frame). Then we add a “swipes” interaction to the action area with the direction “left” and a “change layer visibility” reaction for the current layer with the visibility set to “hide”. But we need another reaction, because the next layer that contains 3 instead of 2 favorites needs to be displayed at the same time. So we add another “change layer visibility” reaction, select the layer with 2 items and set the visibility to “show”.

Adding a swipe gesture for removing an element from the favorites list

Repeat that step for each entry of your favorites list.


That’s it! You just finished the last part of the mobile app.

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


Happy Prototyping!

How to… work with multiple reactions. Part 1: Online store

Sometimes, we need to simulate use cases where one single action by the user triggers multiple reactions. For instance, a click on the “Play” button of a song within a music application on your computer or mobile device not only plays the music but also gives a visual feedback by displaying e.g. the album cover. This can easily be modelled in Pidoco using the “Extended Interactions” feature.


1. The basics

In Pidoco interactions consist of one user action (the trigger) and one or several system reactions. Interactions can be attached to pages, stencils and of course to layers and can vary depending on where you use them.

To add interactions, just open the context menu of an element, select the “Interactions” tab and click “New interaction”. Now you can start defining how the system should react to specific user inputs.

Adding interactions to a page: define a user action and one or more system reactions

Hint: When working with interactions, it is helpful to structure the project first, i.e. create pages and layers upfront, and then come back to add interactions. This makes linking content much easier.


2. The project setup

So much for the theory. Now let’s have a look at an example: the online shop and to give you a little inspiration in advance, here’s what my finished project of the online store looks like. It also includes a complete checkout process for the purchase of article 1 as well as for the purchase of two articles and includes a “Success” page, too. All those pages, especially the redirections, contain multiple reactions and are based on the below mentioned interaction pairings.

And here is how it goes …

To visualize the following two use cases, I prototyped a simple online shop that includes a carousel showcasing several products, as well as a selection of articles that can be added to the shopping cart. Both are displayed on the start page (titled “Online store”), the cart being accessible via the header. Below is a map of the prototype:

Screenflow of the final version of my online shop.


3. Use Case “Carousel”

Goal: The carousel automatically starts after accessing the page for the first time, then runs through several product slides. The slides change every 2 seconds.

Ingredients: The carousel consists of three layers, each representing one product slide on the main page.


Step 1: Building the first slide

The first page in our project serves as the basis of our store. We now create the first of our three slides by clicking on “+ New layer” in the interaction panel. Then we add the content, in this case an image placeholder and some text. Now that we’ve finished the first slide of the carousel, just copy the content of slide 1, create a new layer and paste it there to create slide 2. Repeat for slide 3. (Hint: If you want to you can also add two arrows to go back and forth. If you decide to do so, don’t forget to make them interactive like the carousel.)

Adding the content of the carousel

Step 2: Making the carousel interactive

Since the carousel behavior is tied to the page being loaded, we attach the interaction to that page with a right click on the page to open the context menu and add an interaction. Select “When the user loads the page” as the trigger and “then change layer visibility” as the reaction, choose the layer with the first slide and set the visibility of slide 1 to “show”. To make the carousel cycle through several slides one after another, we need to add additional reactions and use delays (2 seconds) to space them out over time. So we click on “Add reaction” at the bottom of the Interaction dialog. We change the visibility of the layer again, but this time we select “Hide” and add a delay of 2 seconds. At the same, slide 2 needs to be displayed. So we add another reaction and set the visibility to “show” and add the delay of 2 seconds. Repeat for slide 3.

Adding multiple system reactions to create an automatically starting carousel.

That’s it! The first part of our web store is already built!


4. Use case “Cart”

Goal: Adjust the status of the shopping cart independently of the current page (e.g. to continue shopping after adding an article to the cart).

Ingredients: Based on the main page, the online shop consists of one page per product, one page for each completed purchase and one layer to depict each shopping cart status. In my project I used:

    – 3 pages, one for each article and its description,
    – 2 pages, one for each completed purchase, and
    – 3 layers for the cart icon on the top right of the page including the different cart states (empty cart or 1 article, 2 articles).

Adding content to the first product page.


Step 1: Making the “Buy” button interactive

Let’s assume we have designed a product page (called “Article 1”) with a “Buy” button that, when clicked, should bring up a confirmation page and change the state of the shopping cart. To model this behavior, we can add the following interaction to the button: For the trigger, select “When the user clicks/taps” and add the following three reactions:

  • “then show page” to display the confirmation page informing the user that the article has been added to the cart
  • “then change layer visibility” with visibility set to “hide” to let the layer with the status “empty cart” disappear
  • “then change layer visibility” with visibility set to “show” in order to make the layer with the new cart status “cart – 1 article” appear.

Making the “Buy” button interactive and adjusting the quantity of the cart.


Step 2: Adding the “Continue purchase” link

Now let’s jump to the confirmation page, which should offer an option to return to the article overview to continue shopping. To model this behavior, we can use a similar reaction: a click/tap trigger should be combined with a show page reaction to display the start page as well as two change layer visibility reactions to display the correct cart status (1 or 2 articles) and hide any other cart status layers.

Making the “Continue purchase” link interactive to display the product overview with the correct amount of products in your cart


That’s it! You just finished the last part of your online store.

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


Happy Prototyping!

How to … work with pre-designed components

Recently, we added a lot of new elements to the stencil palette, which can save you precious time: The new elements are pre-designed arrangements of existing stencils that serve as building blocks for your prototypes and are ready to use out-of-the-box. Instead of starting from scratch, you can build your screens from those components to jump-start your project. The new components range from simple navigation patterns such as toolbars, navigation bars or menus to full screen templates, e.g. for login or profile pages.

Templates are now part of the stencil palette.

New pre-designed components help jump-start your project


1. Adding components

The new elements work just like normal stencils and can be found in a new section of the stencil palette: Just drag them onto the canvas to start designing. Looking for a special element? Just type a keyword to filter the list. You can also navigate the library using the arrow keys and add components by hitting “Enter”.

Quickly find and add templates to the screen

Quickly find and add components to the canvas


2. Customizing components

The components consist of several stencils each, but are not grouped, so you can edit them right away after positioning them on the canvas.

Modify every template by editing the single elements

All components can be easily modified after positioning


3. Reusing components

Hint: You can turn any component into a masters to save it for later use. This is particularly useful when you have customized a component and want to re-use it in the same or a different project. To do so, simply open the context menu and click on “Convert elements to master”.


That’s it! You have successfully used your first pre-designed components! Do you need help or are missing some “templates” in the list? Then drop us a line via or Facebook and Twitter.


Happy Prototyping!

How to … create a slider

Screen space is precious on a mobile device. That’s why special navigation patterns have been developed to display relevant app content in the most efficient way. We recently showed you 7 commonly used mobile navigation patterns including typical use cases. You can quickly build those navigations with Pidoco, and we’ll take a closer look at one of them today: the slider.

The slider is a great way to depict progressive or closely related content on a minimum of screen estate by displaying successive parts of the content in the same section of the screen, often while keeping the rest of the screen static (much like in a typical module tab pattern). Based on natural gestures you can swipe to the left or right and see content that is only displayed when your slider is in a specific position. For instance, take a transportation app where you can use the slider to switch from one transportation option to the next (e.g. car, train, bus or airplane etc.). To avoid a fiddly navigation, not more than 7 options should be used.

The slider consists of the following parts: Usually a horizontal bar that acts as a visualization of the sliding process. Several elements (e.g. bubbles, round shapes, rectangles) on the bar represent the specific slider states, each of which is connected to specific content.

And here’s how it goes …


1. Setting up the project

For this post, I will use a transportation app with three transportation options as example. To build our slider, we will need several layers that will contain the content specific to each of the three slider positions. Everything around the slider will remain static, so we will use a page for all that content. So, let’s create a new project as well as one page and the three required layers in the beginning. (Hint: Don’t forget to give your layers unique names.)

We commence with the start page and add the static content. Here I added a status bar and a title bar as well as some text and an image. The slider will be positioned at the bottom of the page, so we will leave some space there and continue with the layers.

Adding the static content to the start page

Adding the static content to the start page


2. Creating the slider

2.1. Building the basic structure

Now let’s create our slider. First, we go to the layer panel, select the first layer from the list and start editing. The slider will go to the bottom of the app and will have one element for each option. Here I used three round shapes for each slider position, added some labels and a line to connect the three options.

Building the basic structure of the slider on the first layer

Building the basic structure of the slider on the first layer


2.2. Customizing the slider

Now we can customize the basic slider and add the specific content for every position that is only displayed when the user moves the slider. Here I added some information about travel distance and duration.

For a better visualization of the selected option the current slider position can be highlighted. That’s why I used a bigger round and green shape and an icon.

Adding a highlighting element to the basic structure of the slider

Adding highlighting element to the basic structure of the slider


2.3. Adding interactions

Finally, we can make the slider interactive. To do so, add an Action area to the inactive slider positions and right-click to open the context menu. Select the “Interactions” tab and add a new interaction. In the Interaction dialog that opens, select the pairing “When the user swipes”, select the desired direction (left or right), and set the reaction “change layer visibility” to only show the layer for the selected slider position and to hide the other layers.

Adding interactions to the slider to create the swipe effect

Adding interactions to the slider to create the swipe effect


2.4. Completing the slider

Now we just copy the entire slider with its interactions to the other previously created layers to paste it there. By default, the slider will conveniently be copied to the same position. Finally, we only have to adjust the reactions (which layer to show) within the Interaction dialog as well as the highlighting of the slider.


3. Simulation

Voilà! To test your slider, just open the Pidoco app on your mobile device (available via Google Play or the App Store) and start the simulation of your project by selecting it from the project list.


And if you need a little inspiration, here’s what my project looks like.


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

Happy Prototyping!

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!

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!


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.