When we design our websites, we progress from wireframing to prototyping to – finally – a full design.

I wanted to explore and expand on what Prototyping actually means by taking you through the full process.

Note that I created another course that covers the first step of designing a website: building a wireframe. You can read about wireframing and watch my 30 minute video course here.

In this tutorial, we'll cover:

1. What an Early Prototype is
2. Creating a Structure: Frame, Rows, Columns
3. Adding Content: Header, Slider, About
4. Designing Sections
5. Conclusion: What we've learned from the prototyping process

What is an Early Prototype?

A prototype is normally the secondary iteration of a design, as it is built on top of a wireframe.

A wireframe usually involves a simple drawn sketch via paper, pen, or online tool. Next we build the prototype, which is our more refined mockup for the website or app.

Let's take a look at the early wireframe we built in the previous article:

The wireframe we created in my previous wireframing course.

It has a number of pages, sections, and areas where text and images will be added later.

The goal, then, in the Prototype is to build this visually, but without adding color or images.

In this example, I will be using Figma to do the Prototype. You can view the whole Figma protype here.

How to Create a Website Prototype Structure: Frame, Rows, Columns

When we created the wireframe, we considered the grids – but they were hand drawn.

When doing an early prototype, we have to define them properly so that the whole design follows the grid structure.

In this example, I will be using a 12-column design with a regular width of 1140px, which is traditionally used and seen in Bootstrap designs. This gives us a 15-30px margin between grid units.

This will be useful later when we collapse the columns to rows for mobile responsiveness.

You can create your own grid structure in Figma. But be aware that you (or someone else) will later need to actually code these designs.

Whenever you're designing something, be sure to take the developer into consideration.

How to Add Content to a Website Prototype: Header, Slider, Sections

Unlike the Wireframe, we are no longer representing text with lines, and headers with blocks. Instead we need to fill out content for a mockup.

This doesn't mean adding colors or images. But it does mean we have to show real text.

At this stage, it's a great idea to make sure that the header and sections are shown with the actual content they will be intended to hold. This will allow better selection for colors and images in later stages of the design.

In this part of the example, I built out the slider with hero text, and a description underneath. There are a few things to look out for at this phase of the prototype process:

• Font sizing and positioning
• Content location and spacing
• Margins and padding between sections and content

How to Design Sections of the Website Prototype

For prototyping and the final mockup, it's important to start layering your groups and sections. Sections can include things like the header, the "about us" section, and the sponsors section.

You can create groups in your UI tool (Figma does this with Ctrl+G). Label your sections and set them with different background colors. This will make it easy to identify them, and will allow you to easily move them about.

Too many times I've been asked to move certain parts of a website up and down the grouping. By grouping all your components into sections, you will make it much easier on yourself during the prototype phase of the design work.

Conclusion: What We Have Learned from the Prototyping Process

As we build out the rest of the design, it's important to ensure that this early prototype does not become a full mockup for a website design.

It's easy to get carried away. But the goal of doing a prototype after a wireframe is to ensure that we can continue to plan the website's development.

It's much easier to identify problems and issues in the early planning stages and update them before diving into creating the full design. Such prototyping may only take you a few hours, but it can save days worth of effort later in the process.

Once you've prototyped multiple pages, you can move on to the full mockup design phase. This will involve figuring out color theory, typography, and images that work accordingly. We will take a look at this in the next article in this series next month.

Bonus: Adding an Interactive Prototype Run

We only created a single page for this example. This said, prototyping also allows you to create an emulated example of the site operating.

This emulation is very useful for conducting demos, testing how clients respond to seeing a real world example of an early mock-up, and revising how all of your links flow.

I hope you enjoyed this article. If you don't know who I am, I'm Adrian from Australia. ? I have a tiny channel on Twitter & YouTube, so if you want to know more about me or enjoy my content, check me out sometime ?

• Youtube: https://youtube.com/adriantwarog
• Twitter: https://twitter.com/adrian_twarog

When developing an MVP (Minimum Viable Product), you intend to go from idea to prototype as fast as possible. The faster you can prototype your idea, the faster you are able to iterate upon it.

As you’re moving from abstract idea to working prototype, you usually don’t want to spend a lot of time creating a custom design when you should be focusing on the functionality of the application. To solve this issue, we use frameworks like Bootstrap to quickly achieve a structured layout with a UI that looks “pretty good” without too much effort.

What we really want to achieve, in terms of design, is to rapidly create a UI that is recognizable and coherent.

I’m about to show you a super fast way of going from abstract idea, to design, to working prototype with Material Design. Material Design is Google’s open source design system that they use for all their applications. This makes it recognizable because it is intuitive and easy to navigate, and most people are familiar with it already. If you haven’t already, you should definitely check out what Material design is all about.

By using the Material Design Plugin for Sketch, we’ll create our own customizable Material Design system. This will include a great set of components that will allow us to quickly create coherent designs for our prototype app. The app we’ll make is a simple reminders app.

We will use front-end framework Vue.js together with the Material Design component library Vuetify.js to realize our app designs. Lets get to it!

Creating the design system

Download this plugin for Sketch. Once installed, simply go to Plugins > Material > Open Theme Editor to see the Material Design Theme Editor. Click “Create New Theme”, and we choose to begin with the Baseline theme.

We are now presented with our Material Design system of Sketch components.

Your component library.

In the Theme Editor, you may change the primary and secondary color, change the font, change the shape of elements’ corners, and include custom icons. For this example, we will change none of these and just stick with the defaults.

We have now created our design system. As you can see, it says that the document is a library. This means that any changes you make to this Sketch file will affect your mock-ups and update all your designs with those changes. How great is that?

Before we continue, we will also install the Sketch Material plugin, which will add some modules that we’ll soon use.

Mock-ups

Let’s start by opening a new Sketch document then creating a new iPhone artboard and saving it as MaterialReminders.sketch. This is where we’ll create our designs for our application. But first, lets explore the rich component library that is at our disposal.

Under Insert > Symbols you should see the component library we just created.

Explore all the components in our library and imagine the possibilities!

Just so many components! We can now begin to create our designs. But first we must break down what functionality we want this reminders app to have. We’re keeping it simple and only adding the ability to:

• Add a new reminder
• Delete a reminder
• Check off a reminder from your todo list
• Uncheck a reminder from your completed list

Fantastic, let’s speed things up and begin dropping some components into our first iPhone artboard.

We start with a top navbar. Drop it in and place it then size it to fit the screen. We’ll have to change the first icon to an “Icon / Add / Filled” for the Menu Icon and change icon color to white. Then change all the other icons to none, since we wont be needing them. We also change the headline to Reminders.

