In 2017, I was hired by HP as Lead UI (interaction and visual) designer, as well as UI storyboard artist, for the HP Sprocket printer app team. They desired to see the 2.5-star app become "World-Class." My first task was to audit the app and define some areas that needed improvements. My initial examination revealed a heavy reliance on modals to dialogue with the user, features that had unpredictable outcomes, and a lack of consistent patterns. Based on this audit, the team (myself, a lead architect, and a visual designer) began planning ways to change the app and create consistency.

Using typical design heuristics, I began to focus on revealing hidden functions and creating consistent principles and patterns for any new features or updates that follow. 4.8 stars later, the app now has principles, patterns, and has become much more user-centered and standards-based.

Building a team

After the design audit, I needed to begin building rapport with the visual designer and the iOS and Android dev teams. On top of the weekly design-to-dev review, I started having weekly meetings to share the new design direction, get their input into how they see the current design working out, and discussing with them ways to develop with patterns and reusable/extendable code. A lot of the app, the developers expressed, was hacked together with spaghetti code—due to short timelines. At the same time, the visual designer (VX), and I began to transition our designs to the new patterns and began explorations around styles, colors, and standardized patterns.

While she (VX) did visual exploration, I transitioned our team over to an Agile workflow using Jira. (We were the first team to transition to a fully Agile team of any of the design groups in HP print.) This flow allowed her and me to work in the same system that the devs were using. It created a public design backlog where we could all be aware of what was currently being worked on, work in planning meetings together, and understand what the next sprint would contain. Daily standups, dev-to-des discussions, and design discussions melded us into a remote but functioning team—who were excited about the new direction and potential.

New Definitions

In concert with the above, I built interaction flows, defined new patterns—for each of the new or revised features, and planned a loose road map toward future versions. Our first real challenge, as a team, came when the PO wanted to use instructional coachmarks, for the camera, which I had shared with them during the audit. Upon review, the design (lead by me), dev, and research teams determined that heuristically this wasn't the best way to handle the problem. The issue we discovered was that there were too many separate camera instances in use and none connected to the other.  Because of this, we began a slow process toward rebuilding and simplifying the Camera use throughout the app.


I began by discussing the camera reduction possibilities with the devs. As mentioned above, we discovered there were multiple camera instances—five to be exact. We determined the goal was to reduce that to one—if possible. Thus began the primary challenge of decreasing the number of camera instances—this took multiple meetings to agree upon a direction and discover which cameras we could combine, lose, or which had to stay temporarily. For our AR Feature (called, Reveal), we had three different AR functions happening, and only two could work using the main camera instance. This meant that Sprocket would need two instances just in the Camera function alone.

Each time a user wanted to use one of the other AR features that we would have to switch cameras and display a transition between them so the user wouldn't have an odd black screen as one camera pauses and the other starts. This oddity led me to define a behavior of capturing the app's screen state and define the blur amount to limit the feeling that a glitch was happening.

In the end, we were able to remove 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 camera apps and polled them to discover universal patterns. We discussed the pros and cons of discoverability vs. findability. Discoverability, without coachmarks, won. This was because of the Camera's many hidden features. Also when a user wants to take a photo, they are in a moment. Users want to capture that moment, not be required to remember how something works.

Further, the idea of static coachmarks is inherently broken. The biggest failure with them is that they block users from being able to immediately use the features and leave no hinting behind—as to how to use them when the coachmarks are gone. I determined that obvious and extensible discoverability trumped findability because it would allow us to tweak the interface in minor ways that we could analyze and fix easier, it could have consistent patterns, and only after we have done everything we can to make it easy then we could fall back on animated instructional coachmarks.


Because of the aforementioned request and the difficulty for us, as well as our users, to understand, find, or use the hidden features of the Camera, we focused on redesigning it first.

Original Camera Flow
Camera Flow


