Forward

We are a small team of talented creatives and developers, answering the question: “...tell us about your process or design principles.”

We are going to do something far more valuable: write about what has worked and what has not worked.

In the weeks ahead, KRUTSCH will post a series of bite-sized articles that encapsulate a decade of experience leading the life-cycle of product design and user experience (UX), across a variety of industries, with clients both large and small, including consumer and commercial projects.

This is Part 6: Prototype Main/Secondary Scenarios. Introductory post: UX Design Life-cycle, A Mini-Series.

Follow us on LinkedIn to see the next chapter in your feed.

A Story about a Problem

Know how spaghetti always seems to taste better on the second day? The reason is simple: the pasta absorbs a lot of the moisture and some of the sauce. When you re-heat it, it retains the flavor without being as "wet" as the day before.

Digital design and software works much the same way. The best apps happen after version 1.0 - you learn important lessons on the first try, which can be used starting from scratch on version 2.0. Great product design is about more than the user and their needs - you must also consider what can be reasonably built, supported and extended. Technology exploration is just as important as understanding the user and their goals/needs. Find the potholes, early on, before committing to a particular design direction.

Many years ago, I was working on web-based front-end for a storage area networking product. The company for which I was consulting was just starting to experiment with web-based interfaces for complex storage and network appliances (actually, so was the rest of the world in that era). The team was adamant in using pure HTML for their user interface. During this time, there was nothing like web sockets to support asynchronous updates of the interface from the embedded system – everything was polling-based. If you’ve ever built a complex user interface whose principal mechanism of updating is polling, you are aware of the myriad of problems that introduces.

Meanwhile, Java 1.0 was making inroads into the enterprise development space. After our experience with this initial project, we embarked on a new user interface for a much larger, more complex appliance – a system that required as many as a 100,000 set-able parameters, with a huge collection of attached systems and storage devices. The lessons we learned from “Junk Yard Dog” (team’s name for the first project) made it clear we had to move in a new direction. In a sense, Junk Yard Dog served as a prototype for the “real” version that followed.

At the end of the article, I’ll tell you what we ended up doing. Read on…

Don’t Start from Scratch

Prototyping is one of the most powerful steps in the design process. It melds together your research, flow, and visuals, giving a soul to your idea.

Built as a demo front-end, we often use Axure to mock-up designs into an interactive prototype, connecting the dots between hi-fidelity collaterals and building a narrative around the main success scenario. Using a story-driven walk-through sets a familiar framework for the user–a beginning, middle, and end. Narrative develops a task list the user can easily wrap the mind around, resulting in clearer communication and a more memorable design.

A prototype most closely matches the user experience outside of the real build because it incorporates simple interactions and responses, therefore eliminating the imagination and assumptions needed to connect the dots between static screens. The explicit model opens up capacity to catch missing details, feel unnatural workflows, or heavy handed decisions. When we begin building our prototype, we inevitably find new adjustments to complete the story of the main success scenario, a natural result of the newly provided design perspective.

Lessons Learned

When paired with hi-fidelity screens and CSS styling provided by Zeplin.io, a prototype helps clearly communicate a design to clients and developers. Because a prototype involves action and hi-fidelity screens are static, they inherently balance each other. However, if you are intentional about the focus of the prototype versus the high-fidelity screens, they can become a stronger pair.

For example, if your high-fidelity screens lean towards the representative, then make your prototype robust building out more interactive components as a method to anticipate questions and serve as a form of documentation. On the flip side, if your high-fidelity screens are thorough and detailed, your prototype could encompass a macro scale of interaction models without needing to build every actionable component.

A Planning Framework

Sometimes the client wants their own developers to quickly translate the design into their own working code, sometimes they want our own front-end development team to do that part for them. Either way, we have some tips and tricks.

1.Develop a prototype around the main success scenario.

We’ve discussed the importance of understanding the problem to develop the feature set and workflow, now you can take the main/secondary success scenarios and build a prototype encompassing the common use case.

We use a handful of tools to complete this step. Axure allows us to build interactive prototypes that look almost exactly like the real app without writing a single line of code. It’s our favorite tool for communicating interaction models that don’t translate through our hi-fidelity screens. We reach for Axure if our design is heavy on data entry or large elements of the workflow diverge based on a handful of user decisions.

AxureRP video conferencing UI early prototype

If we need a less detailed prototype, we use the prototype tools within Adobe XD. KRUTSCH uses XD to draw all of our hi-fidelity screens, so adding links and basic interactions on top of the designs is our favorite quick way to test the flow. Their prototyping tools allow you to build transitions from screen to screen by designating actions and triggers to different design elements like a button or a tab. Prototyping in XD is also our favorite way to present our design in narrative form to the client, fluidly walking through screen by screen.

