Taking an invoicing application mobile

Launched in 2005, Blinksale is an invoicing application for freelancers and small businesses. Built exclusively for use in a desktop browser, the app had never worried itself over small screens. Mobile web browsing wasn’t a common investment at the time—especially for web apps—and responsive design wouldn’t develop until years later. But with the advent of the iPhone in 2007, the product landscape began shifting significantly and many web products began to go mobile.

As smartphones increased in popularity, so did the requests for a native iOS app experience for Blinksale.

In the fall of 2013, we were able to spin up a mobile initiative in order to support to the way our customers—and prospective customers—are now working. 

Initial research

The team began with high-level discussions of what it thought the app should be. Should it only deal with invoices, or should it also handle estimates, client management, settings, and any number of other features? Should the invoice creation process on mobile be simplified, or should we include all its bells and whistles?

There were a lot of questions and tough decisions. In the end, it didn’t feel right to treat the mobile app as an abbreviated version of the web app. We wanted mobile users to feel like they had the whole app in the palm of their hand so that, if they wanted, they could be completely untethered from the web app.

In the course of our product discussions, we started a list of core product features in a shared spreadsheet so that we could track the features we talked about. Now that we’d decided that the app should include pretty much everything, we had to define “everything.”

That simple spreadsheet evolved into a detailed inventory as I documented every screen, element, feature, and action in Blinksale.

Finding clarity

This was as much a discovery exercise as a documentation effort. None of us had been with the product since the beginning, and forcing ourselves to shine a light into all the corners of the app helped us get acquainted with parts that we hadn’t necessarily paid attention to before.

The end result was like one of those scenes in Iron Man where Tony Stark looks at an exploded holographic view of some piece of complex tech. It allowed us to see all of the pieces we were dealing with and how they connected to each other. We were able to have more specific and informed conversations about what should be “in” or “out” of the product. It also served as a map so we didn’t forget any elements as we reconstructed screens and functionality in iOS.

What we were able to see is that not every piece of functionality from the web app could or needed to move to iOS. For example, exporting a data table to an XLS file is not likely a relevant activity on a smartphone, but that is something that the web app can do. We decided that should not be a feature we pursue on mobile.

Once we’d tempered our understanding of what features should go into the app, I could more clearly explore design.

From spreadsheet to screen

After pondering the spreadsheet, I decided to jump right into Photoshop to explore a few key screens. Playing is vital to the design process, but it often gets stamped out by the pressure to meet deadlines or jump right into agile development. I didn’t want to leave it out, so I made sure that our schedule included time for this activity.

I chose to play around with an invoice (in both read-only and edit mode), and the invoices (list) screens. The invoice is the centerpiece of the app, and I suspected that solving design there would create a lot of patterns to be used elsewhere. And there are quite a few list screens within Blinksale, so figuring out that format could also assist design in other places.

As a result of making screen designs that looked very real—not sketches or other abstractions—I think I arrived at solid design decisions much more quickly. When you have space to play, pressure releases and the mind has permission to wander. And when you go as high-fidelity as possible, you avoid the pitfalls that lie between abstraction and reality.

So as I played with these core screens, tangential design—like primary navigation and other high-level design patterns—were also able to crystallize. The core aesthetic (color, fonts, etc.) also materialized quickly, as I’d been thinking about the next evolution of Blinksale’s visual design for some time.

Mapping the territory

With these structural and navigational ideas gaining more clarity, I decided to create a simple “app map”—a visual representation of the screens I’d need to organize and chain together. It helped me turn that very abstract spreadsheet into a high-level screen diagram. This visual also helped me prove out my main navigation ideas and give the developer a clearer picture of how I was thinking about the app’s structure.

Have I mentioned that the development team was privy to all of this work and these product conversations? They were. Development was exposed to design work from the very start and validated or raised red flags if I started going down a path that was problematic. Design should never be isolated—it rarely has all the answers. 

>

Designing for iOS

There’s been a lot of talk about how Apple’s influence may or may not be homogenizing user interface design, but I’m not going to get into that. What I will say is that our product team didn’t want Blinksale to simply pull in standard iOS UI elements and call it a day. We wanted to stand apart to some extent. Additionally, not all of Apple’s default design choices agreed with me in the context of this app.

