The Design Sprint – Our Experience

The sprint

The past two weeks we have worked on a prototype for a customer in the financial world. They approached us with an idea for an app. Because it wasn’t clear enough what the potential app would be about, we’ve chosen a design sprint to collaborate with the customer and find out what the app should be about.

A design sprint consists of five stages:

Schermafbeelding 2016-06-13 om 12.04.04.png

We have used these stages in iterations of 3 days:

Day 1: Empathize

  • In this stage we made sure there was a clear understanding of the content ahead.

Day 1: Define:

  • With the information gathered during the first hour(s), we went ahead and started to define the customer profiles of their users

Day 1: Ideate:

  • Knowing the content and the users of the new app, we started with ideas that could lead to an app. Everyone was drawing their ideas as simple as possible on a piece of paper. Afterwards, dot-voting would make sure the best ideas were chosen for further analysis.

Day 2: Prototype:

  • In the previous stages we gathered information and ideas we used as input for the prototype. The first prototype was created as a clickable PDF. However, we soon found out that users got stuck on trivial stuff like static content and missing animations. By creating a simple app we gave users the idea that they where using an actual app. That helped a lot to get better feedback on the content.

Day 3: Testing:

  • We used usability tests to evaluate if the features in the prototype matched our expectations. We gathered around 4 to 6 users each testing day so we had enough information and input for the following iteration.


Our experience

To be honest we were a bit skeptical at first, but in the end we couldn’t have chosen a better approach. Because of the short iteration we were forced to be creative and concise at the same time. This resulted in a satisfied customer who knows their target audience and has an idea of what the actual app could be.

We encourage those that want to create a great prototype with well thought out content within a short amount of time to use a Design Sprint. We’re sure you will love it!

For more information about Design Sprints check out Google Ventures.


Appril: Mobile UX Design met Keynote (Utrecht)

Na een geslaagde workshop in Eindhoven op 3 april hebben we wederom een workshop gehouden. Het event heeft ditmaal plaatsgevonden in Het Kapitaal in Utrecht. Een groot aantal deelnemers (26!) waren aangeschoven tijdens de tweede workshop. In tegenstelling tot de voorgaande workshop waren er minder designers aanwezig, maar meer App developers.

Tijdens de workshop kwam al snel naar voren dat er veel enthousiasme was over het maken van een prototype met Keynote. De resultaten mochten er ook zijn. Iedere groep heeft zijn eigen prototype kunnen maken en deze mogen presenteren tegenover de andere deelnemers.

Om de keynote te bekijken van de workshop kan de onderstaande link gebruikt worden:
Appril presentatie Utrecht – Prototyping met keynote

Onderstaand een impressie van de workshop!

IMG_0005_2 IMG_0006_2 IMG_0007_2

Debugging Web Content on iOS

Inspecting and debugging a website though a web inspector is a common practice among web developers. This blog explains how to do the same when using web content on an iOS device. You will need Safari 6.0 or higher to do this.

1. Connect your iOS device to your Mac

2. Enable Web Inspector in iOS

The first step is executed on your iOS device. Under Settings -> Safari -> Advanced you will find an option called Web Inspector. Enable this option (as shown in image 1) and your device is set for Developing purposes.

Image 1

3. Enable Develop Menu in Safari

The second step in the process is executed on your Mac. Open Safari and enable the Show Develop menu in menu bar option. To do this, select Safari -> Preferences -> Advanced. In the bottom of the popup you will find this option (as shown in image 2)

image 2

4. Select the Content To Debug

When the settings are correctly set, you can inspect content within an application on your iPhone. To do this, simply start your application on your device and view the menu within Safari as shown in image 3:

image 3

A list of options will appear. In this example an iPhone (Berry-iPhone) is used to inspect the content on Safari.

When the option is selected, a list of websites that are currently opened on the iOS device will be shown. This can be websites that are running on Safari or in a currently open native iOS application.

This doesn’t only work when using an actual device, it is also possible to do the same on an iOS-Simulator. Image 3 also shows the iPhone Simulator as an available option in the development menu.

5. Start Debugging the Content

