3, 2, 1… MedBridge.

surf's up

On May 5th, a Thursday, I heard back from the COO at MedBridge; my references had finally checked out, and their offer to join the team as their Product Design Manager was official. Just three days later, I found myself on a plane to Seattle and started work the very next day. To say the last month and a half has been an acclimation whirlwind would be the mother of understatements.

I’ve been somewhat of a lone wolf for the last eleven years, so it’s going to take me a while to wrap my head around what I can share that’s job specific, but I’ll figure all that out in due time. In the meantime, I’ll stick to posting a smorgasbord of product design thinking that’s been rattling around in my head.

As for MedBridge; what a great opportunity to do work that truly impacts people’s lives.
medbridge

The company started five years ago with a focus on creating high quality online courses for physical therapists and a HEP platform to improve patient outcomes. Since then, they’ve invested in a production studio, and the product line has expanded to support enterprise solutions, along with continuous shifts towards the latest advancements in the field. As a bootstrapped company, we’re as agile of a business as you’ll find in our industry, which allows us to nimbly pivot to address immediate needs—whether cementing our strengths or addressing our shortcomings.

While the design challenges are deep and wide—from overhauling the existing interaction model to standardizing our patterns and visual language to impacting the next wave of products from the moment they become a directive—it’s the exact challenge that I’ve been looking for. The last time I had a similar opportunity, my team made some serious waves in the financial industry with the Apex platform.

Surf’s up.

New Product Launch: IDB Project Mapping

idb project mapping

As we wrapped up the redesign of the IDB website, the team reached out to see if Analogous could assist with a redesign of their mapping tool, MapAmericas.

MapAmericas was used as a secondary mechanism for IDB employees in the field to input project data, with the additional benefit of geo-targeting projects and their corresponding results. The public-facing map featured every project across Latin America, introducing users to contextual information within a click. The concept was useful, but the interface segmented projects by country, had limited filtered views and the iconography overlapped and confused navigation. With a low adoption rate by all users, we had our work cut out for us.

As I wrote up a heuristic evaluation of the user experience, the design team researched mapping solutions out in the wild to review the variety of visual and experiential options in play. After a review of all our findings, we settled in on an overarching approach:

  1. The project map couldn’t exist as a destination point in the global navigation. While it had the potential of being be a smart, useful visualization of regional projects, it just didn’t fit the context of how users browse or might use it. We decided early on that the map needed to be accessed contextually from project, sector and country pages while providing avenues to return to the same templates when appropriate
  2. There’s a large amount of structured data found on project pages, but only structured in terms of the information design of the page, which allowed for great readability. We needed to free up data as explicit attributes for filtering purposes to navigate within the map interface.
  3. The overlap issue needed to be address, so we decided upon a clustering approach for projects living in nearby proximity at high-level views, and situations when exact geo-coordinates overlapped. We also created two tiers to the map—a pre-project view and a project/results view—which allowed for different behaviors specific to the context of the current task.

idb-maps-interaction-model

project filter wireframe

The resulting experience now allows users to view projects across all of Latin America, but subsets particular to persona interests. So an Education Minister in Bolivia can view all education projects in her country, and then broaden the results to show education project across the entire continent, allowing for better context. Similarly, data points such as total cost and phase were made available as filters, so that same user can now view projects in the approval phase that cost $50M-$100M. These were simple, yet powerful changes to the browse paradigm.

project view wireframe

Once the user drills down to a particular project view, results are now explicitly tied to the project, whereas previously, results lived within their own view with no discernible relationship to a project and/or a mechanism to get more project information. The cognitive result is an immediate processing of scale—how many outcomes were produced by a single initiative.

A decent amount of code tweaking remains in order to get the experience exactly right, but that should occur over the next few months. Once we have usage numbers, I’ll update this post.

RETHINKING: Planet Fitness Mobile App

planet-fitness-review

