For 20 years, I’ve been pining for the industry to consider interactive design as something far more than pushed pixels, first & foremost. Looks like even industrial design is becoming a second class citizen to the experience of things.
[…] Think of massively linked datasets on user behavior, which allow your phone to guess what you want to do, when you want to do. Think of digital assistants able to parse even the vaguest commands and parcel out all the sub tasks to the right app—”Hey, can you make a reservation at one of my favorite restaurants this Friday, and make sure that my best friends get the invite too?”
These things are invisible. We can’t hold them, and the sense in which they are “designed” will be vastly different from any piece of hardware we have today, or even any piece of software, no matter how beautiful. […] The next great design monuments won’t be easily displayed in a design museum. They’ll instead be the systems and incentives that dissolve all the messiness of our whims into that simple bit of feedback that happens when your smartphone listens to whatever convoluted thing you’re asking about, and simply says, “Okay.”
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.
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.
In the midst of a post-job interview / project downtime stretch this past March, I decided to scratch an itch I’ve had for a while and test the overall experience of driving for Uber. I’ve always wondered about the product experience from a driver’s perspective, and hey, why not make a few bucks while finding out?
I was steeled for a lengthy process, but signing up was rather simplistic; I only had to upload images of my active insurance, registration and drivers license. As I waited to clear the Uber background check I detailed my Ford Escape, upped my mobile data plan, and within just a few days, I was on the road.
Since Uber launched a number of years back, I’ve had a rather conflicted perspective on the entire ride-sharing industry, unsure as to whether I found their disruption innovation to be of actual value to workers or an example of a tech firm taking advantage of an entire ecosystem of labor. The reality I experienced over three straight weeks of 30+ hours of driving was something a bit more towards the latter.
Context Is King
Heading into this experiment, I realized there was going to be a drastic difference between driving within a saturated area such as New York City and my current home town of Greensboro, NC—from fare prices to Uber’s percentage cut to the degree of fare consistency, location makes a difference. So before I jump into my findings, let me provide some context regarding the environment I found myself navigating:
As a sprawling home to 270,000 people, Greensboro has a small downtown footprint—three blocks wide by six blocks long—surrounded by traditional suburbia and urban sprawl that extends out to a good number of office parks, gated communities and strip malls. It can take upwards of 30 minutes to drive from the northernmost to southernmost tip of its borders.
There’s one sporadically busy bus and train station downtown, and one small international airport about 20 minutes away.
Five sprawling college campuses call Greensboro home, along with a host of technical and trade schools. The student population alone is close to 35,000.
Nearby major cities include High Point (20 mins), Winston-Salem (30 mins), Raleigh-Durham (1 hr) and Charlotte (1.5 hrs)
Sundays and Mondays are practically dead, with not many options for food or drink available after 9pm, if establishments are open at all.
Fares and Surge
As one might imagine, catching fares in such a vast physical space with limited activity can be a challenge. Aside from very particular hours of the day—from 8 to 9:30am and 5 to 6:30pm on weekdays, and from 10pm to 2am from Thursday through Saturday—consistency is severely lacking. The job becomes a crap shoot with so many neighborhoods and businesses to cover in guessing where fares will pop up, especially while competing with an unknown number of fellow Uber drivers chasing the same rabbit.
Whereas large cities have relatively consistent Surge™ zones over populated areas of both work and living activity, Greensboro drivers don’t enjoy such a luxury. The most recognizable Surge zone is found downtown, often later in the evening as people make their way home from clubs and restaurants. Every now and then a random Surge zone appears on the map, but it’s often during down times, and it seems to be literally based on a couple of fares vying for one or even zero drivers in the area. Uber markets Surge to the public as a feature designed to get more drivers on the road to service passengers with high wait times, but in reality, by the time an active driver (let alone someone at home or in a coffee shop) makes it across town to attempt to tap into an announced Surge it has already passed.
From a driver perspective in larger cities, Surge pricing is a nice-to-have in order to augment consistent fare activity in larger cities. In locations such as Greensboro, Surge is a core necessity in bringing hourly rates to even a semi-respectable level, much closer to how a waiter making $2.50 per hr relies on tips to pay the bills.
When expanding into cities with low population density, high degrees of urban sprawl and a limited adoption of technology, it’s abundantly clear to me that Uber can’t just roll out the same program.
(Not) Sharing The Load
In January, Uber reduced the passenger rate in the Piedmont-Triad area by 20%. This price point reduction was rolled out to help grow the Uber passenger base, which is an understandable approach and one that would help drivers as well. The problem is that while Uber passed such a significant savings to passengers, they didn’t supplement the loss of income for drivers, as they kept their 25% overall take of driver earnings in effect.
Essentially, drivers in non-dense, growth markets are paying for Uber to expand their market, while the company keeps raking in the profits. If I were making solid money over those three weeks, I wouldn’t care much. So how was my pay? Here’s the breakdown:
Week One: 32.18 hours driving
25% Uber fee: ($142.80)
Gas & carwash: ($100) Total Income: $328.39 [$10.19 per hour]
Week Two: 30.92 hours driving
25% Uber fee: ($99.96)
Gas & carwash: ($100) Total Income: $199.95 [$6.47 per hour]
Week Three: 36.12 hours driving
25% Uber fee: ($140.92)
Gas & carwash: ($100) Total Income: $322.87 [$8.94 per hour]
Over the course of three weeks, working an average of 33.07 hours, I only made $8.58 per hour—not to mention the cost of taxes (10%) or the depreciation of my vehicle by putting an average of 1,000 miles per week. Unless I had zero other options to earn, why would I continue driving for Uber when in order to meet a living wage threshold in my area, I’d have to make at least $10.53 per hour?
The Longtail Of Drivers
Aside from drivers who have limited options to earn income, you have to wonder why anyone would commit to a full-time schedule picking up fares. Maybe my three weeks doesn’t accurately represent the opportunities of all drivers. Or maybe Uber didn’t design their service with full-time drivers in mind, and are shifting the focus away from their more traditional employees.
Uber portrays their archetypical driver in the following commercial:
The service is framed as beneficial to each person’s life based on the flexibility that Uber provides; not based on the amount they can make while driving. Uber has tapped into a workforce version of what Chris Anderson coined The Long Tail well over a decade ago.
In an online retail environment, The Long Tail represents product that might never see the light of day on a brick & mortar shelf. Think Amazon, and the millions of books available to you, regardless of the size of the print run. The web makes such product availability possible, as the concept of physical shelves is replaced by a singular coded product template that represents each and every book in stock.
Most importantly, when you stack the long tail on end, overall sales will equal or surpass the big ticket items; the “popular” head of the tail. While such a static results proposition doesn’t match the actual results of part-time vs. full-time Uber driver productivity, it doesn’t need to, as new long-tail drivers are constantly replacing the attrition of fellow moonlighters.
Uber’s business model is steeped in the surface notion that the tail is what matters; that people moonlight with Uber to make ends meet, so the traditional definition of an “employee”—and every labor expectation that comes with it—shouldn’t apply. And with the constant turnover that occurs in the < 10 hours per week driver class, Uber benefits by having a turnstile of new drivers willing to forgo basic labor rights, such as a minimum wage or benefits. This becomes the overarching approach to classifying Uber drivers, as they redirect attention to the moonlighters while full-time drivers aren't treated any differently.
[…] the much-touted majority of Uber drivers working very few hours per week are performing far less than the majority of the work. And the seemingly marginal group of full-time drivers actually are doing about half the work, far more than those driving the fewest hours. The precise numbers are sensitive to how one subdivides the drivers (using 1-10, 11-29, 30-44, and 45+ hours per week might look worse for Uber) and to the distribution within each bracket, but the basic point is robust.
Uber has created a worker ecosystem that benefits only those who need to occasionally earn, and doesn’t reward those who invest the most amount of time catching fares.
As a driver, there are a few interaction model changes that would impact my ability to make more money:
Expose predictive patterns – I’m not sure what percentage of riders use Uber in the same way either daily or weekly, but expose pick-up patterns to allow drivers to cruise areas well prior to Surge zones being presented. It may not matter in a huge city, but it would make a difference across all of the mid-sized cities in play.
Allow for tipping – Lyft already has tipping in play. I can’t tell you how many of my riders wanted to hook me up, but didn’t have cash on hand. Uber, if you’re not going to cut your 25% take, then make it easier for drivers to make a living.
That’s Damien Newman’s process of design. It may be crude, but it’s absolutely clear: the unknown heading into Research leads to the sparks of Ideation and culminates with the clarity and details of Design.
While being a universal axiom of both art and design—we all start in a fog as we attempt to narrow down to any clear form of visual or behavioral expression—what it doesn’t begin to touch upon are the moving parts found within the various methods that we must employ in order to participate within & contribute to a product development team.
I’ve been thinking about the evolution of my own creative method for a while now, as I’ve moved from personal expression to participating within and creating Design methodologies for both start-up & large organizations over a 20+ year-long career. So if you’re inclined to join me on this journey, be warned up-front: I’m going to start at the beginning and that goes way back.
Being an Artist
Before art school, I was a “drawer”—I’d go directly to pad with either pencil or rapidograph, often to remove cognitive processing altogether with blind contour drawings; my portfolio for art school was filled with them. The subject matter was mine to define, and I finished when I felt it was complete.
As I became more focused on the craft of illustration, I’d spend time ideating through the subject matter and prepping for the pen to paper in a number of ways—from taking photographs to sketching to cutting images out of magazines. If the illustration was for a class or a client, I’d invest as much time conceptualizing as would illustrating. This was the moment where my creative process evolved to include other people’s input for the first time.
Undergrad Advertising Design
My illustration focus at Crouse College quickly took a turn to advertising design, and with it a whole new set of challenges were introduced.
We discussed faux business objectives and campaign parameters in studio, and then sequestered ourselves to research, sketch and write copy. Relatively quickly, we’d return to class to present three concepts and receive a full-on design critique. Repeat, narrow down, complete. It may not sound like much at first, but being able to clearly pitch an idea, and then take criticism as constructive rather than negative, is almost as important as the ideation process itself.
Towards the end of my undergrad career, we began to collaborate with Newhouse copy writers, prepping us for the machinations of a real world creative team (I never pursued a traditional print & tv agency career). With no developers in the mix, this was a commercial design process, but one with greater degrees of complexities than illustration when it came to client input and iterations towards sign-off.
Directly after undergraduate, I spent my days designing CD-rom games after landing an internship at a design and production studio. The biggest contrast between then and now is that the notion of a downloadable patch or a version update simply didn’t exist. We were pre-web, so production houses didn’t staff and operate with the concern that developers constantly needed to be busy shipping product.
We began each project with a single, clear goal of burning a gold disk to take to a reproduction house on a specific date far off in the future. There was no iterative approach, no outcome to meet other than great reviews. We were 100% big bang.
Our creative process looked something like the following:
the writer develops a linear script
our team translated it into a non-linear, node-based script and made material changes as necessary
we storyboarded key frames and the interaction model
environment, sprites, and animations were identified
we then focused on final animations and artwork
As we made progress, the development team would ramp up their technical requirements and begin to shape their architecture; new details from the design team would impact their approach and they’d iterate accordingly. We would intensely collaborate, and the engineers prototyped both good and throwaway code. The process felt much more like collaboration found in film production than a web-based product.
Our reputations and compensation were dependent on releasing a finished product that actually found a market. We were 100% outcome based. Our distribution partner placed the product into the limited sales channels that existed prior to the robust long-tail of online retail, so we only had one chance to make a impression with both reviewers and customers.
If you ever see me twitch when an MVP is mentioned, that’s simply muscle memory from a product age long ago.
As east coast game production dried up, I transitioned to the web and cut my teeth within a couple of agencies; first as an interactive art director, and then as an information architect.
The creative process as an IAD was somewhat similar to undergrad—though pitches and critiques absolutely stepped up in intensity—and my experience in the gaming world prepped me for collaborating with a development team. Similar to gaming, online campaigns, websites, screensavers, etc. were a first impression pursuit— the notion of iterative updates was nascent in adoption.
As an IA, the work was much more focused on defining and then translating requirements into sketches, schemas, taxonomies, etc., but the ideation, presentation and executing processes were highly similar. The “new” element was the explicit notion of documenting user requirements as a point in the process. Functional requirements (user + business + technical) and strategy docs were the foundation for how we ideated solutions
= = = = =
< An Aside of Thoughts About Agency Life >
In the late nineties, when agencies were in the luxurious position to offer soup to nuts services, development teams didn’t have the agency to drive innovation as they enjoy today. Engineers were explicitly beholden to the client initiative, which didn’t align with launching experiments in-market due to the economics of the time and our collective understanding of the medium. Aside from collaboration around information architecture and design deliverables, engineering innovation was boxed within the core vision of the client, the strategy team’s position paper, and the design process.
Only the best of the best shops could honestly tout a record of pushing the boundaries of the medium with their work, and those shops were doing it with top notch collaboration and deep client partnerships. My time spent time at Organic exemplified such a business environment. These days, firms such as IDEO and frog have diversified with such quality and talent that they can demand the proper price to bring innovation to the table.
Conversely, smaller studios and boutiques have to be creative in how they sell themselves, otherwise they fall into a game of pitching beyond their capabilities. Clients may invest upfront to bring in a shop to provide specific thinking—forever the value of an external team—but businesses are leaning more and more on newly formed in-house product design teams to take on the majority of design thinking and execution capabilities.
While full lifecycle innovation is difficult in the agency space, outside consulting can fosterinnovation within this climate through ideation around notions such as brand experience development, ideation workshopping, and targeted behavioral and industrial design approaches. The challenge ahead for studios will be to move to a business model and underlying IP creation method that can adapt to the shifting world around them to redefine a. what innovation looks like and b. how an external team can provide it with clear and understandable ROI.
</ An Aside of Thoughts About Agency Life >
= = = = =
Engineering Leading; Engineering Billing
After stopping by for the tail-end of a startup experience (Tripod)—where method wasn’t much of a focus—I experienced working within a development-centric organization for the first time. As the Chief Information Architect of a consultancy spun off from a global IT shop, my charge was rather specific—to develop an information architecture practice within a creative team methodology that was flexible and scalable, and could roll out across all of our domestic offices.
Aside from forming strong allies with creative directors in each office—which became a difficult line to toe as they (understandably) felt comfortable running their own teams as they saw fit—the largest problem I faced was that ancillary teams (business analysts and developers, in particular) operated in an object-oriented, UML methodology where “user needs” was a poorly tracktable notion. Engagements began with client-focused JAD meetings that lasted days, sometimes weeks, and stacks of business and development documentation were produced for the project’s build.
I’m sure good thinking came out of those sessions, but it looked like ceremony for ceremony’s sake, especially as I came to understand that the majority of the work turned out to be websites with less than innovative aspirations, degrees of difficulty, or complex user needs. The scale and complexity of the challenge ahead of me was clear.
My primary goal out of the gate was to figure out how to get tech management on-board with user-centered design in the midst of client engagements kicking-off across the country. After rounds of discussions outside and within the context of active projects, I realized that IA had to own as much of the actor-driven UML documentation as possible or we would have no leg to stand on when delivering user-centered experiences to our clients.
While we were successful in taking ownership of certain aspects of the process—from key insertion points to deliverables—we just couldn’t nudge the overall methodology, which was a nightmare.
As our team attempted deeper degrees of change, our efforts quickly became a game of tug of war with management. This was the time we lived in (2001)—many of my design peers were experiencing similar struggles with development-centric organizations across the industry. The attempt to convince an entrenched executive technology staff that Design needed to have a seat upstream to inform development of what users needed, even with wins in tow, quickly devolved into a street fight.
Technical documentation = billable hours.
Looking back, the daily struggle for optimizing how Design fit into a potential innovative space created a blind spot for me to the possibilities of more collaborative opportunities. Maybe we could’ve figured out a pre-Lean UX / Agile approach, or complimented JAD with design activities. At the end of the day, I believe our intent was good—we wanted to build trust and deliver highly useful work—but we were too early to a philosophical problem that not enough people had yet encountered with clarity.
Over the next five years, I unceremoniously took on the role of being a change agent for Design, which unbeknownst to me at the time was as important to me as producing innovative work.
Product Design Where No One Considered Product As A Thing
As with my previous stop, it took results to seal the deal of institutional change.
Over the three years that I was in the employ of Datek / Ameritrade, Design moved from a position of downstream application to an upstream presence that impacted every aspect of the brand made available to the public. But to describe our methodology in a simple sentence just isn’t possible.
Both firms knew they were providing a service to their clients, but at the highest positions internally the authenticated space simply wasn’t perceived as what we commonly understand Product to be today. It was treated as the “flip side” of the marketing layer; the logged-in space that pushed traffic to pages or applications that triggered trading charges.
When Ameritrade bought Datek, the Business provided Development with direction that prioritized desired projects and Marketing was accustomed to providing all visual assets when applicable. After successfully navigating the domain for a few years, I positioned myself to staff a UX Design team to design a new trading platform after a deep, collaborative analysis of user needs.
The Active trader platform, Apex, was born and we had real, innovative work to do.
While our process was more waterfall than not, the front-end engineers were in our group (UX) and they were constantly prototyping our designs for user testing and skeleton development. Looking back, I considered us to be the D in an early EPD team, with the evolutionary notion of Product still stuck between the business analyst and project management roles.
Without this team approach, waterfall would’ve stopped development in their tracks, but our collaboration was top-notch. At any given time we had 10-15 active projects prior to the era of collaborative platforms (e.g. Basecamp). Our productivity would’ve grounded to a halt if it weren’t for how well our internal processes adapted to produce both on-time and above expectations.
We pushed forward within a Goal-Directed Design framework to innovate an experience designed specifically to support scenarios particular to our active trading clients. The opportunity to apply human-centered design thinking in a broader manner was limited by our place at the bottom of the engineering reporting structure.
For much of the past ten years, I operated a design shop that would flex in size depending on the opportunities in front of me. Similarly, the particular engagements I landed (and the domains behind them) greatly influenced the process and methods available for me to employ.
Example: Over two years, I engaged with a huge player in the media industry, Scripps Networks, building out my FT distributed team to six to completely re-imagine how they published to their online brands, which received millions of views per day.
Our design process with the internal project management and development teams was steeped in an early-stage (2007) Agile method with a blend of GDD, as we needed to understand and meet the needs of a cross section of internal users—editors, designers, media buyers and product management. It also had the challenging objective to be generic enough to be used by teams across multiple brands publishing to differing front-end templates.
After beginning the gig with a round of research to understand the role-based needs of the product, we kicked off the work by identifying key scenarios to pursue, beginning with the “publish and edit article” scenario.
My team, located across the US and the UK, would hold our own daily scrum each morning prior to joining in for the client scrum in the afternoon. We (myself, the PM and dev lead) discussed where we were in designing for the scenario in play, and what we’d complete over the following three week period. We would sketch, review, and specify, and then work with dev.
As this was an internal application for a high-profile brand, a certain degree of politics limited our iterative learning capabilities. If I were in-house, I probably would’ve engaged harder to make such learning a reality. As a consultant, I did the best I could delivering what we had promised to deliver.
The lesson from that experience is that methodology decisions matter, as method—how we choose to collaborate, research, iterate, prioritize, be agile, etc.—directly impacts the creation of a useful experience for actual human beings.
Design Thinking With A Side Of Innovation?
We began with a process of design, which seems ridiculously simple looking back across this essay, and here I am, fully taking in how much I’ve had to adapt to my environment over the years to survive, let alone thrive.
While I’ve operated in a manner to nudge others to shift their perspective on how to work with Design over the past 20 years, the evolution of my understanding of Design, and how it fits across industries, form factors, and customer types has immensely changed as well.
Just as business leaders shift their operational tactics as the world evolves around them, we designers must also evolve in order to produce quality work in an ever-shifting technological environment with varying expectations from users in market to business partners alike.
My d/Design interests have never led me to submitting entries in an awards chase. I don’t care about accolades; I care about results. My interests lay squarely in the realm of leading a team of practitioners, contributing to an excellent product vision, understanding human needs, innovating solutions, and executing designs to the point of wild success.
What method gets me there is still yet to be defined… as it should be.
What do you think of when you hear the word “fence” spoken aloud?
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 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 ALLvariables 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.
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.