When a choice has been made for the website that needs to be debugged, the Web Inspector will appear. You can now use the web inspector to inspect web content, debug JavaScript etc.

iOS Tutorial : Preview Paging


Paging is a widely used functionality within iOS applications. Paging is build by using an UIScrollView. While scrolling to the left or the right, the user will swipe the application content from page to page.

Besides this normal behaviour of a scrollview, an iOS developer could also like to build a pager like the Safari Page Preview to enhance the users experience:


To be able to create such a paging scrollview, follow the three steps below:

Step 1:

Create a UIView

CGRect viewFrame = CGRectMake(0, 0, 300, 100);UIView *view = [[UIView alloc]initWithFrame:viewFrame];[view setClipsToBound:YES];

Step 2:

Create a scrollView with a width of 250, and position it in the middle of the view

CGRect scrollFrame = CGRectMake(25, 0, 250, 100);UIScrollView *scrollView = [UIScrollView alloc] initWithFrame:scrollFrame];[scrollView setClipsToBound:NO];

CGSize scrollContentSize = CGSizeMake(500, 100);

[scrollView setContentSize:scrollContentSize];

[view addSubview:scrollView];

When ClipsToBound is set to NO, the content of the scroll view will be visible outside of the scroll views own frame. The same applies to the view, set ClipsToBound to YES, so the content of the scroll view will not appear outside of that view.

Having implemented this, it should also be possible to scroll the view while a user touches the view outside of the scroll view.

Step 3:

Create a method for the view that recognizes touches:

-(UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event {UIView *child = [super hitTest:point withEvent:event];if (child == self) {

return self.scrollView;


return child;


This method allows a user to scroll the pages within the scroll view, without touching the scroll view itself.


Standard paging is not always good enough to create a great user experience. Using a tiny bit of code to create an additional functionality for existing components, helps you to reach that experience.

How-To: Alert Dialogs on iOS

When designing your application for an iOS device, you might run into a common interface feature; The Alert Dialog. These dialogs are simple and easy to use features for a user, but without careful positioning of buttons and the overall know-how of alert dialogs, it could turn out into a disaster for the user. To counter this, just follow the basics as described below.

The Description

Alert dialogs are temporary views that will appear on top of your application to bring the user’s attention to some detail or ask the user to confirm an action being done. An alert dialog will popup in the center of the screen and all other interaction with the application is disabled until the dialog is canceled.

The Layout

An alert dialog consists of three separate parts; a title, a message body and one or more buttons. Below is a visual representation of an alert dialog:

1. Title

The first element is the title. Try to avoid titles that contain only one word or take up more then one line. Keep them short and descriptive. Do not forget to use title-style capitalization, in which the first character of most words is capitalized. An example for a good title could be “New Text Message”, so do not use a title like “You have a new text message”.

2. The Message

While an iOS device gives you enough space to show the user a lot of information, try to keep the message within an alert dialog short and to the point. Mostly this ends up with using two lines long sentences, where only the first character in the first word in each sentence is capitalized (sentence-style capitalization). Whenever your message will contain too many words, the device will create a scrolling alert dialog. This is something you really want to avoid, since it gives a bad user-experience.

3. The Buttons

The buttons within the alert view are the controls that could make or break your workflow. An alert dialog mostly consists of two buttons. Using three or more buttons is not preferred and could give the user some difficulty to read and respond to to the information you are presenting in your dialog.

A very important part of the buttons is the positioning;

  • Whenever you are deciding to show an alert dialog that performs a risky or destructive action, place a light-colored Cancel button on the right and place a dark-colored OK button on the left.
  • Whenever you are deciding to show an alert dialog that performs a positive action, place a light-colored OK button on the right and an dark-colored Cancel button on the left.

The coloring and meaning of the buttons are always the same, where the left button is dark-colored and represents a negative action and the right button is light-colored and represents a positive action.

While it might seem useful for bringing the user’s attention to your dialog, try not to overuse them. Using too many dialogs in your application decrease in how important they are and they will most often slow down the flow within your application. Instead, try designing a way to show your users more information within the screen that is currently available.