As a member of Planet Fitness for over seven years now, I have to admit that I had not once thought about the utility of a mobile app. My personal context scenario is focused on making it to the gym first and foremost, then jogging for 20 minutes, lifting free weights, cooling down with cardio and dragging myself home.

But that’s my routine when I’m casually hitting the gym; for those brief stretches when I’m serious, my routine becomes highly structured and dependent on there being low traffic on both machines and weights. That made me wonder—could a mobile app actually assist me attain my goals?

The Current State

When I imagine the potential for a gym app, I think of an experience that’s going to assist me with my fitness goals and the close context surrounding that primary set of scenarios. Planet Fitness doesn’t view their app in the same light, as the focus is centered around marketing their business to the general public, rather than assisting a member in their workout. 90% of the navigation leads to sections that could be the responsive output of a marketing site for a mobile devise.

planet-fitness-mobile-app

From a list of local gyms to member benefits to a PF store, the marketing navigation clouds potentially useful member interactions. Even the “Planet of Triumphs” section—one with an authentication requirement of members—is set up for members to help market the PF brand by sharing our workout stories. In a world of blogs and social media, why exactly would I or any other member waste time with this feature?

The responsive version of a well designed site should be able to cover these requirements, as potential members will most likely end up there via organic search. Why would a non-member download a branded mobile app? It should be built with highly specific goals of members in mind by presenting highly specific member features.

Highly Specific Member Features

Once you get past the marketing noise, there is one section geared towards supporting member workouts: the My Fitness area. The primary features include:

  • Scheduled Workouts: Set up a cardio or weight-lifting workout, choosing from a list of activities with times, effort levels, weight, number of reps & sets etc.
  • Log an Exercise: If not working from a predefined calendar workout, members can document their workouts
  • Start Your Exercise: Countdown based on in-the-moment choice of exercise and all its details
  • Sync a Wearable: Link a Fitbit or Jawbone fitness tracker to the details of an exercise
  • View Reports: Goal Progress, Day/Week/Month reporting (hours, exercises, calories burned)

Currently, I bring a workout calendar on two sheets of paper to the gym, covering each day of the week for two weeks, with weight, rep and set info. I have to admit, it’s somewhat annoying to walk around with it and even keep track of it at home. PF has made the process of creating a calendar with both cardio and weight specifics super easy:

planet-fitness-mobile-app2

PF could’ve stopped there, but they dug in deeper to support member needs, adding the ability to sync with a fitness tracker and review progress reports automatically generated by previous workouts. These features create closure around the context of workout goals—the reason we all drag ourselves to the gym in the first place.

planet-fitness-mobile-app3

This set of features should be the absolute primary purpose of the app. Aside from the rare need for finding a PF when on the road, members shouldn’t even see the corporate marketing content. That said, PF is missing out on supporting one huge scenario, core to the gym workout experience.

A Packed Gym

How many times have you shown up to the gym and had to wait for a treadmill or exercise bike or a series of free weight stations, throwing off your schedule? What about when you’re just getting back to the gym and simply want less people around as you try to reach a 15 minute mile? Could the mobile app present data to help with these scenarios? I think so.

What about a visualization on the main screen that presents the current capacity of the gym? 40%, 80% full, etc.? Since PF members use bar codes on a keychain to check-in as they enter the facility, the entry data is already captured. When signing up for the “Planet of Triumphs” feature on the current app, a member enters the same bar code ID# to be verified as an actual member, so the two systems already speak to one another.

In a perfect world, members would check in AND out with their cards, creating conclusive data re: time spent in facility. This would allow for explicit visualizations of traffic in the moment, and reporting of historical trends for, say, a Friday night or a specific holiday. Another option would be to tap into the phone’s GPS to approximate when the member leaves the gym, though that might have unintended consequences regarding privacy issues. It may even be worth it to PF to incentivize checkout behavior by members, but even without exit data, PF could present occupancy patterns based on check-ins at certain times of the day. With more than enough employees roving the floor, they could also manually input % of cardio and weight stations used on a half-hour basis.

