Mobile Print App Design

The screens above depict the original application design. It was riddled with user experience issues, but people often overlook awkward experiences when they need something and it sort of works. That wasn’t the case for this app. It had unusable patterns and often didn’t work. 

Knowing that we had much work ahead of us, the mobile UX team began the research phase. We reached out to the product owners and the previous developers to understand what they were aware of when they built the app. We probed for more information regarding what we could remove, fix, and add to the experience to make this application sing.

After discussing the ins and outs with the last team, we broke down the current app to understand the workflow and determine what was extraneous, wrong, or right. Not having a direct line to existing users, we relied on reviews of the app on the app stores (iOS and Android), Google searches, competitive research, and feedback from marketing they had heard from the field.

We set to work, pulling out the bits and pieces of UI/UX critique we could. One of the main priorities was knowing which toolset to use to build Mobile Print. Three times the development platform changed, which changed the types of interactions and micro-interactions we could use. Also, since our wireframes needed to reflect the toolkit (for internal reasons), we had to rebuild these wires multiple times—not the most productive workflow.

After exploring two frameworks, Bootstrap and Lexmark’s Perceptive, we finally settled on native apps. We chose a native app because it allowed us to utilize the system more efficiently. The user wouldn’t have to deal with the odd discrepancies that can come with web frameworks, and it would feel natural using a system language with which to use it the user was already familiar. When we finally locked down the intent to use native components, taking the various and scanty user input, we were able to move forward toward a more finalized design and direction. We iterated through section-specific workflows and determined the primary patterns the app would use.

Several questions we had to determine throughout the project was:

• • Why does a user need this app?
  • What is the process a new user should experience versus a preexisting user?
  • How do we let a new user understand what the app is for?
  • How do we hint at progress and intended direction?
  • What advantages can we give the user in native apps versus a web-only app?

There are many more questions to explore, and we did, but the point is: understanding UX is about asking the right questions.

Since we chose native apps and knew we would be able to tap into the system better, we wanted to install extensions/plug-ins, allowing the user to scan and print from the cloud from within any app on their phone. The user would now be able to access OS extensions (which both iOS and Android have), but they would need to enable these extensions and allow them to access the system.

• • How do we inform the user they will need to enable the extension?
  • How do we tell them of the benefit?
  • Is a wizard the proper flow to help them accomplish this task?
  • How do we help them to remember it later?

Onboarding can be tricky. Done wrong, the user feels as though they have been swiping forever. We decided to test a few simple screens.

Once we had the ideas mapped out better, we worked through each onboarding workflow, discussing the possibilities and limitations with the dev team and the product owner. Can we add animation to the onboarding? Can we have an interaction trigger the animation? We’d seen it done, but could our team do it?

After testing the onboarding and several other workflows, we began to build rapid prototypes to try the experience to iterate to an MVP design that was consistent with user expectations and would help the user understand what they needed.

We worked out most of the problem areas for an MVP through iteration and user testing. If I needed to clarify a specific flow, I would create a rapid prototype and refine it to a more fully functioning prototype. While not fail-proof, the rapid prototypes were essential to understanding the pitfalls a user might encounter. It helped us clean up the user-facing language, slim the flows, and refine the interface.

I believe that as a User Experience designer, all designs should be rapidly prototyped. I should be experiencing the designs I create and not just creating wireframes and wireflows, which are lifeless. When I experience design, I better understand the needs and problems a user will have. Challenges and successes make more sense than when looking at static designs.

In addition to the designs above, we developed storyboards (these are Beat Boards) to explain and experience a possible growth function for the application. Our goal was for the user to accomplish their tasks and projects quicker and more flexibly. The theory was that if the printer could “sense” the user was near and ping them to release their print, they wouldn’t have to use the printer interface or return to their desk. The user could release the prints with a simple swipe on their phone. This concept allowed us to leverage the mobile phone to provide an overall smoother and faster experience.

We explored several user scenarios and mapped them out in a beat board fashion to visualize the user within their environment. This visualization helps show why the function or flow works or fails.

Beat boards are similar to rapid prototypes; they provide valuable insights into the scenarios—visually. Usually, a manager or product owner can’t envision our concepts with written scenarios alone. Creating rapid beat boards helps provide a better picture. It also can help with the workflow and function requirements.

Below is a hinting animation to enable extensions; I storyboarded it but didn’t create the final animation. I devised this hint because the newly installed extensions were disabled by default. I suggested this direction to aid the user in understanding how to enable the iOS extension. The original vision was: that the user would click the “Set up Sharing” button (image two, first row), and then the animation would begin playing. (Note, the original animation played at a slightly slower rate. This animation was an example gif. Further note: Lexmark never implemented the animation.)

As a User Experience designer and illustrator, I believe that all UX is about storytelling. Our goal is to help the user be the hero of their story and guide them through their immediate needs without stumbling. While no application or user experience is perfect, we can help the user overcome inconsistencies and oddities by merely helping them be heroic in their day to day. My goal with this app was to make it the best way for users to interact with their printer and cloud printing to feel they had succeeded in their task. If we create one less difficult task in their day, we have designed it well.