Customizing for your needs becomes super easy with symbol overrides.

We’ll now start dropping in some dummy reminders. We’ll create our reminders like a list, so let’s find a suitable component. We’ll use “List / Single Line / Indent / Body 2”.

Now we will center the list object, take away the bottom divider, set the text to “Chores”, and lastly change the icon to “Icon / Checked Circle / Outlined”.

Add a title by inserting a text field, then using the Plugins > Sketch Material > Typography module to change the style to Subhead.

When selecting a text field and going to the Typography module you can click on a style to apply it.

It’s beginning to look pretty good so far! But we are now faced with a problem. We want to also include list controls to the right in each list object, because we want to add a delete button there. But the devs over at Google did not include any override for that in the Sketch component. No worries though, we’ll fix this by going into our library file and adding our icon to the symbol, thus updating it throughout our project.

Go to the library and find the list component we used in the Material Components page. Then, double click it to go to its symbol. Click the icon to the left so that it is in focus, then copy paste and move it over to the right. Done deal.

When we switch back over to our project, we can now see that in the the top right corner it says “Library Updates Available”.

Changes have been detected in the library. You may choose to update your designs with these new changes.

Now we should be able to change the right hand icon to “Icon / Close / Filled” which will be the button to remove a reminder completely from the list.

To create a list of reminders, we simply copy paste a bunch more list objects, change their text, then change the title that we added to Todo.

Todo list is complete.

Then we copy paste that entire list to create the Completed list. On this new list, you must change the title to “Completed”, then change all the icons to the left to be filled instead of outlined.

Select all the list items to change the icons to them all at the same time.

Were almost done with our mock-ups. To speed things along, I just changed our artboard color to #FAFAFA and added a “Shadow / 00dp” behind each of my lists.

Completed mock-up.

This mock-up view is now complete. The next one we need to create is the dialogue that appears when you press the add button.

We begin by copy pasting the artboard we’ve been working on to create an exact copy. Then, we use the Dialogue and Form modules under “Plugins / Sketch Material” to create a dialogue and a form separately. These are then combined and a opaque box is placed behind. I switched out the transparent action button in the dialogue to a primary colored button.

We are now done with Sketch. Of course, we could add more features and expand our mock-ups even more, but we will keep it simple for now. The next step is to write the code that will become our app!

Vue with Vuetify

Now to the fun part — coding. We will be using Vue.js which is a front-end UI library written in JavaScript. It’s really easy to learn, and checking out their website would be a first step. To implement Material Design, we’ll use the Vuetify.js component library which includes a bunch of Vue components along with a grid system to easily organize your layout.

We start by simply copy pasting the example markup that’s on the Vuetify starter page. Let’s look at what this does for us.

When looking at HTML, start from the outside and work you way inwards.

We have our <head> and &lt;body></body> tags.Inside the &lt;head></head> tag we have <link> tags that` will pull in the required vuetify.min.css file and Google Fonts.

In the <body>&lt;/body>; we have a

Further down you have two <script><;/script> tags that import the Vue.js and Vuetify.js modules into our page.

Lastly, after the import statements, there is a third <script><;/script> tag which creates a new Vue() instance. This is where we will write all our JavaScript code.

We can see that the instance is hooking into ‘#app’ which is the ID of the <div> tag in our HTML. This lets our Vue instance know where to inject our UI.

Inside of the <v-content></v-content> tag we will soon place all our Vuetify components. But first we will save what we have for now as index.html, and then open the file in our browser, where we should be presented with “Hello world”.

We continue by looking up what HTML we need for the top navbar component in the Vuetify documentation. The tag we’re looking for is <v-toolbar app></v-toolbar> . We’ll also have to add a <;v-btn> inside this navbar so that we can press it to display the dialogue to add new reminders.

In this button we’ll also add a @click= event which will set addModal to true which will bring up the dialogue modal. We add this in between the <v-content></v-content> tags:

<v-toolbar app color="primary">  <v-btn color="primary darken-1" icon @click="addModal = true">    <v-icon>add</v-icon>  </v-btn>  <v-toolbar-title>    Reminders  </v-toolbar-title></v-toolbar>

Next, we must add the HTML for the dialogue. This will live right after the <v-toolbar-title></v-toolbar-title> tag, but still inside the <v-toolbar> tag. Here is the dialogue:

<v-dialog v-model='addModal'>  <v-card>    <v-card-title>Add a reminder</v-card-title>    <v-card-text>      <v-container grid-list-md>        <v-layout wrap>          <v-flex md12>            <v-text-field v-model="newTask" label="New task"></v-text-field>          </v-flex>          <v-flex md12>            <v-btn color="primary" @click="add">Add</v-btn>          </v-flex>        </v-layout>      </v-container>    </v-card-text>  </v-card></v-dialog>

Here we add a <v-card-title> with “Add a reminder” as a title. Then we use the Vuetify grid system to create a list that spans all 12 columns. We add a <v-text-field> that binds to 'newTask' and has a lable that says “New task”. There will also be a button that, through the @click= event, triggers the 'add' function that we’ll write in just a second.

After saving the changes to your document, you should end up with something like this when you refresh your index.html page in your browser:

Don’t worry that the dialogue does not yet work — we must first add the functionality for it inside our Vue() instance. We do this by adding the following to our instance right after the el: '#app' but separated by a comma:

el: '#app',data: {  addModal: false,  newTask: ''}

The data object is where we will store our application state. With this tweak, our dialogue should now work. Save and refresh the page.

Now whenever you click to open your dialogue modal, the internal state in data: {} is set to addModal: true, which then displays the modal. Similarly, whenever you write a message in the dialogue’s text input, it will be saved in newTask since the <v-text-field></v-text-field> is bound to it through v-model=.

We’ll now add the code for the add function that will save whatever is inside newTask to our soon-to-be list of reminders. This function must be located inside the methods object, which we’ll add after our data: {}, object in the Vue instance.

The function will look like this:

add() {  if (this.newTask !== '') {    this.tasks.unshift({text: this.newTask, completed: false})    this.addModal = false    this.newTask = ''  }}

After enclosing the function inside the method: {} object, the code should now look like this:

new Vue({  el: '#app',  data: {    addModal: false,    newTask: '',    },  methods: {    add() {      if (this.newTask !== '') {        this.tasks.unshift({text: this.newTask, completed: false})        this.addModal = false        this.newTask = ''      }    }  }});

When the add() function fires, it will add our task from newTask to our not-yet created tasks list unless it’s empty. It will then close the dialogue by setting this.addModal = false and set the newTask to empty again.

Let’s create our task list so that we can begin entering some reminders. Inside the data object, place this code:

tasks: [   // Some dummy data   {    text: 'Chores',    completed: false   },   {    text: 'More chores',    completed: false   }]

These will be our dummy reminders. As you can see, we have a completed key that is set to either true or false so that we can differentiate between the tasks that are completed and those which are not. This also means that we can’t simply display our tasks list as it is in our UI, because then we would be displaying completed and non-completed tasks together.

The way we’ll solve this is with computed properties. They work by constantly watching for changes in your application and returning a computed value based on the changes.

We need two computed properties: one for the todo list and one for the done list that will each separate incomplete and completed tasks. We add computed: {} after our methods: {}, and drop in todo: function() {} and done: function() {} computed properties. The todo function will return this.tasks.filter(function(task) {return !task.completed}) and the done function will return the opposite by removing the ! (which means “not”) in front of task.completed . The code should look like this:

computed: {  done: function() {   return this.tasks.filter(function(task) {return task.completed})  },  todo: function() {   return this.tasks.filter(function(task) {return !task.completed})  }}

We’re now ready to render our two lists in our UI. This is going to be quite a bit of markup, but don’t worry, we’ll walk through it together. We’re going to replace <v-container>Hello world</v-container> by selecting it and then pasting in the following in its place:

<v-container grid-list-md>  <v-layout row wrap>    <v-flex xs12>      <v-list>        <v-subheader>Tasks to do</v-subheader>        <v-list-tile v-for="task in todo">          <v-list-tile-action>            <v-btn icon ripple @click="complete(task)">              <v-icon v-if="task.completed">check_circle</v-icon>              <v-icon v-else>check_circle_outline</v-icon>            </v-btn>            </v-list-tile-action>          <v-list-tile-title>            {{task.text}}          </v-list-tile-title>          <v-list-tile-action>            <v-btn icon ripple @click="remove(task)">              <v-icon color="grey lighten-1">cancel</v-icon>            </v-btn>          </v-list-tile-action>        </v-list-tile>      </v-list>    </v-flex>              <v-flex xs12>      <;v-list>        <v-subheader>Completed tasks</v-subheader>        <v-list-tile v-for="task in done">          <v-list-tile-action>            <v-btn icon ripple @click="complete(task)">              <v-icon v-if="task.completed">check_circle</v-icon>              <v-icon v-else>check_circle_outline</v-icon>            </v-btn>            </v-list-tile-action>          <v-list-tile-title>            {{task.text}}          </v-list-tile-title>          <v-list-tile-action>            <v-btn icon ripple @click="remove(task)">              <v-icon color="grey lighten-1">cancel</v-icon>            </v-btn>          </v-list-tile-action>        </v-list-tile>      </v-list>    </v-flex>  </v-layout></v-container>

To begin with, we add grid-list-md to our container. Then we add <v-layout row wrap></v-layout> and <v-flex xs12> and add our two <v-list> tag`s with a in each. This creates our basic layout in form of two lists.