These are the scenarios that matter. Get me in the door, no waiting, into my routine and help me accomplish my goals. Develop that app, strip away the noise and members of a $10 per month gym would gladly participate in the best type of marketing corporate could ask for: word of mouth.

Case Study: Ameritrade Apex Trading Platform

stock market

It would be safe to say that the internet was still in its fledgling state at the turn of the century. Aside from best of breed corporate domains, such as Amazon with collaborative filtering (and their standardization of the check-out interaction model) and Google blowing open the very definition of data mining, much of the web was relatively “dumb” in the way that it could deliver user information to databases and back to the presentation layer.

It was a much simpler time for interfaces across the board—(hash)tags weren’t used to expose similar concepts within and across domains, sites were designed with one delivery platform in mind (rather than the responsive nature of today) and dynamic, lightweight web apps as we know them today were hardly imaginable, let alone standardized in development terms.

Asynchronous displays of input/output just weren’t commonplace in the browser, so the vast majority of interactions between users and system data predominantly relied upon straight form submissions and page refreshes. While most users didn’t necessarily feel the impact of such limitations, industry domains that handled timely purchases of goods with limited inventory or changing prices felt an intrinsic need for progress.

When I joined Datek Online (2002), I imagined that these boundaries were ripe to be pushed, and I had good reason to believe so, as Datek had already revolutionized the financial industry through the release of its Streamer app, which made public a set of streaming data tools that only industry day traders had access to previously.

Internally, all streaming visualizations were handled in Java, which by definition provided asynchronous communication between the client-side & the back-end and was sturdy in doing so. The trade-off with Java, though, was that it limited the possibilities when customizing the UI to a wider set of user needs and interactions, not to mention aesthetics.

Since the the function of the Datek website was highly focused on three priorities—the execution of a trade, management of account information and marketing communication—the division of tasks between account and information on two platforms wasn’t changing anytime soon. Datek was wildly successful and management didn’t seem much of a need to rock the boat to innovate, in terms of platforms, in the day trading realm. A such, my initial day-to-day focus was centered on incremental behavioral updates to all apps within the Streamer Suite.

Shifting Focus & Opportunities

Three months after I joined, Ameritrade purchased Datek and my days became much more interesting. We had just shipped a new Streamer app called Command Center—a dashboard app that present multiple Streamer tasks in one interface and was a center-piece of the product suite while the merger was being discussed—but now everything was on hold as the two management teams negotiated the redundancies of both backend systems and product features.

Ameritrade, the brand, was a destination for people who didn’t know much about investing, let alone trading. Innovation wasn’t the focus, and the only “edgy” aspect of their brand was Stewart, a marketing constructed hipster created to represent Ameritrade while schooling a technically-challenged, older, potential client base on how to trade:

After six months of maintaining the product suites, we (Dan Saffer, Tom Alison and myself with the blessing of Larry Szczech, Datek’s SVP Product Strategy) made a proactive push to Ameritrade management to design a new trading platform, one that could support the day traders of Datek, the long-term investors of Ameritrade and most importantly, the unsupported sweet spot between the two—active traders.

While day traders brought in large commission-per-client ratio, the number of active traders (10-20 trades per month) dwarfed them and made them a much more valuable market segment. Everyone in management agreed; we needed a new platform, catering first and foremost to actives, yet designed in an extensible manner to support the continued focus on day trading and long-term investment.

Over the next two years, we did just that. We ran numerous usability studies to understand the major pain points for both client-bases and ran qualitative interviews to develop personas and document needs and experiential expectations.
design persona
We even flew in Cooper Design to run a workshop for my team and developers, getting them up to speed on Goal-Directed Design, while inviting both product managers and business analysts to sit in so we could all approach supporting clients using our service using a similar methodology.

All About The Interface