But the great thing about a human interface guideline is that it’s a guideline. Think something isn’t quite right? It’s your app and your design—do something better.

For example, I wanted to do something more interesting and flexible than iOS’s standard text inputs. Other areas of the visual design were shaping up in such a way that this default element would look out of place. I also wanted to be able to make the UI more compact by putting 2 or more inputs side by side, and the default pattern made this difficult, if not impossible.

I ended up using an input pattern that displays the input label by default, but then animates it to up above the input area once the user begins typing. This allowed us accommodate that compact layout goal and give the app a fresh, differentiated element.

No operating system is going to hand over everything you need all of the time. It’s okay to push the boundaries and create new things so long as you stay true to the overall spirit of the platform.

Capturing interaction details

In completing the app design, I ended up creating mockups for nearly every screen. Remember that thing about high-fidelity design? With every screen I mocked up, more reusable UI was created. It wasn’t long before I was mostly dragging in elements from existing designs to create new ones.

As I finished each screen, I placed them into a Keynote deck where I could annotate them. I find that the narrative style of walking through a screen or a workflow enlightens the developers on the intricacies of the interaction design and helps the designer detect gaps, inconsistencies, and flaws. Chaining together screens helped me see the “story” of the interactions unfold, like a comic book. I could more easily identify where the successes and breakdowns happen between screens, and what I need to think about as the user moved from one thing to the next. 

These days, InVision takes the place of my old Keynote workflow. It’s easy to link up a bunch of screens with hotspots and guide the team through the specific click path with Tour Points. Dev Notes or Comments act as my annotations. And the screen-level transitions mean I don’t have to annotate how one screen animates to the next—we can all just see it.

Supporting development

Until this point, I’d enjoyed a very necessary head start in front of development. I’ve heard this approach referred to in industry lingo as “Sprint Zero.” It gives the designer an important opportunity to get some design figured out up front before anyone starts building. Remember making time for play? There’s that, and then there are a number of bigger design decisions that are better to make before getting into the wild seas of development.

By coming to the table with at least a vision for how screens should chain together (the app map), how users would get around (Keynote walkthrough), and what major UI elements would look like (mockups), there was less risk of major rework as we built the product.

Although we’d determined that the app’s feature set would be as close to the web app as possible, we still needed to define what we were going to launch as our first release—it couldn’t be everything. Plus, there was some foundational work to be done, like extending the application programming interface (API) to do things it hadn’t been asked to do before. We also began writing stories and forming sprints. (For the uninitiated, you can think of a story as a to-do, and a sprint as a short period of time—usually a couple of weeks—to complete the to-dos.)

For development, the nature of sprints acknowledges the impossibility of knowing with absolute certainty how long things will take to build. Design deserves the same treatment so that there’s sufficient time to properly work out problems. This requires a team with shared goals, reasonable patience, and personal responsibility. Everyone is trusted not to waste time, but they’re also expected not to rush out work that isn’t their best.

And… go!

The majority of sprints came with a Test Flight update that we could all download and use. Having an actual app to tap around allowed development to point out holes or problems with the design as well as validate that everything was working as it should.

Related: How we completed a 5-day design sprint in 3 days

Occasionally we ran across design needs that I’d missed. Sometimes development was pretty confident in a solution and, in order to get a feature completed, they went ahead and implemented the idea. I can’t recall us ever completely throwing out one of those solutions.

On the contrary, they were so close to what I would have designed that we ended up collaborating to get them just a bit more polished. On a good team, everyone—not just designers—knows what great UX looks like.

There were technical limitations, too. Sometimes we discovered that my designs weren’t possible to implement or were unreasonably difficult. I had to accept these constraints and then fabricate a different way to solve the problem.

It takes a village

It shouldn’t be news to anyone that UX isn’t just for designers. It never was. We’ve been fortunate to build a team that cares about UX and supports it.

We are more than our job titles. We didn’t figure out every iota of the design in perfect detail before development. Animations were one place where I could count on the experience of our developers to make recommendations. Others on the team provided input that greatly improved the design of the app. Great design takes a village.

One of the exciting and terrifying things about technology is that it’s always changing. Today’s solutions are tomorrow’s laughably clunky user interface. Every day is a new opportunity to take a pass over what has shipped and consider what could be done to make it better.

Onward!