Building the 'symplest' platform for small businesses
Symple's working on a platform for business payments (and more) that saves time, headaches, and money, especially for small businesses. Rather than the current complex and sloppy system of marked-up paper invoices, mailed checks, and hours of filing, Symple's approach is, of course, simple.
The platform instead enables customers and vendors to share and communicate about invoices and transactions. Businesses can pay and get paid and find new partners all within the app.
I was lucky to join the team in the heart of San Francisco during the summer of 2017 (after creating their brand) to help develop the first iteration of their mobile app along with the head of design, and we immediately jumped into creating the overall functionality of the mobile app.
I. Figuring out the app ecosystem
Our goals for version 0.1 were memorable interactions, a consistent interface, and an effortless experience — something that would function great now, that also served as a foundation to build upon. Practically, we also needed to figure out how it fit into Symple ecosystem, which we were building out alongside the app.
That ecosystem kind of looked like this:
The same functionality would exist in both apps: connect and communicate with business partners, upload and send invoices to those partners, and pay or get paid.
However, each "portal" to the Symple platform certainly has benefits and drawbacks. The mobile app can leverage the immediacy of a camera to prioritize invoice uploading and sending. In addition, because so many of our potential users — delivery drivers, bar and restaurant managers, vendor account managers — are often doing the bulk of their digital work via their phone, we needed to make the full experience on mobile excellent.
Meanwhile, desktop app should show more information in a denser but still digestible manner, taking advantage of the size of the screen and relatively little disruption in a users' workflow as they access Symple. This means more invoices available without a scroll and easy access to request and make payments. Kept intact as well is the ability to upload and send invoices.
II. Of course, we started with sketches
We moved fast, beginning quick mobile interface ideas with questions, like:
- How can we best display invoices on a small mobile screen, given the amount of relevant information? What's the most relevant?
- What's the best language to use for paying or requesting payment from another partner? How will users understand it best?
- What mental model of the app is the most helpful to users, and how do we structure the design around it?
These led to more involved descriptive flows various views of the application. How could this version of the invoices list look? How might the user expect to access and edit each invoice's information?
The two screen sections above, although fairly close to the final version of the app design I worked with, were, at this point, fairly unconnected visually to the rest of the app.
We had developed an interface style that the team was confident with, but we hadn't let it breathe beyond a few key screens. It was time to see how it could handle a broader set of interactions.
III. A whole other dimension
Moving from more static visual and interface design to a living, breathing interactive design is like putting on 3D glasses in a theater — the new dimension of actions, animations, and results serves up an entirely novel set of chances and challenges.
Suddenly, the differences between an intended design and the way a user might comprehend the application comes into sharp relief — do users understand that this screen is accessible from that one, and why?
This evaluative step was really important — several times we had to step back and tweak parts of the visual design to ensure users understanding of the app's structure and navigation was aided by the interaction.
One of the most important pieces of this v0.1 app was a core interaction — invoice capture and upload. Symple's users have a critical need to digitize and share invoices — they constitute the very heart of the interaction within the app.
This would be an important and worthy test of the visual design we had prepared so far — I got to work exploring the entire interaction:
- From the list of invoices, users select to add a new invoice
- Users take a well-lit, clear photograph of the target invoice
- Prompts appear to search for an existing business partner
- Using name or address, users select from a narrowed list of partners
- Users select the correct email address to which the invoice is sent. Alternatively: Users add information for a new partner here
- Optionally, users can add a comment to their business partner
- The invoice is sent
IV. Make it real, then make it right
As is the case with a quick-moving development project like this, we learned so much about the app and its context so quickly that the ideas presented in both the flow above and the sketches above that were supplanted by more nuanced designs soon after. In fact, nearly every design presented in this post is gone — they've either evolved (sometimes to an unrecognizable state) or gone extinct.
But this education about our own app was what we were really after all summer — it's impossible to design something without first making it concrete. We could have spent all summer planning and come away with an incredibly good-looking app that may have kind of worked.
Instead, by making it real first, we were able to move efficiently and reliably to an app that truly worked, with data to back that up.