ProntoForms is the global leader in field-focused low-code application platforms for enterprise. The Company’s solution is used to create apps and forms to collect and analyze field data with smartphones and tablets—either as a standalone solution or as a mobile front-end to enterprise systems of record.
The Company’s 100,000+ subscribers harness the intuitive, secure, and scalable solution to increase productivity, improve quality of service, and mitigate risks. ProntoForms is the registered trademark of ProntoForms Inc., a wholly owned subsidiary of ProntoForms Corporation.
Branding. App Design. Design Systems.
As the first UX hire at ProntoForms, I was immediately tasked with hiring our second UX designer, which meant we needed some amount of structure and process defined in order to function collaboratively and share content with stakeholders in a consistent way. I quickly decided on adopting an Agile UX styled approach and implemented a policy of “just enough” documentation. We document our work well enough to be understood by all, but not be overly wordy, repetitive, or complex. We always favour prototypes over mock ups, and mock ups over text. All documentation and assets live where they are most relevant. For features that are in refinement (pre-development), content is added where the PM/PO is documenting use cases, user stories (given-when-then) and requirements – usually in a wiki, such as Confluence. All prototypes, mocks and detailed interaction documentation are always in a shared space for open collaboration by all. Once a feature starts development, all content is posted where the developers need it most – usually in a “board” system like Jira. We integrate directly into the development process (prototypes in epics, individual mocks in stories). All discussion happens in shared spaces.
When I started, Prontoforms was using a generic off-the-shelf admin template they purchased. When we had a chance to reimagine the form builder with newer technologies, the first order of business was to create a style guide with design patterns. The document lived in the wiki so all could reference it.
We eventually outgrew the wiki and built a complex responsive design system. The company wanted to build a web-version of their native mobile application. The extra difficulty is that not only are the screen sizes drastically different, but the use cases and personas are completely different as well. A user on a desktop will be in an office and looking for a condensed view of the data, while a mobile user may be a construction worker in a distracting environment with direct sunlight on the screen. Text, touch targets, and spacing all needs to scale appropriately.
I created a 4px system I like to call an elastic design. All items are sized on a grid of 4px. However…
Items grow on a curve rather than by a fixed amount – that is, a 12px icon on desktop will grow by 4px to display at 16px on mobile. But an 80px header on desktop will grow by 16px to display at 96px on mobile.
It’s simply a math-based system. The grid sizing options available for desktop are:
4px – extra small
8px – small
12px – medium
16px – large
or 20px – extra large
If you want any size larger, you add up! If you need 44px, you get XL + XL + XS (20 + 20 + 4).
Each of the size names above have a mobile counterpart. You simply add 4 to each size. That’s how it works. If you have a smaller size like 20px, it only sizes up once to 24px. If you have a larger number like 44px above that is made up of 3 size “chunks”, it sizes up 3 times to 56 (24 + 24 + 8). Pretty clever huh?
Up until we released our class leading conditional logic, logic was stuck in the past. It was a complex technical problem that needed to be solved with design – not an easy feat! In fact, I had to use logic to build logic! Every other logic builder existed in one of two different states:
You can do anything you want (if you’re a developer). This creates errors and frustration for new users.
In order to build a system that was not only technically complex but also elegant and intuitive, I had to go back to the drawing board – literally. I used my trusty sketchbook and a whiteboard to meticulously map out the flow of building logic with nesting and brackets. Every other solution – no matter how complex – allows the user to build the logic incorrectly, then tells the user there are errors. But after my user flows were drawn on the whiteboard, I noticed a pattern. We can handle all the bracketing and nesting intelligently for the user. Since logic has to be in prescribed format, we can simply shape the UI to only allow the correct actions and take the complexity out of it. The result is a builder that manages to be equally powerful as it is elegant and intuitive.
Watch the video below to see the user’s journey from starting a new rule to completing a complex nested rule in 1 minute.
One design language, many native platforms. That was the challenge I set for myself. In these early days of mobile adoption in the workforce, I felt it was important for each app to feel as natural as possible on the platform. Even just 6 years ago, the mobile OS landscape hadn’t yet begun to mature and converge into more of a “standard”. Users were just getting familiar with their mobile OS, so a native experience was important to increase adoption and familiarity. At the same time, I wanted our mobile apps to look and feel familiar across various devices and platforms.
Each app looked drastically different, and each app behaved in completely different ways. The first step was getting all the design in line and following the same style guide. In order to simplify the design and allow for theming (for white label clients), I settled on a 3 colour system.
Primary: A dark colour that would be used for heading backgrounds and text titles.
Secondary: A more vibrant colour that is used for actions (links, buttons, and other touch targets).
Accent: A complimentary colour that is used for navigation (page nav, selected tabs & pages, etc).
Once that was set, the next task was defining a loose set of guidelines that each app should follow, yet retain the native look and feel. For example, each landing page should have the same header background and logo, the same icons with the same background, and the same action bar. However, the tiles should be styled to the native OS (ex: circular on iOS, cards on Android, and tiles on Windows) and the action bar should be placed where the OS normally handles this. Doing this across all 3 apps resulted in a mobile experience that is consistent and familiar, yet feels natural to use on the native device.