over 6 years ago from Taylor Palmer, I do the UX
I'm looking for examples of design teams that use coded prototypes to use as examples in my upcoming talk. How do designers contribute? How frequently are the prototypes updated?
For designs where I am focused on the content first, I have developed a couple of tools.
One is for creating websites from a Trello board. Each list becomes a page, and each card becomes a chunk of content. Here, for example, is a live preview of my portfolio website — https://lokum.icing.space/#mQ6WXDAQ/ — the content comes from this Trello board, and the CSS is developed in this CodePen.
The next, currently in alpha, is for rapidly prototyping screens with text, forms, navigation, etc. You type some hashtagged text on the left, and a preview is updated on the right with Bootstrap, Foundation, or wireframes. You can play around with it here.
All of this is open source on GitHub. I use React + Node.js.
Wow, this is really fascinating! What made you decide to use a Trello board?
There’s a few reasons! One, I can update my site from my phone. I just use the Trello app, and hit a special URL to reload.
Two, I have complete control over how the content is presented. I have found there’s a huge canyon between Markdown and WYSIWYG. Trello is a user friendly tool for arranging pieces of content, it’s got the right amount of flexibility and everyone’s familiar with it.
Amazing - why build a CMS when there's plenty out there? Very creative.
Most CMSs I know you have to define some sort of schema with fields for your content to fit into. Trello with lists and cards is really flexible, pair that with hashtags and it’s loose enough to support a lot of different content arrangements. Uploading images is as simple as attaching it to a card.
Plus everything is visible: you can see your whole sitemap in one screen. I can also have lists that aren’t pages for notes and drafts.
And Trello already has an iOS app, so I don’t have to worry about fighting a mobile admin site.
Unfortunately I cannot share our team's work, but a few of us on our design team create coded prototypes. I use Vue.js heavily and it's made the process extremely quick and easy, and very simple to maintain.
Thanks Andy, I just recently started converting my Angular 1 work to VueJS and I'm loving it. It feels like what Angular always should have been, and it doesn't have the baggage of setup and compiling that Angular 2 has.
While I have you, what benefits have you seen to using coded prototypes over something like InVision?
Isn't it the best? I also come from an Angular 1 background, so it was a wicked smooth transition.
Sounds awesome! And I agree with all of your points here.
Do you use these prototype for user testing? Any insights there?
We don't do a whole lot of user testing. Our clients are... I could say, a bit old school. They often don't see the benefit of modern UX process, no matter how much we try and pitch it to them.
For those on our team who have had the chance, it has helped a ton. And so far, those have been purely coded prototypes so it feels as real as possible.
The biggest insight I have is never to assume your users know basic computer use. We had some who struggled with scrolling down a page—it makes me wonder if they've only seen the web above the fold their whole life.
I hear a ton of good things about Vue. Currently using Polymer web components and I'm very happy with it.
If you haven't already read it, Vue has a good write up of how they compare to other frameworks: https://vuejs.org/v2/guide/comparison.html#Polymer
Also, for those interested, I did a summed up comparison of React and Vue a while back: https://www.quora.com/Should-I-learn-React-js-or-Vue-js/answer/Andy-Merskin
Hey, I read that when I was investigating Vue! Nice job.
In our team we use our own static site generator called Bedrock to create extensive HTML/CSS prototypes. You can find a full presentation about our workflow here.
Thanks for sharing, Johan. Great presentation!
Do you ever use those prototypes for user testing?
Allow me to reply to that: yes, we do it all the time. The prototypes serve many purposes but one of the big benefits is testing in a very real environment without developing the whole back-end.
Perfect, that's what I'm looking for. Can you give me an example of a real environment that you wouldn't be able to replicate with static prototypes?
Xavier is my colleague :)
Allow me to reply now:
With real environment he means the browser where you can use your keyboard shortcuts, where you can resize the browser
You can load the URL on any device as opposed to an Invision/Marvel prototype that displays just one device use case.
Hi - Yes I use primarily html / css prototypes to share designs with dev team. I use a stack of Middleman + AWS s3 to accomplish this.
I set up buckets that correspond to our current development sprint so that each sprint's designs are "locked", and available at a unique address (i.e. sprint01.myprototype.com) so I can continue to work on "future" features on the main prototype without risking changing what someone is currently working on. I also push a commit to our shared git repo that also corresponds to our current sprint, locking all needed code and styles for those items.
Cool, so that's how you hand off frontend work to the dev teams? Do you ever use those prototypes for user testing?
Yeah. It's not super useful for anything with multiple interactions between pages since there's no real data being stored, but the animations are present and I fudge modals with jquery etc to make it as close to "real" as it'd be.
It sometimes presents trouble in user testing because it looks so "real", users expect interactions to work, reflect inputs being saved, etc., So it's important to either use fake data and then specifically prompt for actions using that, or set expectations ahead of time.
I have a question about that workflow: how do you shield those prototypes from prying eyes?
Hi - generally they are only available via a specific link and only shared internally. Usually old buckets get deleted after the sprint ends - the designs themselves are archived in the git repo if they need to be referenced.
If there's anything super sensitive, there are a few Middleman methods you can use to password protect the bucket, haven't really gone down that path myself but it's doable probably
(1) Framer Our team at Amplitude uses Framer a lot to prototype new features and components. Although Framer is really for small micro-interactions, if you have JS experience it can become a powerful tool to prototype things that look as good as production.
(2) Labs Our front-end team has also built an entire area called Labs in our app where we can build using any JS libraries/hacky code we want. It doesn't touch the main codebase and doesn't require us to learn React and be fully compliant with our Front end coding standards. It's for experimentation! The important part is that since it's actually on our app, we can use REAL data and see how they would look in practice rather than just in a mock - which for an analytics tool is incredibly important.
Those are both really cool examples. Do you use those for user testing? If so, what benefits do those realistic prototypes provide that a static prototype wouldn't?
We don't currently use User Testing because we have the luxury or testing with real customers every week. We have on-going UX tests every week and we often visit customer offices to show them new designs so it's not a need.
As for the advantage over static prototypes.. it's all about the data! Especially when designing data visualizations, it's easy to imagine what something would look like but in practice it's so different for different companies. For example, as a super simple example, imagine a bar graph. Most examples you would imagine would show similarly sized bars. However, if most customers' data has 2 bars that are 20x bigger than the other 5 bars, then the smaller bars will be hard to see and show little variance. To test out all edge cases, a real live prototype can really save time by seeing it with real customer data. The bar graph example is a simple one but once you start thinking of complicated things that shows multiple dimensions then it gets even more needed to use real data. For example, I recently used a Packed Bubble Chart which I had very little experience with and I absolutely needed to prototype with real data before I felt comfortable it would work well.
I unfortunately can't share my prototypes. I work on internal tools for my clients - but I work almost exclusively with coded prototypes. My current workflow is heavy use of git, Middleman & Bootstrap for rapid prototyping. We migrate eventually to custom Sass, HTML for the final product. Sharing with the dev team happens via git. I push updates and everyone gets notified.
That's no problem, I'm mostly interested in understanding how coded prototypes help you user test. Do you use them for user testing? How does that compare to simpler tools like InVision?
Great question. We definitely use them for user testing and because, well it doesn't get much easier to test an app than the app itself.
How does it differ from image-map type tools? We didn't find inVision to be simpler, at least not for us. We tried it on our team and never got traction. We were uncomfortable with the number of duplicate objects that needed updating with every change, even with a heavy use of symbols. In inVision, nobody used the comment systems, etc. Syncing got to be a pain.
Granted, getting setup with git, middleman is, at first, challenging for some. Once in place, however, it's a simple workflow. We use partials and snippets to construct pages quickly. Or we copy code straight out of the Bootstrap documentation (ex. a pagination widget, or something).
Any interesting insights from user testing? Maybe users who think it's real or something you couldn't have learned any other way?
Kind of. I used couple of times for user testing some HTML prototypes. Usually for time efficiency I just have Invision Prototypes, but working for an app that had more advanced interaction and different languages to test, I decided to do a HTML prototype. Unfortunately I cannot share, but to answer your questions, I did alone the prototype, our design team is distributed, one for each product, it was only done for user testing purposes, it was only update once after the first test. It wasn't something complicated, Angular, React or different complex (for me) stuff, only simple html/css/js.
Thanks Mircea. HTML/CSS/JS is usually all you need for prototyping! It's meant to be hacked together so you can learn what you need to.
How would you compare your prototyping experience when you used code vs InVision?
I mentioned that I used only basic stuff, not something complicated like React or anything else in the same style.
Regarding the difference between code vs invision/marvel, you have pros and cons. Coding your prototype will help you do quicker changes especially when you want to test different copy in different languages and also if you have some scenarios that require to trigger different steps. Using an Invision prototype it's lot quicker for smaller projects or just to test or present a simple new feature.
My personal opinion, is that a designer could use both of these type of prototyping, but it always depends on what type of project is and what should prototype achieve, to test with users, just to present something or something that will be used by developers, etc. I find it harder to maintain a coded prototype, because the one that I did had slightly differences when comparing to the actual design, and the prod version had also some small changes, so I just think it's more difficult to keep all the versions aligned, as when you do only Invision you don't have this struggle anymore, just to check if the final product interfaces is aligned with design. Maybe it is my work process that needs improvements, but at the moment, this is how it goes.
I agree, I use Principle for simple prototypes around the office, but code when user testing. Do you use your coded prototypes for user testing? How has your experience been with those?
While I tried both, Invision and HTML, as I said it's much better to have HTML version, especially that I did the testing for a desktop app, so it looked more easy for the users to understand the context. The HTML prototype was done only with user testing in mind, not for something else : ) Takes more time, but you can have a better insights, as the user could play around rather than just see some images and wants to find out where to click.
At Asurion we started using https://github.com/HosseinKarami/fastshell as a standard boilerplate. It checked all the right boxes for the team at the time, as we wanted good team member participation and coverage, but not everyone on the team was very knowledgable on front-end work.
Basic html/scss with gulp built in, as well as light markup templating/partials. Made components reusable enough, while being approachable to those without a lot of js experience.
Cool, sounds like a good approach. How did the team members with less frontend experience handle it?
Did you use those prototypes for user testing? How did that go?
Workflow was a little clunky for those who weren't colocated with someone a little more experienced.
It was a good approach for a few bigger projects as the company had a very wide front-end skill gap. The prototypes served as styleguides, expected interactions and in some cases ended up setting code standards (that was scary hah).
More often than not, we used more static implementations (invision, etc) for testing. A few of the coded prototypes did get tested, but we ended up pushing that route on projects that needed more handholding.
At Aspire Ventures, we use Angular and Ionic templates to create coded prototypes. It's helpful, but not always the best course of action.
Ionic is great for getting apps up and running quickly. It sounds like you've had a bad experience with these prototypes. Care to elaborate?
Ionic is a great a tool for getting apps up quickly for sure and I actually haven't had a bad experience using it...the troubles come from the stakeholders. They ask for a prototype but they want a fully built app as an MVP....along that line of thinking....OK, sure....not what I would do before committing a dev team to building lots of customized code, but sure. The problem is there tends to be little or no testing before we are asked to commit to building the app. We could easily rectify this by building something quick with Figma and Framer or Proto.io to at least test and see it's worth building out further. Once something is built....9 times out of 10 it gets shelved or tossed and we've wasted a ton of time and resources that could have been mitigated. All in all, coded prototypes are great and serve a purpose, but from my role I want to try to reduce the amount of cost and manage the expectations of project stakeholders. Case in point...
We built an app in a day to take pictures of skins lesions so that our AI backend would tell you if it's nothing to worry to about or that you should see a doctor (sort of like the old FaceSmash site Zuckerberg did before Facebook, but for skin lesions). It was a simple enough concept and it took up three people all day to design, build and test for functionality. It was thrown out by the end of the day. Was it a prototype or full functioning app? Regardless, it was huge time and resource suck. That is the danger I sometimes see with coded prototypes.
Okay, I totally understand where you're coming from. We don't always make coded prototypes. For smaller, simpler project we'll just something like Principle. We only use code when we need real interactivity for testing, and even then it's as fast and scrappy as we can make it. Thanks for sharing!
Here at Withings we've used HTML/CSS to discuss layouts with both web and mobile developers. We've also used Processing to test animations or actions on our connected devices (for instance launching and testing lullabies with lights and music on the Withings Home Camera).
Heck, we sometimes even use Flash to fake and user-test interactions with our connected physical products before we have physical prototypes. For the Thermo thermometer for instance, we would give test-users an illustration of the device on an iPad and let them interact with it, placing it on an illustrated baby's forehead and so on. We learned a lot that way.
It's really about the perimeter of your test and the hypotheses you want to validate.
Agreed, there's no right or wrong answer to prototyping, only the question of what you need to learn.
That's awesome that you were able to prototype with hardware as well. How did users react to your prototypes? Did they think they were real?
No they understood or knew that it wasn't the final thing but we were able to see whether they tried to scroll, tap, swipe or any gestures they attempted on the interactive illustration of the device shown on the iPad.
We tested this either by giving them general instructions such as "take a temperature measurement for Leo" or by letting them navigate through a flow of screens, in an InVision-like kind of way.
My team (Lucid Software) created some Angular 1 components that designers and hack with at particle.golucid.co.
Login to Comment
You'll need to log in before you can leave a comment.
LoginRegister Today
New accounts can leave comments immediately, and gain full permissions after one week.
Register now