How to … create a sidebar

Recently, we spoke about mobile navigation patterns and their impact on creating valuable content on limited screen space without losing important options. This time, we take a closer look at the sidebar.

The sidebar is best used to offer a secondary view that contains additional options like user settings, a list or a contact form etc., but it doesn’t make you leave the current screen. It’s a collapsible panel, often with the same height as the screen, that only slides in with a tap on an icon, usually a gear wheel or persona icon.

And here’s how it goes …


1. The project setup

To visualize our navigation pattern, we go back to our previously created project called “Watch it!“. You might remember: This mobile app contains a navigation bar with an overflow menu. Today, we’ll add a sidebar to it which can be accessed via the persona icon in the top right corner. The sidebar grants access to the user profile and various profile settings and options.

Recap: In our mobile app, we have already created one start page with one layer that contains an overview on the available movie genres. Also we built a navigation bar on another layer which contains a hamburger menu on the left and the overflow menu acts as a collapsible quick-access menu to the available movie genres.

The start page of the “Watch it!” app with the navigation bar


2. The Sidebar

For the second part of our “Watch it!” project, we need in total: 1 page for the sidebar itself and one page for each entry within the sidebar.

2.1 Creating the sidebar

Let’s create the actual sidebar which will list all available options connected with the user profile of this app (changing password or language settings or getting in touch with the support etc.). To do so, we add a new page (here called: “1-Sidebar”) and immediately add the content. Here: I used a grey rectangle as background and added text stencils.

Creating the sidebar and its content


2.2 Setting up the sidebar content

As our sidebar will only give an overview of the available options, we create a new page for each entry of the sidebar. (In my project I built a total of 8 pages.) Now let’s fill the page with content. Here I  added some text elements, text input fields and a button on the “Password” page.

Adding content to the content pages of the sidebar

To save time, just create one page first, then duplicate it and then alter the content on the remaining 7 pages.


3. Adding interactions

Let’s go on with the interactions. We’ll have to take three steps now because 1) the sidebar is supposed to be slideable, 2) the sub-entries listed in the sidebar should be clickable, 3) the sub-level pages of the sidebar have to be slideable to re-access the sidebar panel again.

3.1 Making the sidebar slideable

To leave the sidebar and get back to the start page of the “Watch it!” app, the sidebar is supposed to disappear with a swipe gesture. So we select the grey rectangle (as it spans the entire page), open the interaction dialog and add the action when the user “swipes”, set the direction to right and use the reaction “show page”. We refine the interaction selecting the option “Instant link” and setting the animation to “slide in from left”.

Making the sidebar slideable


3.2 Making the sidebar list entries clickable

Having already created the 8 pages that represent the content of each entry of the sidebar panel, we continue with creating interactive links. To do so, we open that page (Here: 1 – Sidebar) and click on the respective text, open the context menu and select the respective page from the dropdown menu next to “Target”. Here: I linked the entry “Change password” with the page called “Password”.

Quickly link the entries of the sidebar

Repeat that step for the entries of sidebar.


3.3 Making the sidebar sub-content slideable

Finally, we want to add more interactions to the pages that display the sidebar content. To leave the sub-level view and go back to the sidebar panel, we want to use a swipe gesture. So we open one of the previously created sidebar pages.

Let’s start with the first one: I opened the page called “Password” and added two action areas for that parts of the screen that are empty. (Hint: They might even overlay other elements like the headline.) Again we need the interaction pairing: When the user “clicks/taps” then “show page”,  select the previous sidebar page, set the options to “Instant link” and the animation to “Slide in from left”.

Building a slideable page for each entry of the sidebar.

To save time again, just copy and paste the action areas to the remaining 7 pages and adjust the linked pages.


4. Connecting the sidebar with the navigation bar

4.1 Extending the navigation bar

Now we open the layer that contains our navigation bar and add a persona icon to the navigation bar. To do so, we use the quick-search option atop of the stencil palette and drag the respective icon to its position.

Adding a persona icon to the previously created navigation bar


4.2. Connecting the navigation bar and the sidebar

All that’s left is connecting the sidebar with the profile icon in the navigation bar. To do so, we select the persona icon on the right and add the interaction pairing when the user “clicks/taps” then “show page” , select the one that contains the sidebar and use the animation “slide in from right”.

Access the sidebar menu


5. Simulation

Voilà! To test your sidebar, take your mobile device, open the Pidoco app (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 your mobile app that includes a sidebar

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


Happy Prototyping!

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!

New Release: Speeding Up Your Prototyping

Brand new elements

Hooray! We’ve been thinking about adding this feature for a while now – and here it finally is: With our December release we are adding a new section to the stencil palette which will contain a large selection of new elements to give you a head start on your projects.

Instead of beginning your projects from scratch, you can browse the new palette section to find exactly the right building blocks you need to get your prototype off the ground in no time. The building blocks consist of groups of stencils that can serve as a starting point for your designs, ranging from simple navigation patterns (e.g. toolbars, tab bars, menus) and various types of forms to full screen templates (e.g. login page, search results page, profile page).

New: Add pre-designed templates to your project

New: Use our pre-designed building blocks to jump-start your project

You can’t find what you are looking for? No problem! Send an email to and we will try to add it.


Custom Stencils now are Masters

Did you know that you can turn any stencil or group of stencils into a re-usable asset that can be managed and edited in one location? Imagine you have just built the perfect login form and want to re-use this form across various screens in your project. You could copy and paste it every time, but if the form changes, you would have to touch every screen again. Why not create a master form that you can re-use on various screens, and any change you make to the master will update all the screens automatically? This feature – thus far known as “Custom stencils” to Pidoco users – will be renamed to “Masters” and be available for the new templates as well. So you can pick any template, edit it to suit your specific needs, then turn it into a master that you can update across the entire project with one simple action. Learn more about masters…

Renamed: Custom stencils are now Masters


New toolbar design – more canvas space

While we were at it, we also redesigned an important part of Pidoco – the toolbar. We took out some fluff, made it simpler, and in the process freed up a lot of space for you to work more efficiently. With the gain in canvas space, you can expect to be even faster with your prototyping! Try it out…

Re-designed: the new slim and simple toolbar

Re-designed: More space for your designs with the new toolbar


Let us know in the comments what you think or email us at!

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!

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!