While were relatively hamstrung by available front-end technology, that didn’t stop us from pushing the browser as far as we could. We applied solid IxD axioms across the board, such as “no errors if they can be prevented,” by running javascript checks across fields prior to activating the submit buttons, forcing the user to get it right the first time through—whether the form was as innocuous as a support ticket or as important as a trade ticket. By doing so, we drastically cut down on time-to-task, which means everything when buying or selling in a time sensitive, price fluctuation market such as the financial industry.

deposits & withdrawals

As part of our overall interaction design philosophy, sections such as Deposits and Withdrawals were streamlined from multiple-page form submissions to a singular interface that exposed next options based on input decisions while setting the expectation for time-to-task. These conditional interfaces weren’t revolutionary by any means, but they weren’t industry standards either. Task completion improved as a result and user complaints reduced greatly—one of the overriding success metrics in the financial industry. These aren’t simply customers; these are clients.

Active traders need to move money, but they also need to open, close and change positions with an even greater attention to detail. Ancillary sections such as research were important, but the internet provided too many free opportunities for clients to research positions for us to focus on developing an industry leading research section. Instead, we felt that focusing our efforts on the context surrounding the trade ticket had the greatest ROI.

While we recognized that the holy grail of smartphones were a few years away from being a viable platform, we did recognize through research that traders needed to have as much flexibility as possible in the research ›› trade ›› confirmation process. We began to investigate the ways we could ensure that traders could always be one click away from moving on a position.

snapticket

What we came up with was Snapticket; a nifty little trade ticket with features that supported both primary and edge cases of our active trader clients:

  • The ticket in the footer area of the site, making it available at all times
  • The user could get live quotes in the header, or pull up their watchlist
  • The form applied the previously described dynamic error checks
  • A conditional design was implemented to shift the fields depending on the type of trade chosen—market trades are without a price field; trailing stops have multiple price, closing inputs, etc.
  • After submitting a trade, Snapticket collapsed to expose only the header w/ streaming quotes, allowing more room to engage above the fold
  • Most importantly, Snapticket could *snap* off of the window, and live as a separate, compact trade window in the user’s display. This empowered users to research online wherever they chose, yet still have immediate access to opening/closing positions

After one enters a position, an optimal task flow should take the user to a confirmation and a view of all/open orders. Well, that’s what we knew as traders ourselves, but neither legacy experiences behaved as such. We needed to make sure that every potential detail of the trade ›› confirmation ›› review positions scenario was supported.

Following a trade submission, we designed the flow so that the user was brought to the open order section of the account, where a confirmation—including day trading requirements such as a ticket number—was presented in a highly visible manner. We used this interface real estate throughout the site to communicate both synchronous and an asynchronous system messages. Again, not earth shattering today, but not many web services worked the interface as such to keep the user as informed in 2004)
open order

Overlooked by our competition, Open Orders are immensely important to traders across a number of important scenarios. A few that we tackled head on by making the interface the end-screen of the trading process were:

  • The most basic, and probably most important for all traders, is providing a clean display of whether or not new positions have actually been submitted.
  • When users trade after hours and on weekends they create a stack of open orders, that can’t officially enter the market until the next opening bell. Confirming their existence and providing a mechanism to make changes is important.
  • During more concise time periods—say, after submitting a limit order at a specific price near market price—a user will have a small window to make changes (price up or dow, cancel, replace, etc.). The interface needed to present all interaction affordances clearly and reduce time-to-task as much as possible.

In terms of usability, we remained consistent with our treatment of forms by only making submit buttons accessible once all necessary field were altered, thereby greatly reducing errors and improving time-to-task.

The Results

Leading up to the release, we knew we weren’t just launching a new experience; Barron’s Online Broker Review was waiting for us at the end of the road, and with public knowledge of merger flirtations in the air with a prior rating of 2.5 stars (a bottom of the online brokers rank) the pressure was mounting.

In the spring of ’05, I flew out to Palo Alto with David Whitmore, Director Strategy, to present the new platform experience to Theresa Carrey, who literally had the power to make or break a business. A quote from her eventual report:

