Designing a new web app

How a new interface for enterprise cloud recovery started big and ended up very focused.

Project layers discussed below:

• Introduction and goals
• Scope of what I should do
• Preliminary sketching
• Principles, standards, and targets
• Wireframes / mockups / prototypes
• Flows
• Customer and non-customer validation
• High fidelity
• Adapting to new information and goals
• Adapting to team changes and workflow
• Refining experiences
• Transition strategy

These layers are in rough chronological order but are only meant to organize this walkthrough, grouping non-linear activities in a linear document.

Also concerning the inline samples: these are the tip of the iceberg as far as design material I’d have to choose from and should not be considered exhaustive display of the whole interface design. I only show a few key screens to let you get a rough feel for the sort of things I was trying at the time.

Introduction and goals

I was brought in to the project as the engineering department’s sole designer, to turn their existing web application into a new “next generation” web app capable of growing in all the market directions they expected to go. They wanted to do away with their current solution entirely in favor of one that would make more sense for and be more attractive to their customers. Their product is cloud-based backup and recovery for IT companies to provide peace of mind for their business clients.

At this stage I was doing a lot of whiteboard-heavy discussions with the product managers and stakeholders, trying to hone in on what was already known by the company about their product, their customers, and future features planned so far. I was also looking for what issues could be tackled immediately vs ones that could require long term efforts.

Scope of what I should do

Through these discussions I found that they had customer contact mainly through Sales and Support, had one persona based off of customer interviews, and some fragmentation of known customer experiences and the mental models used to build/explain them. The gaps I saw to be filled were in developing various guides in which I could get collective buy-ins to move toward a new and better design. These guides would define: Terminology, Look and Feel, Personas for Engineering, Persona Motivation Flows, full Experience Flows, and potential Database Schema. I worked on these while I sketched out some rudimentary options for information display styles in a digital white boarding tool.

Preliminary sketching

Using a mixture of text outlines, wall whiteboards, handheld whiteboards, and a sort of digital whiteboard tool called Balsamiq I made several low-fidelity interface schemes for stakeholders to give me their opinions on what basic information they thought would be most useful and digestible to their customers. I put these into “happy path” screen flows.

(email to drill down flows for one customer type)

(hierarchy displays)

Principles, standards, and targets

While making sketches, I planned what sorts of design anchors I wanted the team(s) to use going forward.

(terminology tree, also exported to wiki as a text outline)

(look and feel tree, also exported to wiki as a text outline)

(persona profiles for development team, not marketing team)

(database schema proposals to tie together support for next gen terminology, advanced features, and simplified user experience)

Wireframes / mockups / prototypes

The first goals presented to me were concerning market expansion and flexibility, putting a whole lot more functionality in a more powerful interface with less screens. I also found that without a set of fleshed out mockups and style guide, my low fidelity wireframes were reaching the end of their utility to communicate what I needed to with stakeholders.

I began splitting the difference with partial fidelity wireframe screen experiments, often with clickable flows I created in Keynote. I also prototyped some animation methods using Hype, which exports html5/css3 pages that play in-browser.

Flows

User flows were becoming more important to the overall experience and they needed to be agreed upon between stakeholders — so I mapped them out through a series of conversations and built upon that for ways to simplify. I created potential new branches to shorten the paths with motivation flows to make customer assumptions visible.

Customer and non-customer validation

I wanted to expand upon the customer interaction that was happening in several ways, since I didn’t want to design or build too far in any direction without the ability to vet things beyond Doyenz employees. I like to gather data from two categories, since they produce very different information with interesting gaps:

• User-aware studies — focus groups, usability testing
• User-unaware studies — a/b tests, navigation and mouse tracking

The first method I got buy-in for was hosting a focus group. I collected a small group of non-customers, requested a group of customers, and put together an itinerary for a session. Unfortunately each time I was close to picking a date, stakeholders advised me to postpone while the core service was getting updated or subscriptions were being negotiated.

Ready but delayed, I investigated what would need to happen technically to enable the user-unaware studies. As the product’s architecture and potential foundation changed, I updated those plans for when more developer time could be devoted to the next gen version.

High fidelity

During those delays I did have some informal conversations with people on either side of the customer fence, gaining some valuable insight along the way, which informed my designs. I also decided to make the jump to mockup quality for all my screen experiments.

Adapting to new information and goals

As I was learning more about preferred usage patterns from these professionals, their market focus was suddenly re-focused in another direction. This new market was going to have a different sales model and primary management software, so their interaction would be different. I adapted my interface designs to optimize for this, away from maximizing flexibility for a varied audience of different skill levels and toward two flavors of a similar skill set.

With the insight I’d gained and the new goals I was presented, I decided that things like detailed summaries and exhaustive reporting were not going to be as useful anymore to either market. The main experiences of interest were now about only alerting customers about problems, giving them the quickest path to fix them, and allowing them to “set and forget” quickly.

At this time I was also assigned to a different product manager who wanted to quickly turn this new market into a spin off project with new underlying technology, getting it out the door in a tighter timeline. I was teamed with a dedicated developer and was happy to be slicing my long term designs into chunks attainable through sprints. I started turning my style guide and mockups into CSS, creating the interface objects, widgets, and layouts we’d be needing within the chosen framework.

Adapting to team changes and priorities

Part way through this, my team changed along with several business goals. The new interface was postponed and we were asked to focus on a number of other projects that still leveraged the old web app. I was then mainly doing design and implementation for those efforts, while refining the eventual design between them.

Refining experiences

Further refinement came from expanded discussions with new and previously unavailable stakeholders, changing customer feedback, and new market trends. I focused more on simplifying the priority functions and considering touch devices with more certainty.

Transition strategy

While getting to know the innards and patterns of the old web app, I discovered another strategy for transitioning customers from old to new. It mainly involved shrinking the web app a certain amount every sprint, and placing some new core functionality into the API. I took this plan and expanded the explanation to include the other UX activities that would contribute to the plan’s success.

That unfortunately is where my involvement ends. The company went through some untimely challenges that prevented us from completing this and other projects.

Originally published at www.ihoby.com on May 7, 2016.