Ozark is a portfolio theme designed for all types of creative websites. It was built based in the latest trends in design style and typography choices.

Address

63739 Street B:9 City, Country

Phone

1-900-333-333

Email

ozark@gradastudio.com

Prontoforms Design

Case study

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.

  • Designer

    Andy Morris

  • Work on display

    Branding. App Design. Design Systems.

started from the bottom

Structure, Process, and Design Culture

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.

"A culture that is inspired with a passion for creativity, art, and design is one that produces inspired work. I love it when people are excited to share their work."

Design culture was important, and started by having a voice at Quarterly Business Review meetings with leadership. Upcoming work was presented, and roadmap ideas were shared. As the company continued to grow, so did our voice. UX advocacy happened through lunch and learn style talks presented company-wide, as well as through my mental health talks. More importantly, as the UX team grew, it was important to foster a culture of open idea sharing and collaboration. All our work was accessible to all, and we held bi-weekly “show ‘n tell” meetings. I also wanted a culture of failure and learning. On alternating weeks we held “f*ck up Fridays” where members of the UX team as well as guests from Product or Development were encouraged to share an instance where they failed, what they learned, and how they solved and overcame the problem. We also used the meeting to share other bad, funny, or inspiring design work we have encountered recently.

From theme to guide to system

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.

While providing a good starting point, the inherent problem with a design wiki is that it quickly goes out of date and requires constant maintenance. That really means it's always out of date.

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.

 

Let’s get nerdy

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. 

What is this sorcery?!

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? 

All that means is you get a perfect scaling UI with easy spec handoff to your devs.

Around 1/10th of our design system

"Complex enterprise-grade nesting conditional logic that is almost impossible for even a novice to break. It was a ridiculous goal. But I made it reality."

The Issue with Logic

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:

Too Simple – Flat Structure

Everything is at the same level and it doesn’t allow for complex nested logic rules. ex: If a=1 and (b=2 or c=3)

Too Complex – Not User Friendly

You can do anything you want (if you’re a developer). This creates errors and frustration for new users.

World-Class Conditional Logic

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.

Prontoforms phone designs

Mobile Applications

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.

old designs

Harmonizing the apps

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.

new design