Strategies for skipping UX prototyping tools
When your development moves fast, it’s hard to squirrel away blocks of time for systematically learning new tools. For this reason, I build interactive prototypes straight in my front end framework (Ember) instead of UX prototype programs like Balsamiq or Adobe UXD. Even though a prototyper’s output might meet MVP and be easier/faster to build, I’m making an investment in my future production-grade skills and knowledge.
However, there are some obvious and not-so-obvious pitfalls for rapid prototyping directly within a front end framework, so here are step by step guidelines for avoiding pain and maximizing what you learn as a developer during the build.
1. Write user stories
No matter what tools or strategies you use, nothing is worse than building something that solves the wrong problem. Put into words what your prototype should do.
2. Sketch coarse wireframes and validate them
I like to draw these on a whiteboard because it is impossible to be too detailed with a standard dry erase marker, especially when the tip is frayed and starting to run out of ink. I’m serious. Dying markers are the best. Your wireframes should be directed by the user stories and include every page/view your user will see. When you are done, read through your user stories and make sure you’ve hit all the points.
Ideally, you should be gathering feedback at every step of design/development, but I believe this is the most critical point at which you should get feedback, in order to make sure what you are building actually makes sense for the user’s workflow.
3. Choose your addons
Your goal is to choose addons that do at least one of these things:
- You want to test drive it for possible use in production,
- It will help speed up your prototyping (like grid systems or bootstrap-like elements)
- It’s prettier than what you have time/ability to do by hand
For example, if I needed to make an informed decision about how to handle animation for our production apps, I might try a different animation library for each prototype I build.
Whatever addons you choose, remember to take notes about the pros and cons you see as you’re working with them. You are spending time on important research, and you won’t remember much three months later. Introducing new dependencies is serious business.
4. Create at least one high-fidelity mockup
This is the time to choose things like color scheme, alignment, and placement. I like to use Adobe Illustrator for this, but any number of tools would work here. Because I have to move fast, I usually only do a mockup of the “main” functionality or view within the demo. This step is what helps me stay motivated and on track later on, when I’m writing css classes. If I chose any addons that have to do with visual appearance, like pre-styled charts or bootstrap-type elements, I just use a screenshot from the addon’s demo instead of making something in Illustrator.
5. Sketch a new wireframe showing div containers
This time, grab a pen and paper, or a nice, crisp, new marker for the whiteboard. Look at your high fidelity mockup and the placement of its elements. How will you sensibly divide it into divs? Draw them. But, unlike how you might design HTML for production, avoid nesting divs deeper than one or two levels. You want to build something where each piece can be moved around, restyled, and resized freely. Do this for every “page” or “view” that your user will see.
6. Map user actions onto the wireframe
Draw arrows connecting the wireframes, and write your action names along them. If your user will be navigating between routes, write the name of that route above the wireframe. This thing should appear ugly and complicated, but really it’s just a detailed roadmap that helps make the following steps elegant and straightforward.
7. Start listing out your components
I break up my app into components based on two things: actions and visual layout. Your wireframe is your guide for both. If you followed my advice and avoided nesting your divs more than one level, at least some of the divisions between components should be clear. I like to make a written list that outlines the names of the components that I’ll use and shows where they are nested. I try to only nest components one level deep so that I can move them around easily.
8. Pause to consider your future self
Now is the time to think about how your work today will help you build another prototype or iterate on this one in the future. With each prototype I build, I’m also adding to my own prototyping toolbox.
There are two types of components that I find myself making: reuseable and one-time only. You might have heard that it’s important for your components to be highly reusable, but within a prototype, this can make your code unnecessarily complicated. You don’t want to have to pass in six attributes in order to use them. Remember, you want to make things that you can move around freely and edit easily later. So, a front end prototype should have a healthy representation from both categories, but you should be intentional about which components are which type.
For example, I have a few components that are simply buttons, menus, or input boxes that are already styled according to our branding. I reuse them all the time. In contrast, if there’s a part of my app that needs a very specific layout or look, I might just throw all those pieces together in one component that I’ll never use again, rather than trying to make my buttons and inputs one-size-fits-all.
9. Stub or mock the data
I work in Ember. So if I have anything in my app that resembles a list, I put that content into records within its Data Store. This lets me make use of template helpers like #each so that my HTML is simple. It also makes my app look like the real thing with record creation and deletion, without the overhead of needing to build an API and database.
10. Build how it looks
The fun part! But also, you must remember that you will throw a lot of this away. Do not become attached to your code.
I keep both the mockup and my final wireframes close by as I’m building, and use them as my guide. I try to do one type of thing at a time so that I don’t wander off into the weeds of perfectly positioning something before I even have the skeleton done. First, I generate all my routes and components for the entire application. Then, I work work on html for only the mockup page, and maybe add some simple interaction behavior, like clicking a button to show or hide some content, or handling a form submission. And when that’s done, I move on to CSS for the mockup.
Just like I advised avoiding nesting divs and components too deeply, so that I can move things around easily, I also avoid nesting css. No fancy child selectors allowed. When my work starts looking a lot like the high fidelity mockup, then I can move on to other routes and components. If you’ve done the “main” view to completion, you’ll have all the classes and most of the components that you need to build the other parts of your prototype.
11. Connect component and routes
If I’m confident that either the prototype will be thrown away or it will change significantly in the future, I let my components handle as much behavior as possible, and even sometimes put them in charge of creating the fake data that will be used in the html. Now, this is not very DRY. Not at all. Also, I work in Ember, which has a “Data down, actions up” mantra which I blatantly break when I’m prototyping. I’m consciously trading maintainability for speed, as opposed to being sloppy or lazy.
My final step is adding the route transitions and anything that creates shared state between different parts of the app. I wait until the end because these things are the hardest to refactor if I decide to relocate some nested component or split up its functionality.
Is there a better way?
Absolutely. If I was expecting lulls in work where I could explore new tools, or I was iterating directly with users, I would probably use a prototyping program instead of building straight in Ember. I tried a couple demos and I really liked them.
But, many of the prototypes I build go from concept to working code in one to two weeks, and I’m the only one working on them. In this situation, it’s ok if my code isn’t DRY or particularly maintainable. If I suspect at all that I will need to convert my prototype into something “real” or someone else will be actively helping me build it, I approach many of these steps very differently.
Right now, my hybrid role of design + development makes me a unicorn, but our ranks are growing, along with the tools that make this kind of approach possible.
Are you a designer + developer? I’d love to hear how you do prototyping.
