Originally published on The InVision Blog on June 8, 2016.
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.
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.
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.
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.
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.
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.
Update (9/15/16) — I checked my review on whim and noticed that MVMT has redesigned their reviews area in such a way that you cannot sort by date or rating as you could previously. As a result, my review is now many clicks away, toward the end of the list. Okay.
The review itself has been edited by… someone. Apparently MVMT is threatened by mentions of competitors, so they edited out my 2 mentions of Timex, which very much changes the basic gist of my review.
What a bunch of babies.
Update (5/19/16) — My grousing on Twitter got the attention of MVMT customer service, who emailed me to resolve the situation. Apparently it has been the company’s policy to closely monitor incoming reviews, take down any review that seems to contain any hint of dissatisfaction, and follow up with the reviewer via email to resolve their concerns privately. This is, of course, a terrible policy and I’ve been told that it will be changing.
However, that this seemed like a good idea in the first place strikes me as incredulous. Removing reviews under the guise of a customer satisfaction protocol? It’s hard to believe that in this day and age an entirely internet-based business would not expect backlash over review censorship, however good the intentions.
In the end, though, my review is back up at its original 4-star rating. And yes, I’ll be checking periodically to see if it sticks. :)
I’m mature enough now that the idea of writing a blog post about a beef I have with some random company feels plenty distasteful, but sometimes the situation leaves one feeling like they have no other recourse. Ideally, someone googling for MVMT or Chrono Black/Tan Leather watch will be able to read this this and draw their own conclusions.
It all started with an email from MVMT Watches to review the watch I had recently purchased — a fetching Chrono Black/Tan Leather. “Tell us what you think!” the email said. Here’s what I wrote:
Very Stylish (4 stars)
Overall, I’m quite happy with this watch. It’s a striking design, and it looks just as good in person as it does in the photos. I get compliments all the time when I wear it. Well worth the purchase, for sure!
I would have given this watch 5 stars if it had not been for 2 small things:
1. The strap feels a bit “spongy” — if that makes sense. The upper appears to be actual leather, but it feels like a super-thin veneer of leather. I understand that “genuine leather” bands cannot be expected to use really thick leather, but it does feel really lightweight for the price of the watch. And consider that Timex sells its Waterbury x Red Wing chronos with thick leather bands for less than the price of this watch.
2. The chronograph pushers are very “clicky”. Meaning, when depressed, they make a click sound and feel like they stick for a moment before releasing back up. The effect is that it feels like something is broken, missing, or not lubricated. Again — even at this low price point — that the pusher action is not smooth like a $60 Timex just seems wrong.
(It’s also worth mentioning that I had to Google how to set the date and align the chronograph hands. Seems like a silly thing for MVMT to not provide any printed instructions with the watch, and to also make this information so difficult to find on the website.)
This review was never posted. After looking through the other ~50 reviews for the watch, I noticed that they were all 5 star reviews. Sorry, no one has a track record like that. Here’s one 5-star review from 2/27/16 that is still inexplicably posted for all to see:
LOSINGMINUTES (5 stars)
I’m finding my watch is losing minutes every few days not really happy with that situation you keep sending pop up ads on every page I go on very annoying at this point would not rebuy or recommend your product to any of my acquaintances
I find it hard to believe that a reviewer would rate a watch that does not accurately tell time at 5 stars. Something tells me that this reviewer figured out that a 5-star rating was the only way to have their voice heard and consequently gamed the system.
Taking this approach, I resubmitted my review again — this time rating it 5 stars but adding a disclaimer at the top that I was only rating it this highly to get it posted. I’m smart! And for a couple of days, it worked. My review posted and was viewable even after a page refresh, and on different devices. Success! The voice of the customer had been heard!
Nope. It’s been removed.
Look, I get it: you have an open comment form and the internet is full of trolls. You gotta police that thing. But when a verified purchaser posts a generally positive review with a few light criticisms, removing it without explanation casts a shadow over everything you are. It makes you look like a child who sticks their fingers in their year and yells “LA LA LA LA LA I CAN’T HEARYOU” to drown out the sound of disagreeable people talking.
Several years ago I personally discovered (I am certainly not the first person to do this) that writing out problems I encounter while designing often leads me to a clear solution. This exercise began as an attempt to solicit feedback from my coworkers via email, and to this day I often write inside an email program, even if I have no intention of sending.
The exercise is simple enough: I write out my thoughts on the problem as a solicitation for help, frame it up to ask for the recipient’s thoughts at the end, review it, and edit repeatedly for clarity.
By working through the problem with the mindset of explaining it to another person, a fuller story emerges. The process of articulating a thought to someone who cannot be expected to have the same understanding of the minutia — as the writer does — forces the mind to see the problem in different ways. It also requires discovering or recalling details that may have seemed inconsequential. And, naturally, it requires broader thinking to properly situate the problem in the recipient’s mind. All of this can lead to some very satisfying “a-ha!” moments.
I’m not exactly sure why this technique seems to work so well for me, but I have a few good guesses:
Like note taking, the simple act of writing a thing down makes it easier to recall and work with. The words are right there, right in front of my eyes. I have to make sense of it.
For me, at least, writing is a focusing activity. In order to really work at explaining my issue to another person, I have to concentrate more intently than if I was simply sketching possible solutions. I am forced to physically adapt my environment to the task (no noise or visual distractions).
A sense of manageability
There’s something soothing about reducing your huge problem down to a few blocks of text. I find that the amount of text I write always makes the problem seem less daunting. Like, “This problem is only 3 paragraphs long? Whew!”
Acknowledging all the information
Since the person I am writing to is not aware of all the details of my problem, I am forced to include information that I may be taking for granted. Seeing this information written down forces me to actively deal with it in my problem-solving.
This exercise naturally forces me to repeatedly run through and remold my narrative.
It can take some time, and I can’t say that it works 100% of the time, but it does work. If you’ve never tried this approach before, give it a shot. It’s not the only way to achieve clarity, but it’s definitely satisfying.
We in the UX business have all heard of dark patterns. These are interfaces designed to trick the user into doing something they probably do not want to do.
I’ve noticed a rise in another pattern recently, more subversive than malicious: something I like to call “jerk patterns”. Jerk patterns don’t hide their consequences, but seek to manipulate people on a more emotional level. I think this pattern has been around for a while. In fact, just today I encountered what I would consider one of these patterns as I signed out of my Amazon.com account, as I often do. Because I want to, that’s why.
The language Amazon used for my sign out link is “Not Jared? Sign Out”. Perhaps I am being too sensitive, but this language has always grated on me. The insinuation is that the only reason I should be logging out is if I have somehow found myself logged in to someone else’s account. If I want to log out, I have to basically acquiesce that I am not Jared, and acknowledge that I am performing an action counter to what the UI is telling me. The goal is obvious: Amazon wants me to never log out, and they have engineered an emotional way to discourage it. A jerk pattern is born.
But the jerk pattern has truly blossomed with the advent of doorslams and mainstream ad blocking. BuzzFeed recently published some good examples of jerk patterns. The ELLE.com email collection doorslam is a perfect example of this pattern; instead of a simple “No Thanks” as the link for declining to sign up for their newsletter, users get “No thanks, I’m not interested in protecting my skin”. Yeah, you must want to destroy your skin, you scumbag. This language is a type of shaming. A guilt trip. Backhanded. It doesn’t work on everyone, but it undoubtedly affects some.
Designers, don’t do this.
What I fail to grasp is how this pattern can possibly benefit a brand. The negativity and judgement is thick. I think we can all tell what’s happening when we see this, and it’s not a good feeling. I suppose the intricacies of brand engagement are above my head. I just don’t get it.
There is hope, however. For whatever reason, Elle.com has changed its link to “No thanks, my current skin care regimen works well”.
I just got back from spending 2 days in the field (literally), observing and talking to farmers about how they interact with software. We’re spending the first few weeks of this new project excavating the truth by observing with our own eyes.
Before we go out to observe users, we talk to people inside the client’s organization. They frame up the problem, often paint a pretty confident picture of the way things are, and explain what should happen next. It’s not unusual for this picture to appear fairly narrow in scope — something to the effect of, “We feel like we’ve got a lot of this figured out, and now we just need help with the user experience (i.e. user interface).” The picture also asserts a certain view of the user, and supposes to portray them fairly well.
And it’s great that the client has recognized that there’s a need for UX help. It’s why they called in a User Experience design company. No matter what off-kilter perception there may be of what is needed in the way of UX, it’s usually possible to effectively refocus those expectations.
But what you can’t do is design successful software based on faulty personas. It still amazes me what a different story we can encounter when we go observe people doing their work or talking through their challenges. When clients tell me that they know their customers, and are in contact with them regularly, I don’t doubt their sincerity. But relationships are complicated, and it’s only natural that the client/customer relationship may not be entirely open. Both sides can unwittingly tuck away important feelings and facts.
Research in the software design space is nothing new, though it is enjoying a steep rise in popularity — and for good reason. There is so much that users don’t articulate through plain conversation. Going to the place where they work and observing their environment allows designers to discover not only how the user works in the context of their workplace, but also the environment itself and all those ancillary and atmospheric details that the user would never think to mention.
Go to the field. There is so much more you can discover.