Lucid Particle: How we design in code
Scaling our prototypes and bridging the engineering gap
--
In our last post, Taylor advocated using Codepen as a prototyping tool for our design team at Lucid Software. In this post we are going to jump into more details about our system and component framework for building these prototypes.
Up until four months ago, we probably worked like most UX design teams. We designed using whiteboards, made mock-ups in Illustrator and Sketch, and even prototyped in Invision. However, we still struggled to overcome two main problems in our product and software-making process.
The first problem was a customer feedback problem. We were limiting our feedback (type and quality) with customers by using task-oriented usability methods and static prototyping tools. These methods and tools did not reflect the nuances, affordances, and response patterns of our own product.
Because our products are complex editing tools, we needed more open-ended research methods to test new concepts and workflows.
The second problem we had at Lucid was our handoff of design specifications to engineers. Whenever we described design details in mocks or with CSS annotations using our PDF component guide, we almost always had a loss of detail in the final code. Even with an incredible engineering team, some delivered design details would be lost due to the fast paced nature of our workflow. The result was a functional product that was less than polished.
Lucid Particle was born from the need to build and describe interactive components online — both for engineers to reference in their environment, and for designers to build highly interactive prototypes. Lucid Particle bridges the gap between design and engineering. More than just an online code reference, it documents our process of designing and speeds up our prototyping efforts in Codepen.
Training
Understanding that not all designers on our team have the same fluency with HTML, CSS, and Javascript, we endowed this project with a few learning tools. We put a section for designers to get started using our components in Codepen and a section for some quick angular tutorials. http://particle.golucid.co/#/angular
Each Monday, our team holds Lucid Particle training for 30 mins to go over new components and teach prototyping strategies with our component system. After 2–3 hours of training, my team can build sliding panels, interactive buttons, icon states, right-click contextual menus with tooltip logic, and modals. It’s pretty dope. These simple components empower the designers on our team to build what they couldn’t on their own.
Colors & Icons
We’ve also made it very easy for both designers and engineers to reference and use the right colors and icons for all of our projects. We built a color table that references both the hex value and color architecture of our product with a simple click-to-copy interface. Our team can paste these variables in prototypes or in real code ensuring that we always have the latest and accurate color value.
Similarly, we built an icon table where both designers and engineers can copy the SVG source. This allows us to reference and control all of these icons in one place. Sick of engineers tapping you on the shoulder for an icon? Our engineers now reference the same source that we use, and are now more self-sufficient.
Prototyping with “particles”
Lucid Particles are pre-programmed web components (i.e. popovers, dropdowns, modals, inputs, more-drawers, etc) that are the primary building blocks of our products. With a few lines of HTML and some custom inputs, a designer can create a powerful interaction in minutes.
Normally to build a simple popover, a designer would have to code the HTML, CSS, Javascript, and transitions. They would have to repeat this process with each new instance and duplicate work across each prototype. Imagine having a team of 5 designers each trying to optimize, tweak, and reuse that code — not to mention trying to keep all of these components consistent.
Trust me, we learned this the hard way. Our first few weeks in Codepen we had 3 frankensteined prototypes that were all half broken with inconsistent and illegible code. Now our designers copy and paste simple angular components with the styles, javascript, and transitions already baked in. When we need to add or edit our components, I create the edits locally, push it to our Github project, and everyone’s projects are updated automatically.
Particle Examples
Popovers
In our product we hide functionality through progressive disclosure interactions and workflows — This helps keep our product simple and prioritizes focus on primary actions. If a designer wanted to code a popover by hand it would take at least a hundred lines of code. Now they can do it with three lines, and a few custom inputs.
<lucid-buttcon-popover icon="[ICON URL]" width="200">
<img src="[POPOVER CONTENT URL]">
</lucid-buttcon-popover>
We built our components in such a way that designers can easily add a placeholder image, as a replacement for a fully coded experience. If the feedback we need to get from customers is more granular, they can replace that image with working inputs, buttons, and components. Each component comes with inputs that allow customization. In the popover above changing out the icon is as simple as copying the URL from the icon table, and inserting it in the icon attribute.
Dropdown Lists
Both of our products, Lucidchart and Lucidpress, give our users the ability to customize their documents through settings and configurations. As we started testing the settings panel in our prototype (below) we removed the image placeholders and added more interactivity. Below you can see dropdown lists, on/off buttons, input-steppers, simple action buttons, and collapsible content bars.
Our dropdown code comes with inputs for width, optional label, appearance class, and options array. This allows designers to use the same component in different places in the product without having to customize the code themselves. Depending on the location, we may not show a label, there may be size differences, and varied widths.
<lucid-select width="165" options="[ 'Letter (8.5x11.0)', 'Legal (8.5x14.0)', 'etc..']" label="page size" class="condensed">
<lucid-select>
Finger Tabs
In under a minute a finger-tab structure can built and ready to test. The designer only needs to insert a name, include icon (if the tab uses an icon), choose which tab is selected by default, and insert content into each of the different tabs. Most of the time we fill these with static images.
<lucid-finger-tabs>
<lucid-finger-tab name="Collaborate" icon="[[URL]]" selected>
<img src="[[TAB 1 CONTENT IMAGE URL]]">
</lucid-finger-tab>
<lucid-finger-tab name="Publish" icon="[[URL]]">
<img src="[[TAB 2 CONTENT IMAGE URL]]">
</lucid-finger-tab>
<lucid-finger-tab name="Facebook" icon="[[URL]]">
<img src="[[TAB 3 CONTENT IMAGE URL]]">
</lucid-finger-tab>
<lucid-finger-tab name="Embed" icon=" [[URL]]">
<img src="[[TAB 2 CONTENT IMAGE URL]]">
</lucid-finger-tab>
</lucid-finger-tabs>
Modals
Modals allow us to scale certain options and workflows so that users can work in a simple clean editor. We use modals for things like importing, exporting, and sharing. Our modal component is built to center on the page, softly fade in, and be dismissed by either clicking the “X”, cancel button, or outside the modal in the dark overlay. All of this interaction is built using a few lines of code.
<button class="lucid-button lucid-blue" ng-click="importModal=true"> Show Modal</button><lucid-modal showmodal="importModal" width="590" height="460" title="Import Files" confirm="Import" cancel="Nevermind">
<img src="[[IMAGE FOR MODAL CONTENT]]">
</lucid-modal>
Value of prototyping with code
Building this system, took a 6 week investment (one designer). We had to juggle schedules and punt on a few design projects in order to get it built, but it was definitely worth the time. Now we have 5 designers capable of using this system on each project.
Now when we user test, we schedule a call/screencast, send our users a link to the latest prototype, and sit back and watch. Our users can explore more with less structured guidance. Now they can discover features more naturally, and we are tied to a strictly ordered feedback outline. We’re more comfortable watching somebody struggle because we are no longer locked into this linear prototype experience. Sometimes the tasks they struggle with early on in a feedback session, they figure out on their own later on during our call. They can learn as they experience it, instead of us playing simon-says and telling them what to do.
We have to remind our users, “This is just a prototype.”
Having this richness for a low cost investment of time, allows more realistic feedback. In fact, one thing that we’ve notice in using this method is that users cross the threshold of believability earlier on in the feedback session. Like a magician that causes you to forget the laws of science, we bring our users into this world of believing that they are actually interacting with the real product.
The Future
We continue to push the envelope and narrow the gap between engineering and design. This is a growing and evolving project, so I’m excited to update and change our process as we learn.
Lucid Particle is currently being referenced to build our production code, but I imagine a day when our production code is used in our prototyping process. One of our goals is to have an interactive canvas that can be plugged into our prototype, so users can test their real documents in our environment as we test new features and workflows.
These processes have proved to be invaluable to our product design experience, and we’re excited to see what the future holds.
(This is a post from the design team at Lucid Software. We make collaborative diagramming and layout tools: Lucidchart and Lucidpress.)
