The main goal of prototyping is to get feedback from users faster. If you can approximate a product and still get positive feedback, you know you’re on the right path. Secondly, the act of prototyping forces you to describe the product in transitions, rather than in states. States are static snapshots of a product, representing a single point in time — transitions are everything in between.
The natural transition for a designer looking to prototype is to animate images. When I began prototyping, I made videos with After Effects and Photoshop. As I began doing increasingly complex animations, I started to realize the limitations of prototyping with videos. Videos play linearly, and are not interactive — whereas code is.
Why write code?
As a designer, consistency is part of my job. I became fascinated with design systems over the past few years, and as I did I spent a lot of time researching different ways to codify design decisions.
The funny thing about codifying design decisions is: you’re programming. Coming up with a list of font sizes or colors? You’re describing an array of variables (or constants, if you’d rather). Are there toggle-able elements shared across multiple components? Sounds like a prop.
Understanding how different programming languages construct interfaces informs the way you speak about your designs. If you can communicate better with an engineer, you’ll see better results.
Every language is different, and what you learn here will not translate to Swift or Java. However, understanding these technologies should make it easier to understand others.
Why these technologies?
I use web technologies for prototyping because they’re flexible. The web lives on your computer and on your phone — URLs just work. I can send a link to someone and all they have to do is open it.
Before continuing, you should take time to read about these frameworks and try them out in online code editors like CodePen or CodeSandbox. You may prefer React, and wish to use Gatsby instead of Nuxt. That’s perfectly fine — but this article won’t work for you.
I cover installing the basics in a previous post, and once you’re vaguely familiar with Terminal, Homebrew & Node, you should continue. Installing the packages above is odd if you’re used to an application window popping up, because there is no interface, it’s just ~there~, in the background.
Surge isn’t covered in my previous post, but it’s dead simple to install:
npm install --global surge
If you encounter an error here, add
OK, so how do I prototype?
Now that everything is installed, we’re ready to go — and you won’t have to do that again for a while.
Creating a Project
When you want to start a new prototype, you will need to create a new project using terminal. First, navigate Terminal to a location you’re comfortable installing the project in, like your desktop. Open a new Terminal window and enter:
Then enter this:
npx create-nuxt-app <prototype-name>
<prototype-name> above with whatever you like. You’ll be asked a few questions:
- Project Name: hitting enter will use the name of the project you just entered
- Project Description: add one if you wish, but it’s not required
- Use a custom server framework: select none by hitting enter
- Use a custom UI framework: select none by hitting enter
- Choose rendering mode: use the down arrow to select Single page Application, then hit enter.
- Use axios module: select no by hitting enter
- Use eslint: select no by hitting enter
- Use prettier: select no by hitting enter
- Author Name: hit enter to use the default, or enter something different if you wish before hitting enter.
- Choose package manager: you can use either here. I’ve been using NPM, so I recommend selecting NPM by hitting enter.
Ten questions may seem like a lot, but it’s mostly hitting enter without thinking — You’ll get used to it, I promise.
Once you’ve answered these questions, your project will start initializing. You’ll see a new folder appear where you specified with Terminal.
Seeing your Work
Terminal will list a couple of commands after the project is initialized. For them to work, make sure to navigate Terminal to your new project folder:
A local server will allow you to see your project as you work. To launch the project locally, enter:
npm run dev
When terminal finishes, head to http://localhost:3000 using your browser to see your prototype running! This URL will only work on your computer — in order to share the prototype, we’ll need to publish it.
Publishing a Project
To get it in front of a user on their own device, we need a URL — this is what Surge is for, and it’s super simple.
Small sidebar: Surge is a tool for hosting static websites. We don’t really need to get any further into it, but it’s important to note that Nuxt can generate static websites, and that’s one of the reasons we’re using Nuxt with Surge.
In order to generate a static website from your Nuxt project, use terminal to navigate to the project folder, then enter:
npm run generate
This will create a new folder inside the project called
dist . It contains your static website. We’ll navigate to
dist using terminal now:
Then, we enter:
Kind of anticlimactic, right? You can customize the body of your URL, or just use whatever random string they give you.
That’s it! Try visiting that domain and you should see your website. If you see a Surge error, make sure you remembered to navigate to the
dist folder before running surge. Send the URL to other people, ask them what they see, if it works, and what they think. Then give yourself a pat on the back — you just launched your first prototype using Nuxt & Surge!