Adobe XD prototype tools for a setup wizard

2.Critique your design against the 6 principles of usability.

After building your prototype, use the new perspective created by interaction and responses to consider how the 6 principles of usability are applied in your prototyped design.

Is your design functionally correct?

Does the system perform the functions the user needs? Read: Can they do the thing they need to do? If not, consider which elements hinder the user from completing the task and what needs to change. Iterations could range from small interface edits to large workflow changes that are better flushed out now rather than after building.

Is your design error tolerant?

Observe how well errors are prevented, detected, identified, or corrected. Allowing a user to make mistakes, apply corrections, and still complete the main success scenario keeps the emotional scale tipped towards a good user experience.

Is your design efficient to use? Easy to learn? Easy to remember?

Usability hinges on meeting user expectations. If completing a simple task feels cumbersome, either because it takes a long time to complete, is difficult to learn, or has too many steps to remember, there’s a disconnect between user expectations and execution.

Finally, is your design subjectively pleasing?

How does the audience feel about the content? Often this step has already been addressed through iterations of the high-fidelity screens, but as you incorporate interactive elements, it’s helpful to revisit. Evaluate the attention to aesthetic and detail, the layout, and if it your design appeals to your audience.

3.Record an annotated walk through of your prototype.

Even though presenting your design in prototype form makes it more memorable and understandable for the client, providing a controlled way to revisit the prototype furthers comprehension. Allow clients and developers to revisit portions of the prototype on their own time to fully review or soak in the design. While letting a user loose on an interactive link helps flush out concerns, what it lacks is context and explanation. An annotated recording provides that context.

4.Build out a working front-end based on your prototype.

In the old days, design was communicated with static images, plastered into a Word document or Adobe InDesign project. The developers took it from there, asking for images/logos to be sliced out, then built something that looked a little like the design. Gray is grey, right? And that custom font? Looks like Arial Narrow to me!

So, the next step is to build the working front-end based on your prototype. Once this is built, you’re ready for delivery and testing.

From here, we can go in one of two directions:

Interactive Prototype – Storyboards

Wireframes, a visual language and best-fit technology come together into a high-fidelity prototype built as an interactive front-end – we call these “Storyboards”. Using tools such as Adobe XD and Axure RP, we approximate the end-user experience with high-fidelity tools that allow you to view and understand a representative product experience. We use Axure to mock-up designs into an interactive prototype; coupled with high-fidelity design collaterals, produced with Adobe XD and hosted with Zeplin.io, the developers can very quickly translate designs into working code, using the CSS styling auto-generated by Zeplin.io.

Interactive Prototype – Reference Pages

Wireframes, a visual language and best-fit technology come together into a high-fidelity prototype built as a working front-end – we call these “Reference Pages” with demonstration, back-end code with canned data in a quick demo server that approximates a subset of functions of the full-featured, system or application.

In other words, rather than delivering static documents as a “style guide” for the design, great design provides working code that realizes the front-end user interface designed in the previous phases. We find this works better for us and for our clients, as it frees up a client’s development resources to focus on the product team’s core competency, rather than trying to stay up-to-date on the latest front-end technologies. It also eliminates the time-consuming and frustrating experience of trying to match the “style guide” to working code – the design team does this part for you.

Epilogue About A Problem

At the birth of what I like to call “The Consumer Internet”, most developers came from a rich client background – 16-bit Microsoft Windows, maybe OS/2, with the really cool kids working on commercial UNIX systems, like SPARCs, building user interfaces with X-windows and Motif.

The promise of web-based interfaces was a siren call no one could ignore; build once and run everywhere. Being able to embed a networking appliance’s user interface directly onto the device itself was a powerful idea.

All great, except that the early days of HTML were tough – no asynchronous data connections to a back-end service, along with a very low standard of quality on HTML components, presentation control, and layout. And then there were few options for client-side processing. There was really nothing to help you with HTML in those days; you had to write everything from scratch and each new browser iteration, along with the Netscape vs. Microsoft war, made reliable software a difficult achievement.

Along came Java 1.0. Their tag-line in those days was “Write Once, Run Everywhere”, which veterans of the experience learned really meant: “Write Once, Test Everywhere”. Still, you had an actual Canvas with which you had pixel level control; you had TCP sockets; you had a real language that actually ran on the client browser and could talk to code in the same language running server-side.

Having come from the Microsoft Windows world as a developer of desktop applications and device drivers, I set about adding what was missing from Java 1.0 – real UI components. After the follow-on product shipped, I wrote a case study on the project, published by Wrox Press. Memories…

https://www.amazon.com/Professional-Java-Custom-UI-Components/dp/1861003641

End Note

In our final post, Part 7, Deliver and Test the Design, we will bring everything together into a deployed and user validated system.