Why we user test with CodePen
When some prototyping tools just don’t cut it
At Lucid Software we dig into data, analytics, feature requests, bug reports, and anything else we can use to understand how to improve our products. The real test of utility comes when customers get to take the design for a test drive, which is normally only possible after an engineering team has spent a few weeks building out our prescribed solution.
But what if we were wrong?
What if engineering spends weeks or even months building out a design that completely misses the mark? How can we be sure that the designs we delivered were the right ones?
A quick band-aid fix might be to show your mockups to customers and ask them if their needs are met. This might occasionally drum up good feedback, but we quickly learned that people have a hard time describing a true solution to their needs.
We were searching for a way for us, as designers, to serve an experience to customers that would be as close to reality as possible. We test drove products like InVision and UXPin, and played with animation tools like Principle , After Effects, and even Keynote. But in the end we settled for the best prototyping tool of all: good ol’ fashioned code (and it looks like we’re not alone).
No matter how “native” a prototyping platform claims to be, the user is always at a loss. The core of our product experiences rely on user input, which these tools rarely provide for. Can they actually input data? Can that data be manipulated to supplement their experience? We found these benefits and more when we started prototyping in CodePen.
A team tool
My first prototype at Lucid was a one-for-one recreation in CodePen of my new design for the Lucidchart documents list. It provided exact metrics for hover animations and transitions. Developers were able to pick and choose CSS as they pleased. This proved to be an extremely easy way to introduce motion into the product without having to sit next to an engineer to tweak easing and timing.
Soon after, other members on the team began to prototype in CodePen as well. Being in the cloud allowed for live collaboration, reusing code across different projects, and opportunities to teach good programming practices. We’re fortunate enough to have a team that’s not afraid to get their hands dirty with code.
All work on CodePen is automatically hosted. This allows for collaboration without needing to set up designers on a git repo (which, as we’ve learned, can be disastrous). With CodePen, designers have immediate access to modern front-end web technologies like Jade and Sass without needing a Grunt/Gulp setup (or something similar). Everyone is up to speed and working within minutes. Not days.
Show your work
When our prototypes are stable, we send a URL to customers and have them share their screen through UberConference (which is free and easy to use). CodePen allows us to create a completely sandbox environment. We very rarely tell the testers that they can’t click on something or that certain components don’t work. We encourage customers to explore the prototype in the same way they would use the real product.
We can also show multiple versions of our work, in a sort of psuedo A/B test. We send multiple CodePen links and have the user try the same task in different versions, then explain which version they prefer and why.
Customers are asked to think out loud and express any concerns or frustrations they have with what they’re using. We receive very real and relevant results from our testing with CodePen.
Our latest iteration uses AngularJS to capture and handle data. Users can create and rename pages, drag and drop content, sort and reorder lists, and much more. This has been an indispensable source of feedback. It allows users to feel the UI shift and change based on their input— the exact same way the real product would react.
The future of design
A typical source of friction for a designer is handing-off work to a developer. The burden is either on the designer to create pixel-perfect specifications, or on the developer to analyze those specifications themselves. Many times, both of these fail.
A designer may not know exactly what specifications are needed to code their design. Every width, height, margin, font-size, color, border-radius, and shadow needs to be account for. This doesn’t begin to scrape the surface of transitions, movement, and hover states. The development team may not realize what is missing or know what to ask for.
We’re working hard on unifying the coding efforts of both developers and designers. We’ve begun to develop a CSS framework and component library that designers can use to prototype, and developers can use to unify their CSS. This will bring us one step closer to to bridging the gap between design and development.
Using CodePen as a user testing tool is free and easy, but also extremely valuable. We’ve seen phenomenal results from our testing, and plan to keep pushing the limits of our work.