The changes we made brought the Camera features (we call them modes) of camera, video, photobooth, Reveal (sprocket's AR capabilities), and, later addition, PhotoID to the foreground—to allow them to be easily discovered and new features could extend it as they were added.

Each of these modes has 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 user's hands, I determined that the modes and the options should be nearer to the user's thumbs and therefore easier to change, enable, or disable. (This behavior was tested before finalizing.) 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.

Final Camera Design Screens


Gallery, Preview, etc

Post Camera redesign, we began planning to update the remainder of the Sprocket app.

Landing screen

Once a user has onboarded and set up their Sprocket, the original app opened with a selection screen. That screen laid everything open and allowed the user to choose from any source they wanted. What we discovered, however, was that 97-99% of our users printed from their local phone gallery and only secondarily used the camera, share extension or social sources. With this information in hand, we refocused on our primary users and defaulted the landing screen to the local gallery.

The reason for this change was because from the gallery the users could quickly select a photo, multiple photos, change photo sources, or switch to the camera. Even though the choice screen allowed users to quickly choose their path, the majority of our users choose the same one—gallery. Added to this usage data was the lack of expandability of the choice screen—at some point, it would run out of space.


Global Navigation Bars: Home Bar (bottom), Mode Bar (middle), Options Bar (top)

Working from left to right, below, versions one and two were designed prior to my arrival—both had a camera instance. Version 1 had a discernable camera icon, but the camera would disappear as soon as the user scrolled their photos. In version 2 was simply an icon swap—the business wanted to focus more on their AR capabilities. During camera redesign, we focused on removing the live-feed camera instance—because it was slowing down the app. Both of these versions made it difficult for users to find social media galleries. Version 3 focused on implementing the reusable global home bar (bottom-most portion), mode bar (allows users to swipe to other features), and option bar (options within each mode). Version 4 is an iteration. We refined the overall version 3 experience as well as lightening up the interface, increasing the font size, and adding new Gallery features.

Print queue

The print queue evolved from a modal in version 1 (two images below far left), to a fullscreen in version 2—it could have just been another modal (second from right). The idea was that version 2 would allow the company to create a Print Queue landing page. The goal was to, later, iterated it, however for the user, their only recourse was to delete all unseen print jobs or do nothing. This wasn't a good user experience. Version 3 (far right) allowed the user to delete and move an item to the top of the queue—but it's IA was unorganized and clunky.

Version 4 iterated the queue further, shortened up the row height a bit, 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 queues to other connected Sprocket printers, defined the moment the print job actually transfers to the hardware, and the ability to manage printers from the queue.

Also, because the new Sprocket printers have a hardware queue as well as a software queue we had to define a minor distinction between the two. The software queue holds the print jobs until all of the files are transferred, over BT, to the hardware queue—which only holds up to 10 print jobs. The goal was to help the users understand where things were in the printing/transfer process.

Therefore, the version 4 Print Queue design introduced an accordion pattern—this pattern we would reuse in other places. As I mentioned earlier, we introduced a way for the user to switch to a secondary printer—if they had more than one—to see its queue (see the first image above). In version 3, there was a history row at the bottom of the PQ—it took up a large section and would appear or disappear depending on if there were items.

In version 4 (see clock icon in image 1 and image 4), we utilized the options bar pattern to allow the user to have a consistent place for history items. This history drawer never disappears—but it also has a bit of findability issues happening. This section could have used some iteration to make it more discoverable.


The version 1 of Preview never changed through multiple iterations. There were minor adjustments, but no major differences. Preview version 1 had an image preview, edit, share/save, print button, and a drawer that users couldn't find—it had a line or dots depending on the version and the affordance was too thin to be recognizable.

Preview version 2 introduced the Navigation Bar (below) but it had a hidden Add Printer affordance. Most of our users only had one device and would only have one. We made the decision to design the Add Printer affordance with a press and hold until we could define a behavior we could use app-wide. Version 3 moved the Add Printer menu from the press and hold print button interaction to the top in a dropdown menu. This menu was introduced as a switch printer mechanism in version 2. Also, in v2, a modal Add Printer flow would appear the first time a user tapped the print button, when no printer was paired, but required a press and hold on the printer button when at least one printer was paired. Another addition in v3 was a lighter background and header continuing with the intent to lighten up the interface.


The first thing I noticed when I audited the onboarding was how its design and styling didn't seem to fit our target audience of 14-24 year old females. The second thing I noticed was that the dark tone, used throughout the app, switched to stark whites at times. This created a feeling that there wasn't a planned style/color pattern for this behavior. In fact, the more I used the app the more I discovered heavy information areas were typically (but not always) stark white. This behavior of swapping between colors created a sense of incongruity with the app as a whole—this was because pages like Settings (information-heavy) were still the dark grey.

As a new user, I couldn't know when the screens would be grey or white and was surprised when it did or didn't behave the way I expected. The third thing I noticed was that the screens weren't functioning as a group but as individual screens. Each setup screen, when the user swiped, moved the entire screen—even if they had shared attributes (see split image below). Making the onboarding behave as one group was one of the first revisions we handled for onboarding. The next thing we focused on was refining the setup screens and transitioning to a new style.

Focusing on our target audience we determined to use a softer color palette and less techy/rendered images. These images became an iconic touch point for our users. Our intent with the new style was to better appeal to our target and tie into the iconography styling to create a continuity throughout the app. Along with these visual changes we began to determine touchpoints that needed updating to lighten the entire app experience.

Two examples: the first time a user tapped the print button they would receive a blocking modal that would tell them about the AR experience. Then after a few uses there was another blocking modal when they would tap the print button that would inform the user that they could use the Share Extension from within other apps. The problem in both cases is that the user was trying to do other things and were blocked from doing it. This is why we needed to reorder the information and flow of when we present learning material to our users. Each of these changes was mapped and flows were built to identify any areas that needed improvements.

(Note: I would love to take credit for the illustrations, but visual design was handled by the talented Melissa Smith LinkedIn.) Below shows how the visual design layer iterated on the design after the interaction/UX layer was defined (above).

What I have presented above are just a few of the many changes that we made. There are many more features and changes that could be called out, but this app is still in process. It's in its current state because, as with all software design, more new features are requested and maintenance and des/dev hardening of the design and code take a lower priority. To ensure that we can address these new features and the maintenance and updates we work in an Agile process. This way we can plan to roll out maintenance and updates alongside new features. We are currently in a cycle of iteration toward a flexible and extendable interface that meets the needs and appeals of our target audience.


Other Projects

Sprocket App Design

Sprocket App Design

UX Web Wireframes

UX Web Wireframes

UX Mobile Print App Design

UX Mobile Print App Design

UX Hinting

UX Hinting

Leave a Reply