Then, we will add <v-list-tile v-for="task in todo"></v-list-tile>; where the v-for= statement iterates through each task in our computed todo property. Same thing goes for the done property. As we iterate through each list we will render each list item. Each item will display the task.text and will have two buttons: one for triggering the complete() function and one to trigger the remove() function.

Let’s continue by writing these inside of our method object.

complete(task) {  task.completed ? task.completed = false : task.completed = true},remove(task) {  this.tasks = this.tasks.filter(function(x){return x !== task})},

The complete function body contains a ternary operator which will toggle the complete button on each reminder. Whenever task.completed is set to true on a reminder, the entire UI will update and move this reminder to the “Completed” list.

You should now have a real working prototype of our reminder application!

Final thoughts

In this article, I was not trying to show how to specifically build a useless reminders app with limited functionality (although that is exactly what I did). Rather, that you can use these tools that I have presented to you to very rapidly build a collection of mock-ups and then, with minimal setup, create a real, working prototype from these designs.

With this in place you can now tweak your component library, build out your designs, and then quickly implement them in code as you go along.

You can find the finished Sketch file and code here. I also strongly recommend diving deeper into the tools I’ve talked about to fully realize their potential.

Hope you enjoyed this article and that you find it useful. Comment if you have any questions or let me know what you thought of it.

Everything you need to know about rapid prototyping in 7 minutes (or less)