“[…] Ameritrade, which swallowed up Bidwell & Co., Brokerage America, JB Oxford & Co. and Investex over the last year, earns four stars this year for its Apex offering. Ameritrade seriously overhauled the Website this past year, finally integrating the technology brought in with the 2002 Datek acquisition. The new site provides improved navigation, more tools and services, easier-to-find information, customization and better trading technology. […]”

Ameritrade moved into the top three of online brokers and a few months down the line, TD and Ameritrade merged.

NBC: Kinda, Sorta, Somewhat Getting Web 2.0

nbc

Back in February, NBC made a completely bonehead business move by making YouTube take down the hugely popular video short Lazy Sunday. My instant response was to fire off a salvo at NBC for being old media ogres (NBC: We Get Web 2.0… Sike!) and not working within the limitless parameters of the web to strike a business deal that suits their needs to protect their copyright, while allowing us to continue to enjoy their content when we want and how we want.

Well, today NBC announced that it’s embracing a few of the ideas I previously lobbed into play:

[…] “Under the deal, YouTube will create a separate channel for NBC video, so that visitors can easily pull up the half-dozen or more items that NBC plans to offer at any given time. It will be similar to channels that other companies, filmmakers and everyday users create. […] NBC and YouTube officials acknowledged the possibility that fans will reject the clips if they appear simply as promotions, but YouTube co-founder Chad Hurley said fans would likely embrace the video if it is compelling and not available anywhere else.” […]

Promotional video is somewhat of a start — I suppose you can’t expect major change from a major television network without them testing the water first. Give the experiment a few months; if uptake begins across numerous types of unbundled content, I’m sure they’ll be banging on YouTube’s door, attempting more creative ways to “let” people upload their content.

Affecting The Interface

In terms of the user experience, I only ask one thing of YouTube: please refrain from creating a pulldown of “channels” on your interface.

Asking people to assign ripped video to a “media channel” in the upload process makes sense:

  • It alerts you (YouTube) to content that needs to be assigned a “shared monetization flag” and
  • It automatically assigns network metadata to the video object to help people finding content they desire

Balancing the two-way participation of a user base with the business opportunities of old media is a difficult conversation to manage and execute, for if you transform your main interface too far towards the navigation of paid-for, primary channels, the entire participatory, community vibe will begin to deteriorate.

Remember, your brand is YouTube.

User Experience Team Blueprint

Building a successful UX team, with the right mix of roles, responsibilities, method, etc., isn’t an easy task. Depending on the type of the organization (internal product team or agency) and its executive leadership, UX can take on a range of responsibilities and methods to produce innovative work.

Here’s a visual outline that I tried to follow at Ameritrade when I was the UX lead managing a team of 12. The domain is a secure, authenticated trading platform, with unique opportunities for collaborative filtering, interface customization, sussinct client messaging and knowledge management.

ux-team

If I had to do it all over again, here are the top four things I would’ve done differently:

Align Sr. Designers with product verticals
Running a centralized team is difficult; product owners are constantly vying for resources and there isn’t deli ticket machine keeping folks in-line. While I did align designers to Apex, Amerivest, Streamer, etc. to keep consistency, I didn’t do a good enough job communicating outwards and managing the finality of those resources. I’ll take responsibility for that, but it would’ve helped if my management chain understood anything about design.

Reduce the emphasis on methodology
Due to the UX team sitting at the bottom of the development team, with no executive Design representation, and the lack of Design input in modeling requirement documents, I pushed to implement an IxD Goal-Directed Design methodology. While it successfully gave my designers the footing to have important conversations upstream when defining the product, it also created bottlenecks for the development team without proper attention. Figuring out how to iterate and ship more often would’ve been imperative.

Introduce blogging as a means for knowledge sharing
KM is such a terrible term. In essence, an outward facing blog with a solid search engine and a rich tag approach could’ve served as both a conversation point for speaking with clients and providing answers to non-client account related questions. Internally, we could’ve dropped our KM tool with central controls and replaced it with internal blogs for every employee.

