Viewpost is a business network for payments and invoicing. They approached me in 2014 to work between the UX and Engineering teams on a variety of projects. I spent the most amount of time working with the mobile team organzing and shipping the first version of their iOS Application, while reworking and redesigning for the second version.
I had been working with the Viewpost team for 5 months on two other projects before starting work on the iOS product in January of 2015. I learned shipping the iOS application had become the highest priority from the CEO down. Engineering and management resources were shifted to push the product out the door within the first quarter. Development on the first version was about 50% completed when I started work. I worked directly with the mobile Product Manager and engineering team to start understanding the scope, intention and direction for the mobile product.
Earlier in 2014 the UX team had started mobile design with the knowledge the product would be built with Xamarin, a non-native iOS tool, to help with time-to-market concerns. I quickly learned a main challenge in working with the iOS product would be pushing forward the current design and balancing the constraints of a non-native iOS product.
I took the first design and made a few small tweaks to help with overall clarity and getting the product out the door. I helped connect colors, typography and re-organize spacing in the table view cells to increase clarity and deference.
This previous design had some baggage that came along with it. I learned one of the stated goals from management was feature parity with the desktop web application. This drove the direction of the first design and kept it cornered.
Learning about these constraints and organizing them into notes shared with the rest of the team, I set out to identify a few key decisions we could make to drive simplicity in an entrenched design.
To narrow in on some things I learned from researching the current mobile situation, I created prototypes using the previous design and used the work-in-progress 1.0 prototype. This helped me identify 3 distinct problems to start working on for cleaning up v1 and preparing for v2.
Deciding to rework the navigation was a quick initial hunch that I had to find more validation on. This quick prototype tests helped me confirm a flyout navigation wasn't suitable for this application. It required the user to many taps for moving between content and most importantly, flyout navigations don't fulfill the main goal for good navigations, answering these two questions -
To validate some assumptions around the navigation design, I built a tappable prototype of the current flyout navigation and tested it with users against a tab bar navigation. I showed them each design and asked them to perform a task. The tab bar performed better on each task.
The transition to a Tab Bar design was a big one for the team, the Product Manager really championed the direction and got the entire team on board. Moving to the Tab Bar also became part of a bigger transition towards a more native build to help with speed and responsiveness. With the Tab Bar Controller being built natively presenting WebViews for content within, as part of the transition strategy.
The Tab Bar represented a big fix in navigation clarity, working on icons that represented each section well was another hurdle. I designed each icon from scratch to help keep context of the Viewpost brand and match the iOS design aesthetic. Additionally, the Tab Bar reduces navigation taps by ~33%.
With the Tab Bar helping the redesign goals 1 & 3, I started working towards ways to make the UI feel more comfortable and familiar. I think a great interface has an ability to evoke a sense of understanding and connection. I worked on adding this to the Viewpost UI in three specific ways.
A big part of working towards both of these goals was identifying reusable styles and components. I think compounding patterns in UI behavior add to a feel of familiarity within the app, so creating systems the app can work inside helps towards this goal. Pulling from the original design, the TableView pattern works tremendously in both of the goals for driving familiarity.
Using these repeatable components as building blocks, I prototyped lots of ways to put the views together. Knowing the frame of the navigation and having these components designed, I used lots of different view combinations to test different hierarchies and flows. I used InVision a lot in this stage to test the different views on device with other people.
Here are some of the full views created from components of Sketch Symbols -
The beautiful part of creating constraints for your work to sit in, is the clarity that comes in unexpected places. It became extremely clear which pieces of the interface needed more complexity to work inside. To accomplish this while maintaining organization, I utilized a card system to act as a control container for how those packets of information could be displayed. This same system is applied to 3 different information packets and interacts with a full-view on each container.
One of the harder interaction problems was creating a simple way for users to filter their lists of Invoices and Bills. Some of the work required trying to reorganize how Viewpost classified the work as a company and working with the engineers on how data is organized in the database. We spent time exploring apple's trandtional Segment Control, both below and in the header. As well as a more android inspired active view indicator. Shown in the middle prototype below.
Creating constraints also helps in knowing which rules help and which ones hinder. The iOS Segment control brings a lot of clarity, but it has a certain weight and unfriendliness that it can add to a view. For switching between invoice and bill states, I made an interaction prototype in framer (above center) which utilized a more "material" design segment control.
Throughout the design process, I relied heavily on prototyping through InVision to facilitate in-hand testing. I worked with the mobile PM to show the clickable prototype to as many people as possible. Through showing the product, some crucial bits of feedback began to show and we identified a few places to continue iterating our design.
Some of the questions that arose in designing around the first problem were When do we send users a notification?, Which data is activity and which is a task? and What channels should we use for notifiying users of certain actions?
The answers became more clear as we organized the actual types of notifications users would be getting. Certain notifications required action, some only carried data. We organized the two into two separate categories and defined them Tasks and Activity respectively.
The Viewpost iOS application is an extremely feature rich product. I think it was simplified and organized well, but the highest order of simplification didn't get touched. Setting hundreds of features on fire. If I could re-work the product again, I'd start at a much more refined place of the mobile experience. Without any testing on this hypothesis, I think the product could have been trimmed to solve two primary user interactions.
Letting you approve invoices, make a payment, delegate a sign-off while you're away from the office. And letting you get a quick overview of where your current assets sit. I think the product could have been simplified this far.