_Photo by [Unsplash](https://unsplash.com/photos/ZEtE38ybfao?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Denise Jans on <a href="https://unsplash.com/search/photos/sketch?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

The process of going from an idea to a product is a messy one. Learning how to prototype your idea, getting feedback, and iterating on it is the most critical skill anyone aspiring to build their own products should have. This is also one of the most significant parts of a UX Designer’s job.

Prototypes come in many forms, from a rough sketch on paper to an interactive simulation that looks like the final product. This guide is for complete beginners who want to understand what Prototyping is all about.

We’ll cover the meaning of a few terms related to rapid prototyping as well as the following:

What is Rapid Prototyping?

Rapid Prototyping is an iterative process used to visualize what a website or an application will look like in order to get feedback and validation from users, stakeholders, developers, and designers.

When used well, rapid prototyping will improve the quality of your designs by enhancing communication between the various parties and reducing the risk of building something that no one wants.

What do you need to prototype?

A prototype is not designed to be a fully functional version of a system, but is only meant to help visualize the user experience of the final product. As Google Ventures design partner Daniel Burka says:

The ideal prototype should be “Goldilocks quality.” If the quality is too low, people won’t believe the prototype is a real product. If the quality is too high, you’ll be working all night, and you won’t finish. You need Goldilocks quality. Not too high, not too low, but just right.

You can prototype not just screens, apps, or websites, but almost anything. Prototyping is an excellent method to test the following (examples provided):

• New functionalities: Prototype Instagram Stories in the Instagram app (before they were launched)
• Changes in a workflow: Prototype Medium’s new publishing flow after the introduction of paid memberships
• New technology: Prototype a self-driving car journey!
• New interface: Prototype Apple Watch interface (when it first launched)

So, now you understand what rapid prototyping is for. But how do you do it? We’ll cover that next.

The Rapid Prototyping Process

Rapid Prototyping involves a three-step process, repeated as many times as needed:

1. Prototype: Create a visual mock-up of your solution or interface.
2. Review: Share the prototype with users and evaluate if it meets their needs and expectations.
3. Refine: Based on this feedback, identify areas that need to be improved or clarified.

Prototype, Review, Refine, Repeat.

A prototype will usually start with a very simple mock-up of key areas and become more complex with each iteration as you gather more data from user feedback.

How much should you include in your prototype?

Focus on the critical functions that will be used most often. The point of rapid prototyping is to show how a feature will work or what the design will look like without prototyping the entire product in detail. Remember, we’re aiming for the Goldilocks quality!

Prototype one User Flow at a time. Instead of going screen by screen, base your prototype on a story that will take the user through the areas that you want to prototype. This way, you will get more accurate feedback because your prototype will reflect real life scenarios. For instance, prototype the “sign-up/sign-in/reset password” flow together.

Also, remember to have an iteration plan in mind. A good rule of thumb when planning iterations is to start broad and then work your way towards a more detailed version of the solution. As you iterate, the fidelity of your prototypes, as well as how much you include in them, will increase.

But wait, what is this fidelity?

What is meant by the fidelity of a prototype?

Fidelity refers to how closely a prototype matches the final product or solution. You can choose from a lot of different options and levels of accuracy, depending on the stage of the process and the goal of the prototype.

Visual (Sketched vs. Styled)

Layout and design are the most noticeable aspects of a prototype’s fidelity. If a prototype is produced with a high level of visual fidelity from the beginning, users will tend to focus on visual rather than functional details, which would distract from the primary goal of the early stages of prototyping.

Static prototypes with two different fidelity levels - sketched (low-fidelity) and styled (high-fidelity)

Functional (Static vs. Interactive)

Should the prototype be static, or does it have to look fully functional (interactive)? Both versions have pros and cons: static prototypes are simpler and quicker to implement, while interactive ones can be used later for usability testing and user training.

_A high-fidelity Interactive Prototype. ([Source](https://framer.com/getstarted/examples/" rel="noopener" target="blank" title="))

Content (Lorem ipsum vs. real content)

In the early stages of prototyping, standard “lorem ipsum” content can be useful to avoid distracting the user so they can focus on providing functional feedback instead of commenting on changes in the text.

However, as the prototyping process continues, evaluate the need to replace dummy text with real content so users can get a feel for how it affects the overall design.

Using real labels is also an excellent opportunity to test whether your “copy” is working well or not. “Copy” is just a fancy term for text labels and information you see on the screen, like calling the “Publish” button “Publish,” “Post,” “Send,” “Done” or something else.

What fidelity levels exist?

• Low-Fidelity: Low-Fi methods like pencil-and-paper sketches produce static prototypes with low visual and content fidelity that allow for quick and easy changes. This forces the user to focus on functionality and on how they will use the system instead of what it looks like.
• Medium-Fidelity: Computer-based tools like Visio produce what we can call medium-fidelity prototypes in the form of wireframes and workflows. This level of fidelity is used to demonstrate a system’s behavior, to determine if user needs are being met, and to evaluate the user experience.
• High-Fidelity: High-fidelity prototypes can sometimes be so realistic that they are often mistaken for the real product. They are also much more time-consuming to produce. Tools like InVision, Sketch, Figma, Adobe XD, Framer, and so on allow non-technical users to create high-fidelity prototypes. Although these cannot be converted into usable code, they can be very handy later for usability testing or user training purposes.

_From Low-Fi, to Med-Fi, to Hi-Fi. ([Source](http://murdochcarpenter.com/portfolio/wireframes/" rel="noopener" target="blank" title="))

How do you select which fidelity level to prototype on?

Most of the time, designs are best evaluated by starting with a rough sketch, then moving on to higher fidelity levels depending on the system’s complexity and requirements.

Sometimes, your choice might be guided by client requirements or areas of focus. For example, if you want to evaluate the visual impact of an interface change, you might want to go with a styled design instead of a rough sketch. Or if your solution is message focused, you may decide to use real content instead of standard “lorem ipsum” placeholder text.

How do you choose a prototyping tool?

There is a wide variety of tools available for prototyping depending on your needs and approach. Before choosing a tool, here are a few questions to ask:

• How much time would it take to learn how to use the tool?
• Does it support prototypes for the needs of my product (web, software applications, mobile apps, some new technology, and so on)?
• Does the tool allow me to share my prototypes with others and gather their feedback?
• How easy is it to make changes to the prototype?
• Can I use pre-defined templates and stencils with this tool?

Paper and pencil, Sketch, Figma, Framer, Photoshop, Illustrator, XD, Origami…

Prototyping best practices: do’s and don’ts

Do’s:

• Work with users and stakeholders to get the most feedback and engage them in the ownership of the final product
• Set expectations early by making sure the users and stakeholders know that prototyping is a way to get answers to specific questions, and does not represent the finished product.
• Make your high-fidelity realistic (including response delays) so that users and stakeholders are not disappointed when they compare it with the final product.
• Save templates and stencils to reuse on future projects.

Don’ts:

• Don’t prototype features that won’t be in the final product
• Don’t be a perfectionist. Good enough is your friend. The goal of rapid prototyping is to give everyone a common ground.
• Don’t prototype everything!

If your’re wondering how you should go about testing out your prototypes, read my post on Usability Testing here:

The well-kept secret behind great UX: Usability Testing
_Whether you only have a prototype or a full-fledged product, it’s a really good idea to run monthly usability tests…_medium.freecodecamp.org

Thanks for reading this quick guide. This was originally published as part of the UX Design course on Commonlounge, a platform that has courses with small bite-sized lessons like these on topics ranging from Django to Machine Learning that deliver the most value for the time you put in.

You learn by working on real-world projects and getting feedback from industry mentors. You should check it out here!

I’ve been involved in a number of projects that required the development of prototypes in a short period of time. These prototypes helped evaluate the viability of ideas and the user experience of a specific solution. Sometimes they served as proof that the concept could be developed given the constraints.

What is Software Prototyping?

Prototyping is the process of creating incomplete versions of a proposed solution. That sounds bad — it’s incomplete! But the aim of prototyping is to simulate only a few key aspects of the solution. This helps us evaluate the viability of potential solutions in terms of cost, complexity, usability, and value.

Projects are often taken on before team members fully understand the effort required to achieve their goals. Sometimes they don’t understand if the solution is what’s required. Prototyping can assist in the analysis of these requirements, and can help the team learn more about the solution domain or problem domain, depending on the approach.

Prototyping and Design Thinking

Design thinking, as a mindset, is the methodology for crafting solutions to complex problems using creative techniques. You have to account for both the known landscape, and the potential possibilities within that landscape.

Prototyping is a big part of design thinking. Visually representing, understanding, evaluating, and learning from ideas is at the core of design thinking. Design thinkers concern themselves with the solution space, not just the problem space. In design thinking, it is common to uncover or create new problems to solve when evaluating prototypes — and this is a good thing.

Why Prototype?

Early user acceptance testing

People get a chance to use and experience the solution early in development. This will result in early feedback from the user base, and allows you to implement changes earlier rather than later. The cost of a change in a project increases significantly in later phases of development.

Realize requirements and constraints that were not previously considered

By simulating some of the functionality of a product, the team may discover side effects, constraints, or additional requirements that were not considered before. This assists in achieving a more complete and robust solution.

Better cost, time, and complexity estimates

By realizing additional requirements and constraints early, as well as receiving user feedback early, you can make better complexity and time estimates. This results in better cost and time estimates. These estimates impact a range of activities when rolling out a solution to production.

Slaying the dragon

In software development, we speak about slaying the dragon: A single team of heroes attempts to slay a large project (or “dragon”). With software prototyping, we try to make slaying the dragon more like shooting fish in a barrel — we tackle smaller or more complex features first.

A Process for Prototyping

Step 1: Understand the landscape

You must understand the existing technology and business landscape, as well as the future vision and strategy. This is a crucial foundation for developing any solution.

Step 2: Identify the core requirements

These are the requirements for the solution. These are usually derived from the ideas at hand, or from the problems you’re attempting to solve. Requirements usually evolve as you learn more.

Step 3: Research

Determine if something already exists that fits the requirements. Look at competitors or similar solutions. Uncover the details not mentioned in the core requirements. These uncovered details could be a blocker for the solution, or could potentially open the door for better, more valuable features.

Step 4: Develop an initial prototype

Prototype the features that are important and have high impact. This depends on the goal of the prototype. If complicated features with unknown possibilities exist, then tackle these first. If there are many simple features, try to simulate an experience across all these features without delving into the complexity in each.

Step 5: Evaluate and review the prototype

You should review the developed prototype with the target user group and relevant stakeholders. Some prototypes could even be released to production for evaluation.

The performance of the features and usability should be evaluated and measured both quantitatively and qualitatively. This means that you gain some knowledge from measurable numbers, and other info from human intuition and observation.

Step 6: Revise and Enhance the Prototype

After reviewing the feedback from the prototype, you gather information. Then you can make enhancements and changes.

Step 7: Repeat

If unknowns still exist, repeat the above process. In fact, even with solutions in production, this process can be harnessed to test new ideas for the solution.

Dimensions of Prototyping

Horizontal Prototyping

The aim is to provide a broad view of the entire solution. There will be little complexity in individual features. This approach is good for websites and instances where you need to achieve a general feel for the product.

Typically, these are solutions that are targeted to the public, or solutions that require intensive usability testing.

Vertical Prototyping

The prototype will focus on a small set of features, sometimes even just one or two. The chosen features are explored and researched completely. This approach is good for solutions where you use obscure or complex algorithms, or when you attempt something unusual or unorthodox.

This is useful for experimenting with new tech, new approaches, and typically when you desire “disruption.”

Types of Prototyping

Throwaway Prototyping

This is also known as close-ended prototyping. Rapid Prototyping involves creating a working model of parts of the system, at an early stage of development, after a relatively short investigation.

This kind of prototyping shows people what the feature will look like. But the code base or project is not necessarily used for the production version of the application.

Evolutionary Prototyping

The main goal here is to build a very robust prototype in a structured manner and constantly refine it. The prototype forms the heart of the production application, and additional features are added to it.

Incremental Prototyping

In incremental prototyping, parts of the system are developed as separate prototypes and plugged together to form a complete application. It is important to develop the interfaces for the separate components early, as integration may turn out to be a nightmare.

Extreme Prototyping

Extreme Prototyping is employed mainly for web applications and usually in three phases:

1. Static HTML/CSS/JS is created — this gives users an instant tangible feel for the product.
2. Thereafter, the service layer is simulated — this includes business rules and logic.
3. Lastly, the actual service layer is developed — this involves integrating with real-world systems and plugging that into the front end HTML/CSS/JS views.

This gives users an early view of the application without having actual functionality behind it. The backend will gradually come together as the process moves along.

Disadvantages of Prototyping

Insufficient analysis

The confidence in a prototype could cause the team to abandon further analysis of features. This could result in part of the system being well-defined, while the remaining parts are vague and incomplete. This can be controlled through correct processes in requirements analysis.

User confusion between the prototype and the finished system

If the final system is completely different than the prototype, users may be confused about how it operates.

Expenses of prototyping

Although prototyping saves cost in the actual development phase for a solution, there will be costs involved in implementing a prototyping phase.

The risk of spending money on a prototype that could potentially be thrown away must be understood. What you learn from developing that prototype is still valuable!

Advantages of Prototyping

Reduced time and costs

By exploring the requirements and constraints, you can better estimate the upcoming effort.

Improved and increased user involvement

User involvement is important. Prototypes clear up misconceptions and expectations, and they assist in gathering user feedback from early stages of development.

Quality assurance

Realize oversights, additional requirements, and constraints.

Innovation

Without being brave enough to explore the crazy ideas, an organization can easily stagnate.

There’s a range of topics related to prototyping. To learn more, researching these terms will help: design thinking, user experience design, agile.

Thanks for reading! If you enjoyed this post, please give me some claps so more people see it.

Pause. Rewind. Deep dive in the design process.

Two weeks ago I posted about the possibility of an iPhone that has no Home button at all.

With iOS 11 on an iPad you enjoy a whole new app switcher. As a little design challenge, I study how this UI could work on the imminent ‘iPhone 8’, and whether it could cater for the absence of Home button.

Today I’ve paused the exploration, and I’m walking you through the design process. We’ll review my sketches in detail, see what they reveal about the train of thought (ouch!), and look at a couple of prototype variants that you’ll be able to download and try.

Being process-oriented, not product-driven, is the most important and difficult skill for a designer to develop.

Matthew Frederick

Sketches and prototypes below are provided as is, they haven’t been modified at all for the sake of this article. I include raw scans of my large sketch boards, so the post is probably best viewed on desktop or tablet.

Sketching

I always keep my sketches and notes. They’re useful to review in slow motion what has happened in the mind, assess the reasoning, and have a fresh look at germinating ideas that were forgotten on the road side.

For this project I used two A3 sheets. Let’s comment the key screens:

1. Trying to force-fit the iPad design. In that first attempt, everything is on a single horizontal scroll view. And there’s a Home button! False start.

2. Trying again. But stopping fast since clearly, it’s not going to work. My proportions are completely unrealistic. Lack of discipline.

3. A more realistic ratio. I finally acknowledge it’s a very long phone I’m dealing with (6/13 ratio). I’m going to need my imagination. The whole view now scrolls vertically, with apps on 2 columns. An accident happens here: my focus has now shifted to the iPhone’s Control Centre (that I’m probably examining on my iOS 11 phone, as a model for the sketch). I’m misled and add the little chevron at the top, meaning “swipe down to close”.

Sheet 1 of 2

4. A potential conflict. Because I now wrongly assume the UI can be swiped down, I worry this is going to interfere with my vertical scroll. I capture this in a side note: “KO since swipe needed to close overlay”. I swap things, move apps to the top, as if it could help, but finally plant the seed of an alternative idea: “Recent apps @ top but as horiz. carousel”.

5. One last shot at the vertical scroll. Here, I guess I’m seeking confirmation that the vertical approach is flawed... But my mind forks again as I notice a new issue! Controls and recent apps compete for visibility: Scroll to view one and the other is pushed out of bounds. They’re part of the same strap. At that point I decide to try decoupling them.

Sheet 2 of 2

6. Recent apps as horizontal carousel. That looks more familiar for an app switcher. Controls still scroll vertically, though — so how does that work as a whole? Doesn’t feel right. I appear distracted again between 6 and 7 but let’s skip that.

7. Two parallel scroll views. The control group and the app carousel are now free to move without running into each other. Space is shared equally. I annotate some elements with “Size?”: Can I afford that layout on the real device? Only one way to know: Increase fidelity. But overall I sense I’ve got a candidate solution I can work with.

Observations

I don’t state my goal. That’s a pity because something as simple as “Adapt the new iPad switcher to the iPhone 8” (even if obvious) would have focused me sooner on the actual issues.

I don’t have a very clear logic in mind. Evidence of confusion: The fallacy that the UI is an overlay that can be swiped down, and the Home button that I remove then for some reason bring back (don’t ask!).

I seem mainly concerned by a layout problem. Apparently I don’t worry much about how to access the home screen. Yet that’s very key in my experiment! I do leave a shy trace at step 3: “Lacks obvious way to go to HS”, and then stick a Home button everywhere. This is embarrassing (given the experiment is all about button-less!) — I’m probably aware that at some point I need to find empty space so the background can be tapped, like on the iPad switcher, but I wouldn’t swear. The Home button looks more like a mechanically applied FIX-ME label, something I don’t want to deal with yet.

Being process-oriented means: [Long list that includes:] Working fluidly between concept-scale and detail-scale to see how each informs the other.

Matthew Frederick

My drawing and handwriting look awful. But somehow that’s positive. In the process of doing these sketches it never occurred to me that I would share them later; in the moment, the absence of aesthetic requirements actually did reinforce focus.

Side notes help inform my next steps. Sketch, evaluate, note issues, and try addressing them in a future iteration. Any change can bring new problems, and the sooner I capture them, the better. It’s just so easy to spot and forget. I’ll take side notes more systematically in the future.

Prototyping

You can try the prototypes below if you use Principle, on a Mac or an iPhone directly. Click the movie captions to download the Principle .prd files. To learn more check Principle’s docs, and my tips at the end of the post.

_[Download v8](https://www.dropbox.com/s/i8lsat5mq5w9x8i/homeless%20v8.prd?dl=1" rel="noopener" target="blank" title=")

An early version (v8 above) features the chevron at the top and a discreet Home button at the bottom. Tapping the chevron re-opens the current app (what else could it do?) but so does a tap on the app miniature already.

So this chevron based interaction looks silly, in hindsight. Pay attention to the animation it triggers: While it does the right thing (zooming in the app correctly represents the action of bringing it to the foreground), it is disconnected from the chevron object itself. The chevron, on one hand, is doing what you want (dismiss switcher and return to app) but on the other hand it does not behave as you’d expect (slide down). Prototyping instantly trapped the contradiction here. I should have caught the flaw much earlier, but that’s ok — there are many things in my life that I should’ve done earlier.

_[Download v11](https://www.dropbox.com/s/6dsveqoqusqam8g/homeless%20v11.prd?dl=1" rel="noopener" target="blank" title=")

The chevron is gone (v11 above) but I now experiment with a home screen miniature (like in iOS 10's switcher). This is efficient for the home screen use case, but it pushes the previous app (green) too far left for a right-hander. And there’s duplication again: the Home button becomes redundant, but if I remove it then the user can only rely on the miniature to go to home screen, which is too far right for left-handers! They could scroll but in this particular case I certainly don’t want them to have to.

There’s another aspect: this model is inconsistent with my target one, whereby only a tap on the background should take you home. This is key for the coherence of the whole, and central to the beauty of the new iOS 11 switcher. Why? Because the blurred background behind the switcher is the home screen. Any specific affordance to access the home screen (such as a Home button or my miniature) is superfluous (not to say incoherent) when you can interact with the home screen directly. Depth is one of the core design principles in iOS — with Clarity and Deference — and Apple beautifully builds on it here.

Main mental model layers in iOS 11

_[Download v14](https://www.dropbox.com/s/9p5zon3u8kfkjru/homeless%20v14.prd?dl=1" rel="noopener" target="blank" title=")

In the final v14 iteration above I clean up and more strictly align with the iPad switcher. That’s the version I present in part 1. A further improvement could be to enlarge the empty area at the bottom, for instance by limiting the Control Centre grid to 3 rows.

One last quote from Matthew Frederick’s excellent 101 Things I Learned in Architecture School:

Properly gaining control of the design process tends to feel like one is losing control of the design process […] Accept uncertainty. Recognize as normal the feeling of lostness that attends to much of the process.

On my journey I drifted away from my initial goal several times and accidentally glimpsed at different possibilities. Some may be worth revisiting later, some opened my eyes to new pitfalls. The wandering isn’t waste, it is the essence of exploration. At the same time one can’t keep opening boxes and adding todos forever; it’s also important to deliver reasonably stable and presentable solutions as you go along. The challenge is to strike a balance between breadth and depth.

Tips – if you try the prototypes

• Interactions are limited to: swipe up, scroll horizontally, tap the blue app miniature, tap the switcher’s background. In the home screen, tap the blue icon only.
• The intermediate Dock state that I describe in the previous post is not supported by the prototypes I share here. In order to create the Dock state movie I made a temporary modification.
• The prototypes are designed for the ‘iPhone 8’ itself, at 375 * 812 points (145 pt taller than an iPhone 6/7). So if your test device, like mine, is a 6/7 series, Principle scales down the UI a bit so that it fits your display: Everything looks a bit smaller than it should be. And positioned a bit higher too, due to the bottom area on the 6/7 (no such chin on the future edge to edge display).
• However, if you open this image on a 6/7 you get a much better idea of the expected ‘iPhone 8’ feel. Just imagine the phone is taller and that you can tap the bottom area anywhere. You may need to first save the image to your photo library. It’s supposed to fill the entire screen and look like this:

Some time ago I shared in a Medium article the idea for context aware messenger app. The idea challenged the design limitation behind all messenger apps allowing you to write only one message at a time.

What I always missed in these apps was a way to save the message I’m currently typing and type and send something else instead. Then a way to get back to previously composed message and continue. Just to stay on topic and keep some order in my conversations.

Left to right: Messages, Slack, Hangouts, Messenger, Whatsapp.

The way I do it today involves the sequence of text field related gestures: Long press, Select All, Cut, Type in, Send, Long press, Paste, continue.

My concept allowed to replace that sequence with a single tap, but it was up to the app to recognise the need for saving a message based on the context of the conversation. I built a Quartz Composer prototype to show the feature in action:

But I never shared the prototype, as it wasn’t functional, allowed for only one extra input field and was done solely for the purpose of recording that video. Also Origami prototypes for Quartz Composer didn’t work very well on the device (not mentioning the absence of native keyboard).

Release of Origami Studio allowed me to revisit the concept and build fully functional (sort of) prototype to share.

I ditched the context aware part and allowed for saving as many drafts as you need, whenever you feel like it.

Here’s a demo video of the new prototype.

Building in Origami Studio.

I could write a separate article/tutorial for each of the technical challenges I encountered while building the proto, but I’ll limit myself to just briefly list some of them here. Hopefully these short descriptions will be enough to spark some ideas whenever you encounter similar blocks. If not don’t hesitate to ping me directly.

Multi line input field.

Text Field component in Origami Studio doesn’t allow for multi line inputs. When you double tap on it to reveal it’s content’s you’ll find the actual Text Input component that does. The problem is it doesn’t have a cursor/caret. So hacked in a cursor by measuring the position of the last letter in the text field.

Each time you type a letter I check if it’s a ‘space’ and if it is I append it’s index to an Array of spaces. Then I assume that whenever height of the input increases the text will break at the last recorded space. Then I measure the rest of the text to place a cursor in a correct position of the new line. When you don’t tap the space I just measure the size of the text that fit the line.

Building a conversation feed.

The challenge here was dynamically creating chat bubbles while keeping the correct order in the feed. When bot starts typing you can see the last bubble on the feed with 3 jumping dots. But if you send the message before it finishes typing your bubble should land on the feed before the bot’s bubble. I managed to make it work by keeping two arrays of messages. Temporary one (bot typing) and final and switching between them whenever bot starts typing or sends the message.

I created a JSON config file with the bot messages that allow you to configure what and when the bot is sending and if it should wait for your message(s) to start typing.

{"message":"Ok, I'm dumb. What do you want from me?!", "waitforuser":2,"delay":1}

waitforuser — describes how many user messages should the bot wait for before it starts typing. Zero means it won’t wait for user at all.
delay — time in seconds before bot starts typing.

Creating/removing input fields and managing their order.

Whenever you create input field I’m increasing the count on the Loop patch, but as soon as you don’t need the field anymore I tried to remove the field from the loop and keep the other input fields keep their order and content. It was impossible for me to figure out as loop patches don’t keep the reference to the actual instance of the element they’re replicating. I worked around by hiding and reusing unused fields instead of removing them from the loop.

Downloads!

You can download Origami prototype, JSON file as well as multiline text field component from my Google Drive.

User’s Manual:

Long press on Send button to save the current text and create new input field. (Yes! It’s undiscoverable. I know.)
Prototype is optimised for use on the device. (You can’t hide the keyboard)

Last minute discovered fun facts:

• The prototype crashes when using emojis. ?
• Multi line input field cursor can behave erratically when typing super fast (I’m sharing anyway).
• When you send a message in the exact time that bot starts typing, the empty bot message can appear on the feed.
• Other bug fixes and performance improvements. (What?!)

“The meeting of two personalities is like the contact of two chemical substances: if there is any reaction, both are transformed.” — Carl Jung

Doing something you’ve never done before is inherently exciting.

When I wrote to Framer a couple of months ago asking why there weren’t any Framer events scheduled in Boston, they responded with, “Well, why don’t you host one?”

Truth be told, I’m generally not one to organize events. I think I’m a little too micro-manage-y of a person to both enjoy it and keep it running smoothly. It’s like asking Woody Allen to host a comedy show while catering it at the same time. But this time, for some reason, I said yes.

When someone asks you to host a meetup, jump in!

And if Framer hadn’t connected me with two extremely outgoing, organized, and awesome partners-in-crime, Emily Carlin and Gideon Goldin, it would not have gone nearly as smoothly.

So, as Nacho Libre says, “Let’s get down to the neety-greety.”

As I quickly learned, there are the five ingredients to a successful meetup:

• Location
• Food
• Booze
• Guest speakers
• Some semblance of an agenda

We locked down the location, food, and booze relatively quickly. Finding a great speaker was much more of a challenge.

After some time, we connected with Andrew Nalband of Cut and Fold, a veteran designer and avid Framer user. He used Framer to develop killer interactions like this:

_You can try the interactive version here: [http://share.framerjs.com/zydimzquxu7b/](http://share.framerjs.com/zydimzquxu7b/" rel="noopener" target="blank" title=")

And after a quick survey of other events, we had an agenda, which I promptly inserted into a flashy little invite.

So, our with our ingredients prepped and ready, it was time for liftoff!

The Event

People began filing in around 6:30, and with our abundance of food and drink, there was a comfortable atmosphere in which to socialize.

We had pre-surveyed participants, so we had some idea of everyone’s skill level going in. Most people had never used a code-based interaction tool like Framer, so we decided to start from ground-level.

The presentation consisted mostly of an introduction and a show-and-tell from Andrew. He went through the basics of the tool, as well as some inspiring examples of it in practice.

What I loved about Andrew’s talk was how comfortably he switched into “educator” mode. He went right down to basics and walked everyone through the interface, what a layer is, and how animation works. We had no idea about what he was going to talk about beforehand, but he totally crushed it!

People were so engrossed that Andrew was able to speak for a full hour.

I also went up to share some prototypes, but there are no photos of that since I was charged with the photography ?

We live-streamed the event in its entirety on Facebook. You can watch it here.

Reflection Time

The biggest lesson learned was that, as others have found, it might be good to split people up at the beginning to maximize the effectiveness of the event.

While the event was a big success, I did get some feedback that some people came expecting more of a walkthrough, while others were there to better understand how framer fits into the design workflow.

For the next event, we will definitely strive to meet these needs, and to be even more awesomer!

I’d like to thank our amazing sponsors of this event: Framer, Tamr, and Society of Grown-ups. It wouldn’t have been nearly as great without your support!

Also, thank you for reading! If you have any thoughts, I would love your feedback in the comments.

Also, be sure to check out my last article about prototyping with FramerJS.

If you liked this, click the? below so other people will see this here on Medium.

“Data! Data! Data! I can’t make bricks without clay!”
— Sir Arthur Conan Doyle

Most interaction prototypes today serve one purpose: to convince your user that this prototype is what the “real thing” will look like and feel like.

In the past, designers have achieved this with fancy user interfaces, animations, and fluid transitions.

But those don’t quite cut it anymore. Users have become jaded to these tricks. They lived through the iPhone era, and now expect a fluid UI to come standard.

So what’s the next frontier then? How can we convince people that a prototype is “real”?

By using real data.

Time to go down the rabbit-hole…

FramerJS is a powerful code-based framework for building prototypes for your web apps and mobile apps. In this article, I’ll show you how you can use it to build a realistic prototype that features real data.

Framer’s Interface, Framerjs.com

As a rider of the Massachusetts Bay Transportation Authority (MBTA), I have the distinct pleasure of riding a transit system that is over 100 years old.

As you can imagine, the trains aren’t always on time.

I’ve become relatively familiar with Framer, and as such, I decided to try and design an app to solve this problem.

As a designer who has only a whisper of an understanding of code, this was daunting to say the least.

I called up my brother, a talented computer science major at Tufts, and we got down to business.

[come hither]

Locating our users

The first thing to do was find the user’s location in realtime.

Today’s mobile browsers have this feature built-in.

With two functions, you can get the latitude and longitude of your user.

Then, you can just stick those coordinates into what’s called a hash table of key value pairs. In this table of data, the key might be “dog_breed” and the value might be “Pomeranian.” So now, you can call on that key whenever you need it, and it will return its corresponding value.

Here’s what we ended up with:

#get locationgetLocation = () -> print “INSIDE GET LOC” navigator.geolocation.getCurrentPosition(showPosition);

showPosition = (position) -> print “INSIDE SHOW POS” gpsCoords = { “client_lat”: “#{position.coords.latitude}”, “client_lon”: “#{position.coords.longitude}” }

Now that we have the user’s exact location, it’s time for phase II.

Locating our trains

Where’s that train….Mr. Andersonnnnn?

Getting the user’s location was the easy part. Now, we need to find and parse the API data from the MBTA.

Unfortunately, this organization is about as organized as any other under-funded government operation.

So, their code was — how should I put this — a little janky. Here’s what it looks like:

Kiiind of a jumbled mess.

The data was nested in a combination of arrays and key value pairs. Some of them were data tables with just one entry. It took some time to understand how to pull out the data we needed.

Regardless, once we understood the structure, the idea was to grab the location data from the user’s browser and insert that into the API call to the MBTA. Then the MBTA API would return all data closest to that location.

The first piece of data we wanted was the closest station to the current location:

#grab MBTA station datadata = JSON.parse Utils.domLoadDataSync “http://realtime.mbta.com/developer/api/v2/stopsbylocation?api_key=De_WCTE-gkyYSitBw82YSw&lat=#{gpsCoords["client_lat"]}&lon=#{gpsCoords["client_lon"]}&format=json"  stops = data[“stop”]  stationText.html = null  for i in stops  if i[“parent_station_name”] != “” stationText.html = “The closest station to you is “ + i[“parent_station_name”] + “.”

Once we had the data, we then parsed it into something humans can read. We created a string (an English sentence) that said “The closest station to you is” and then tacked the station name on at the end. And Voila! The first step!

It worked like a charm!

Except not in Google Chrome.

We quickly learned that for some strange reason, Google had decided to disable location APIs. Really Google? You don’t have enough billions to give some location data to the little guy?

But anyway, the prototype works great in Safari.

After celebrating our initial success, we decided to make our lives hard again.

What if we wanted to know not only the nearest station, but also how far the closest train was, where it was coming from, and how many minutes away it was?

Oh boy.

That “uh-oh” moment.

More Crazy Data

Now that we had a handle on how the MBTA data jives, we dove into a second API that provides (mostly) accurate train data.

After some finagling, we had something like this:

#grab nearest train data data2 = JSON.parse Utils.domLoadDataSync “http://realtime.mbta.com/developer/api/v2/predictionsbystop?api_key=De_WCTE-gkyYSitBw82YSw&stop=#{i["stop_id"]}&format=json" routes = data2[“”] timeAway = data2[“mode”][0][“route”][0][“direction”][0][“trip”][0][“pre_away”] trainDir = data2[“mode”][0][“route”][0][“direction”][0][“direction_name”] trainLine = data2[“mode”][0][“route”][0][“route_name”] timeAwayRound = Utils.round timeAway/60, 0 stationText2.html = “The next “ + trainDir + “ “ + trainLine + “ train is “ + timeAwayRound + “ mins away.”

This grabs the “stop_id” (the nearest subway stop) from the first API, and plugs it into the request for the second API.

Then, we just have to wade through the data to extract what we need.

“timeAway” gives us how far the nearest train is away, in seconds.

“trainDir” gives us the direction the train is headed.

And “trainLine” tells us which service line the train is on.

Then we created a quick formula to turn seconds into minutes, and dumped all of that data into a string that made sense.

And voila! A little bit of quick UI, some fancy animation, and we had it!

_You can try out the prototype for yourself here: [http://share.framerjs.com/7ygqcpa64f67/](http://share.framerjs.com/7ygqcpa64f67/" rel="noopener" target="blank" title=")

“Like…Whoa…”

Takeaways

I learned so much in building this. Working with real data is so liberating once you figure it out.

I cannot over-emphasize: if you haven’t gotten practice with reading API documentation yet, it can be quite frustrating. Be patient. It may take several hours to figure these out and get them working.

The syntax has to be perfect. And I mean perfect.

But if you do get it, you’ll be standing there, playing with it and watching the numbers change with a smile on your face.

And you’ll feel like, all of a sudden…you know kung fu.

Thanks for reading. Give the prototype a try. I would love your feedback!

Also, be sure to check out my first article about prototyping with FramerJS.

If you liked this, click the? below so other people will see this here on Medium.