Focus on research, behavior, information context, design and presentation
Editorial is a huge compliance issue within the financial industry, and collaboration with designers on interfaces was difficult to manage. I probably would’ve fought harder to keep the client-side team, or just focus on the core Design contributors.

Live and learn.

Anything But White Picket…

fence

What do you think of when you hear the word “fence?”

Unless you’re my friend Fleur (she’s a fan of the romantic sports), you probably lean towards the world of “things that stick in the ground and enclose other things” and you would be correct, as fences do just that; they enclose, divide, and protect areas and organisms for a variety of purposes.

If we can agree to such a broad definition, we should be able to agree that fences also define parameters of use, for if one can’t get past the fence, one can’t engage with anything outside (or inside) of its parameters.

Why am I fixated on the definition of a fence?

Well, a good deal of user experience design is centered around defining parameters; experiences that support specific goals rely on thoughtful crafting of usage parameters that work towards the needs of the user.

If that’s a vague concept, think about it in terms of designing a navigation system:

  • Does the top/down navigation live in a consistent pane in the interface?
  • If it’s located at the top of the screen, how does it behave?
  • Does it expand onRollover or onClick?
  • Does it display horizontally or vertically?
  • Does it employ hover states for greater affordance?
  • How does color and behavior reinforce the brand?
  • How is bottom/up exploration presented?

Before we get too granular within an imaginary interface, let’s step back outside for a moment and think about how we might design a fence in the real world.

  • The placement of a fence’s corner posts could be determined purely on property lines or through specific requirements based on the needs of the owner.
  • The height of the fence, and its types of rails or wires, could be designed based on security requirements, or based purely on style.

When design attributes are specified, parameters of use spring to life. An experience is established through the simple process of reducing the environment from ALL variables to MANY variables (with an eye on reaching FEW variables)

These specific choices define how, say, a fence can keep sheep grazing within a field; or one that protects property in the midst of urban renewal; or one that surrounds a house at the end of a cul-de-sac.

Solution choices determine specific outcomes.

User Centered Design

Interactive design is an iterative process, a constant remodeling based upon the objectives and desires of both the business and the user of the system in play. But moving from good design to great design requires an effort of reduction to reach an elegant solution, where less is more and the complex takes form in simplistic presentation.

Back to one of our fence examples: lets say sheep are now grazing behind an elegant, rustic, utilitarian, wire fence with wooden posts. You’ve designed the perfect experience to meet the particular needs of your customer, and she is ecstatic with the outcome.

Congratulations, but don’t pat yourself on the back for long. As people engage with interactive spaces, priorities and needs will shift on a dime.

Tom_Sawyer_8c_1972_issue_U.S._stamp

In this out-of-control metaphor, imagine your ecstatic customer now telling you that her sheep are going to be racing for cash on the property across a range of individual courses, which will drive numerous betting options for the local yokels. For good measure, you also catch wind that other farmers may be using the property for similar purposes in the near future, but will most likely use more exotic animals than sheep; animals much faster and larger, with different maintenance needs and subtle details pertaining to optimal footing.

Each farmer is now a stakeholder in how the property needs to function, yet they each hold a different degree of say in the decision making process.

With multiple priorities and agendas in play while designing for an optimal experience of the overall environment, your general approach to quality design (reduction and elegance) remains steady, but the outcomes that you’re driving to meet must be continuously and iteratively redefined and understood.

One thing is for certain: you can’t possibly satisfy each customer requirement with a singular understanding of a fence. The challenge that lies on the horizon: How might you broker the definition of appropriate usage parameters moving forward?

You’ll need to meet each customer’s explicit needs, but not by making “fences” too complicated or by over customizing the experience to any one client need in particular.

You’ll need to be innovative with your solutions by keeping an eye on the underlying viability, usability, and usefulness of the environment that you help create.

You’ll need to be discrete in your approach to both understand and frame the outcomes that your designs ultimately serve, or you’ll never reach them.

Tom Sawyer has nothing on the challenge you now face.

This is Design.