Sprocket App Design

I began by discussing the camera reduction possibilities with the devs. As mentioned above, we discovered multiple camera instances—exactly five. These multiple camera instances were a problem because each instance had to load individually, took too much time, and couldn’t communicate with each other. The goal, we determined, was to reduce to one instance—if possible. Thus began the hunt to decrease the number of cameras. After multiple alignment meetings and a lot of dev exploration to conclude which cameras could be combined, tossed, or which had to stay permanently.

We had three different AR APIs happening for our AR Feature (Reveal), and only two could function using the main camera instance. We realized that the limitations would require the Sprocket app to maintain two instances alone in the Camera function.

Having fewer but still multiple camera instances meant that there would be a slight delay each time a user switched cameras. To mitigate this, we needed to decrease or hide the delay. I defined a transition to work this magic. We would capture a view of the last camera viewport and blur it to make it seem like the change wasn’t as significant as it actually was. Otherwise, the user would see an odd black screen as one Camera paused and the other started.

We removed two instances: that left the primary Camera, the AR Reveal camera, and a custom sticker camera. Once we defined the camera instances, the design team explored competitive camera apps and polled them to discover universal patterns. We discussed the pros and cons of discoverability vs. findability. Discoverability, without coachmarks, won—because of the Camera’s many hidden features. A primary guiding principle that I defined for the Camera was: when a user wants to take a photo, they want to capture that moment, not be required to remember how something works.

In conjunction with the research team, I determined that obvious and extensible discoverability trumped findability. I made this choice because with a straightforward design we could analyze user behavior and easily tweak the interface in minor ways to make it better. Also, the more noticeable design would allow us to have consistent patterns. Only after we have done everything we could to make it easy would we consider falling back to animated instructional coachmarks.

The other reason that discoverability won was that static coachmarks are inherently broken. Their biggest failure is that they block users from being able to immediately use the features and leave no hint—as to how to use them when the coachmarks are gone. The result was a fully redesigned Camera and behaviors.

Each of these camera modes have specific options: timer, front/back camera, flash, and, in the case of PhotoID, capture size, and hints. Because phones on the market continue to outgrow the size of many users’ hands, I designed and tested moving the modes and the options nearer to the user’s thumbs and, therefore, easier to interact with. The Sprocket Camera function hasn’t ever recorded a high usage; the redesigned Camera, however, did lead to a higher percentage of use than the previous version by a percent or two.

A benefit to this change was that users could quickly select a photo, multiple photos, change photo sources, or switch to the Camera from the gallery. Research showed us that even though the choice screen allowed users to choose their path, most of our users chose the same one—their local phone gallery. Added to this usage data was the lack of expandability of the original choice screen—at some point, it would run out of real estate.

Gallery:

In the examples to the right (left to right), one and two (top) were designed before my arrival—both had a camera instance. Example 1 (top left) had a discernible camera icon, but the Camera disappeared as soon as the user scrolled their photo roll. Example 2 (top right) was simply an icon swap—the business wanted to focus more on its AR capabilities—and hard-to-read paging dots. (Note: the live feed is missing from two because we killed the camera instance during the camera redesign because it slowed down the app). Those gallery examples failed from the same defect for the secondary galleries; users couldn’t find the social media galleries. Example 3 (bottom left) focused on implementing the reusable global home bar (bottom-most portion), mode bar (allowed users to swipe to other features), and option bar (options within each mode). Example 4 (bottom right) was a beautifying iteration—we refined the overall example 3 experience and lightened up the interface, increased the font size, and added new Gallery features.

Print queue:

The print queue evolved from a modal in example 1 (top two images on the left) to fullscreen in example 2 (bottom left)—which could have just stayed a modal. Both of these designs were implemented before I took over.

The original idea was that example 2 would allow the company to create a Print Queue page. The goal was to iterate it; however, the only recourse for the user was to delete all unseen print jobs or do nothing. It was obvious, that this implementation wasn’t a good user experience and needed to be fixed quick. Example 3 (bottom right: my iteration) was rough, but it allowed the user to delete and move an item to the top of the queue—while it was a step in the right direction, its information was unorganized and clunky.

Example 3 was one of the first screens I worked on—just a few weeks into the job. I didn’t even fully know what the project would require. When we focused more on this function (after Camera and Gallery), I iterated the queue further, shortened the row height, lightened the interface, and introduced the home bar and options bar. But we did more than minor visual tweaks: we added the ability to switch printer queues to other connected Sprockets, defined the indication telling the users when the print job transferred from the app to the hardware, and added the ability to manage all sprocket printers right from the queue.

The challenge I faced, in this screen, was ensuring that the users understood where their print job was in the print/transfer process. Also, we had to define a minor distinction between two different kinds of queues—the new Sprocket printers had a hardware queue and a software queue. The software queue held the print jobs until all of the file’s data was transferred, over Bluetooth, to the hardware queue—which held up to 10 print jobs.

Further in the redesign, I introduced an accordion pattern—this pattern we would reuse in other places—for the users to see all of their Sprocket printers and switch them as needed. As I mentioned earlier, we introduced a way for the user to change to a secondary printer—if they had more than one—to see its queue (see the first image above). There was a history row at the bottom of the PQ in the previous versions—it took up a large section and would appear or disappear depending on if there were items.

In the redesign (see the clock icon in example one and example 4 above), we utilized the options bar pattern to allow the user to have a consistent place for history items. This history icon never disappeared—but it needed further iteration because it had some findability issues.

The first thing I noticed when I audited the onboarding, was how its design and styling didn’t fit our target audience of 14 to 24-year-old females. Secondly, the dark opening screen switched to stark white in the instructions. This inconsistency created uncertainty about the app. However, as I used the app more, I discovered anywhere there were heavy information pages, they were typically (but not always) stark white. But, it was so inconsistent that no pattern ever emerged. While most information pages switched to white, other pages like Settings (information-heavy) were still dark grey. This swapping between colors created a sense of incongruity with the app.

As a new user, I nor our test subjects knew when the screens would be grey or white and were surprised when they did or didn’t behave the way we expected. Thirdly, I noticed that the screens weren’t functioning as a group but as individual screens. Each setup screen moved as a whole screen—when the user swiped. Even though parts of the screens were shared, the entire screen had to be redrawn.

These behaviors created excellent opportunities to revise onboarding. We wanted the onboarding screens paging dots to be stable: and only the picture and instructions to move; we wanted the colors to feel consistent; and we wanted it to match our target audience. After creating stability in the onboarding, we focused on refining the setup screens and transitioning to a new style.

Focusing on our target audience, we determined, through exploration and testing, to use a softer color palette and less techy/rendered images. The original pictures were an heavily rendered touchpoint for our users and set an unexpected tone. We intended to craft a more appealing introduction to Sprocket with the new style. My focus was to tie the onboarding and visuals into the updated iconography used throughout the app. This change in the onboarding style would create continuity throughout the app—beginning to end. Along with these visual changes (see below), we determined which touchpoints needed to be updated to lighten the entire app experience.

I mapped these changes and created flows to identify all areas needing improvement. Two examples needed to be fixed immediately: the first time a user tapped the print button, a blocking modal popped up to tell them about HP’s AR experience. After a few uses, another blocking modal popped, on print, informing the user that they could use the Share Extension to print from other apps. In both cases, the user’s goal was to print. In both cases, the modal blocked them from completing the task—until they closed the modal.

These two examples are why I needed to reorder the information and flow. We needed to show that info, but we had to determine the best time to present learning material to our users.