Redesigning ContractStandards for Mobile
ContractStandards is a site for attorneys in need of contract language. It is a free resource that lawyers can use to get standardized contract and clause language, along with relevant research, case law, etc.
We recently redesigned the website to better incorporate new features and generally approve the whole experience of finding content. Our team also wanted to use this as an opportunity to create interfaces tailored to desktop and mobile.
Decisions, decisions: native vs. browser
When thinking about improving the mobile experience, we discussed the possibility of creating a native app for iOS and Android. We opted to stick to the browser for two reasons:
- User acquisition analytics. Nearly 85% of our users come to the site by Googling a clause or contract type. This means that if a user Googles some of our content on their phone, we would still need to have a good presence in the mobile browser. A native app felt redundant given that most of our mobile users would be coming to us through their browser.
- Cost. We saw the additional cost and time to develop native apps as an unnecessary burden when a responsive web app would provide a perfectly suitable mobile experience.
Designing for Mobile
I was tasked with creating both the desktop and mobile versions of the site. For the mobile site, I wanted to create an experience that was familiar to users. I looked for patterns used on other mobile sites and came up with three strong candidates:
To test the usability of each of these layouts, I asked a few people from my team and some clients we work with regularly to open the images saved as PDFs on their phone. I then asked the users a few questions to test the intuition of the screens.
These tests confirmed my hypothesis that the navigation items at the bottom of the phone (option 1) made it easier to navigate. With the thumb doing most of the interaction on a phone, option 3 was harder to use because a user had to reach outside of their general comfort zone to navigate the page.
Option 2 was less of an issue, but the collapsible section headings meant that users would have to sometimes scroll through the page to find the section they wanted.
Option 1 proved most useful because all page navigation elements were right at the bottom, by the user’s thumb. This allowed for easy navigation without stretching or scrolling.
The next step was more of a thought experiment. I looked through our contract and clause libraries to get a sense of the variety of data we would use in this layout. The length of the content varied significantly. In the case of a document like a software license agreement, we might have text roughly 20 pages long. On the flip side, some very simple clauses might only be a few lines long.
Longer content presented a challenge for option 2. If a user was looking at a long contract and wanted to navigate to some of the commentary, they may have to scroll for a while to find the proper section heading. With option 1, the bottom navigation gave the user an ever-present navigation bar they could easily use to switch between the text of a document and the commentary.
The End Result
Option 1 proved to be the ideal layout. Our test users found that the navigation elements at the bottom of the phone, near the user’s thumb, made it easier to quickly jump between sections. The bottom navigation element was also immune to variable content length. It sticks to the bottom regardless of the content’s length. This makes it easy to see and use the navigation in all cases.
