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 nuanced.
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.
Uber portrays their archetypical driver in the following commercial:
Uber is framed as beneficial to each person’s life based on the flexibility 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.
While the experience didn’t leave a great taste in my mouth, as a design thinker, I’m not interested in litigating Uber into traditional labor-law compliance. I’m much more interested in exploring the possibilities in the interface & business model that can help drivers while continuing to earn revenue for Uber. And yes, during my time delivering drunks to their homes in the middle of the night, these scenarios were exactly what I was considering.
In Part II, I’ll present interface and business model suggestions to improve both the life and behavioral expectations of the Uber driver.
I guess I didn’t break anything while recording our first pod together as Stephen invited me back to chop up the legendary career of Phife Dawg, the appearance of Bernie Sanders’ fine, feathered friend, the gross nature of our home state’s legislature, Coach K & Lebron’s losing examples of leadership and the future of the hollywood narrative.
Last week, on a beautiful North Carolina Sunday afternoon, I ventured out to the edge of Greensboro’s vast footprint to pick up my good friend, Stephen Charles. I had reached out a few weeks earlier to gauge his interest in me sitting in on his podcast, “Proof of My Existence,” and he seemed happy to oblige. After he ushered me into the house to introduce me to his latest gadget—he’s by far the tech geek of the two of us—we made our way back to my house downtown where we had planned to record episode #14.
Stephen is a renaissance man, with interests as vast as photography, comic narrative, brand development and fashion design, so I wasn’t surprised when I first heard that he was podcasting. His demeanor fits the sonic form, as he presents himself with a calm, measured and direct tone, which allows him to move easily from one subject to the next with a NPR’ish production vibe…and that’s exactly why I thought we’d be an interesting mix (you can figure out what that means for yourself when you listen to the show).
Enough with the intro; here’s Stephen Charles’ Proof of My Existence: Episode #14.
No one uses the term e-commerce anymore because in 2015 online retail is a ubiquitous notion to the market. That wasn’t the case in 1998. Six long years after Book Stacks Unlimited went live and three years into the early days of both Amazon & eBay, a large segment of the population was still wary of making purchases online with their credit cards.
This was the climate when Pierre Fay walked into the Organic Online office in New York with a big idea.
Pierre’s goal was to change the way people discovered fashion & prescription eyewear—moving from traditional brick and mortar browsing to a complete online experience. Just months prior to signing with Organic, and aware of the hold that eyewear stores had on the market, Pierre struck a deal with Lenscrafters to host an Eyeweb co-branded kiosk, which would allow potential customers to measure their facial structure with absolute precision and then capture an image. The kiosk would then upload the image to the cloud (yes, we had “clouds” in ’98), providing the person the ability to choose from thousands of frames to try-on, and ultimately purchase, from the comfort of their home on Eyeweb.com.
I was assigned the project under the mentorship of Organic’s Sr. Information Architect, Robert Fabricant, as this was my first foray into IA after shifting over from art direction at another interactive firm. While the work was much more intense in terms of thousands of objects tagged with unique SKU#’s and an eventual meta-data scheme that would drive our frame advisor engine, between Robert’s direction and the amazing collaboration of the Organic team, I didn’t feel completely out of sorts.
We started on the ground floor, as the branding was developed from scratch via a thorough brand exercise with Pierre. As the visual team led that process, Robert presented our organizational concepts through high-level diagrams, and as we garnered consensus, I defined the organizational principles, recall methods, hierarchy in the interface, navigational affordance, widget schematics, etc.
With a boutique focus on one retail object, Eyeweb allowed us to draw focus on the homepage to specific frame-centric features, and then divide the global navigation between those features and secondary support locations. Nomenclature is always important, but even more so in this instance, as we were transitioning people from the sensibilities of high-end, real-world shopping to an online experience. Areas such as the Personal Collection needed to impart the white glove feel they were either used to or imagined experiencing for the first time.
Web design challenges in 1998 were plenty, but the most ubiquitous—regardless of project type—were limited resolution display sizes (more than 70% of the market had 800×600 px wide displays or less). As such, we had to make strict choices when presenting information within the limited real estate available. This not only impacted the structure of the active elements in the interface, but it influenced how much white space we used to compensate for crowded aspects of the interface.
As the user made their way down to the frame detail, we featured the product image prominently, building the actionable affordances of the interface around the frame itself. Before time-on-page was an understood analytics term, we shot for stickiness, which is an interesting prospect in the retail world, as the ultimate goal is to convert purchases. But stickiness can also apply to users easily moving from one interesting product to the next in their browse > purchase lifecycle.
While we didn’t have the capability to present other frames dynamically via collaborative filtering—or even a simple (in 2015 terms) in-line attribute co-occurance driven display—we knew that prominently exposing frame attributes was important for sparking secondary discovery, which increases the chance for purchase conversion.
When we began working on the most compelling form of discovery on the site, the Frame Advisor, Pierre expressed that he wanted something different, so different is what we targeted. My sketches began by crafting an explicit linear narrative, using multiple choice questions centered around style and functional preferences and leveraging the same set of frame attributes exposed on the detail interface and personal collection—to return a set of frames.
Once we left Planning and landed in Design, we took that architectural approach and built upon it, with our visual designer evolving the explicit nature of the questions & answers to be more of an esoteric, implicit input process, using the grid pattern that we established across the site, but in a way that completely relied on visual clues that mapped explicitly to the attribute answers to move the user through the recommendation engine. The result was compelling and different. If this was designed for 2015, I’m positive that the experience would become immediate, viral Facebook fodder.
Back to the other primary platform experience, the kiosk. We were working with a much more functional interface in this environment, as the user was operating in public and needed to target specific areas of their face for the online system to correctly prep their image for the try-on interface. We needed to create an overly simplistic interface, with zero extraneous copy or features. The last thing we wanted was visible frustration from the least tech savvy users, surrounded by other potential customers.
We carried through the design patterns from the site for both brand and navigation consistency, and designed the java interface to present a simplified mechanism for dragging points into position. The step-by-step process was clearly labeled and overly simplistic, providing easy to find navigation both forward and backward in the process. Yes, we wanted conversion, but not at the expense of usability.
17 years ago we created a true platform—one that had interfaces used both in public and in private and leveraged the then magic of cloud immediacy to provide a compelling experience. There aren’t many platform experiences that survive over a period of 17 years, and Eyeweb isn’t one of them, but some (god awful) variation of the business is still in business, so we must’ve done something right.
Silicon Alley circa 1998; the halcyon days of agency product development.
That’s a 30,000 foot view of 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 Concepts 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 communication—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, during and after art school, I was a drawer on most days, and an illustrator when things got fancy. As a drawer, I’d usually go directly to pad with either pencil or my rapidographs, often attempting 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 serious, I’d spend time understanding the subject matter, find inspiration, and prep in a number of ways—taking photographs, sketching, cutting images out of magazines, you name it. If the illustration was for a class or a client, I’d spend time up front to understand the concept I was attempting to illustrate. 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 creative challenges and processes were introduced. We discussed campaign parameters in studio, sequestered ourselves to research, sketch and write copy, and then returned to present three concepts and be critiqued by our peers. 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 to speak of—let alone bottleneck with our conceptual work—this was a pure commercial design process, but one with greater degrees of complexities than fine art and illustration when it came to client input and production (I’m not going to bore you with the details of setting type and creating animatics).
From ’94 to ’97, as I spent my days designing CD-rom games (I landed an internship at a production studio during college), the notion of a downloadable patch or version updates simply didn’t exist.
Just imagine if that were the case developing modern day apps or sites; would Agile even be a concept? As such, production houses didn’t concern themselves with developers constantly being busy shipping product. We began the project with one clear goal of burning a gold disk to take to a reproduction house as our literal shipping deadline (one day I’ll tell my story of a late night, deadline-pressed, speed-limit drive to Lancaster, PA to do just that). As such, there was no rollout plan aside from the inherently defined big bang and the design/development methodology took that into account.
We often started with a non-linerar, node-based script >> storyboarded key frames and interface behavior >> sketched sprite and background details >> and then focused on final animations and artwork. As we did so, the development team would ramp up their technical architecture and take new input from the creative staff to iterate their approach and code base. So yes, we intensely collaborated and dev prototyped & tossed out code, but it was more similar to the collaboration found on set and in pre & post-production for a film than a web-based product with an MVP.
Our reputations (and often compensation) were dependent on releasing a finished product that found a market. And from our publisher’s perspective, releasing product into the sales channels that existed prior to the robust long-tail online retail world existed, well, we only had one chance to make a hit impression with both reviewers and customers. So if you ever see me twitch when an MVP is mentioned, that’s simply muscle memory from a product age long ago. It subsides with a good night’s sleep.
As east coast game production dried up, I transitioned to the web and cut my teeth within a couple of agencies, first as an art director, and then as an information architect.
The creative process as an AD 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 venture—both from a philosophical perspective and often logistically—so the notion of updates and additions were limited to fixing bugs. As an IA, the work was more focused on translating user requirements into sketches, schemas, taxonomies, etc., but the ideation, presentation and executing processes were similar.
In the late nineties, when agencies were in the luxurious position to offer soup to nuts service, development teams didn’t have complete agency in terms of driving innovation, as they were somewhat separated from the Design process—minus feasibility reviews of deliverables—in order to control costs. Only the best of the best shops could honestly tout a record of pushing the boundaries with their work, and those shops were doing it with pretty amazing collaboration and financial wrangling across the board.
Being truly iterative in a manner that fosters innovation is a rare bird for far too many engagements, and it has nothing to do with the skills of the people involved. Unless a firm has a well-funded retainer, most clients will devise a release plan and agencies will simply drive to meet those deadlines. Most will run a linear design process (some might iterate in varying degrees) and once specs are in the hands of development, the design firm will tend to fall out of the picture, leaving future iterative feature development to the client.
This is the future that all potential clients (from the perspective of an agency) are moving towards. They may invest upfront to bring in a shop to provide specific thinking or output (that often needs to come from the outside of the organization), but they’re leaning more and more on their in-house product design teams to take the majority of iterative responsibilities moving forward.
The very DNA of agency work makes a traditional definition of “innovation” difficult (think: an agency releasing an app on the scale of Google Maps), but if viewed specifically through the lens of expert, outside consulting along the lines of brand, behavioral design, technical approaches, etc., then an agency can most definitely help foster innovation within this business climate.
It’s ok that the halcyon days of Silicon Alley are coming to an end, if they’re not already dead and buried. The industry, in general, needs to adjust their method from running processes that create documentation to ship a product for their clients to processes that, first and foremost, provide immediate returns on innovative thinking and design, such as with variants of Design Studio methods.
Innovation will be even more important for these firms to position themselves for future work as the client ecosystem continues to shrink and become redefined. The challenge is moving to business models and methods that can adapt to the shifting world around them to redefine what innovation looks like and how an external team can provide it.
Spin-Off Consultancy Within A Global IT Shop
I wanted to include this experience as it represented my first time working within a development-centric organization. Hired by the recently appointed corporate creative director—who was brilliant to work with, btw—my charge was to develop an information architecture practice with an operating methodology that could be rolled out the firm’s satellite agencies across the US.
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 was that the business (business analysts and developers, in particular) operated in an object-oriented, UML methodology—beginning with JAD meetings that bore stacks of business requirements and development documentation bordering on ceremony for ceremony’s sake.
When I realized the client work was primarily website engagements, with the random software project that escaped from the IT sales team, it became apparent the scale of the challenge ahead of me.
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 constantly kicking-off across the country. What I immediately discovered is that IA had to own as much of the actor-driven UML documentation as possible or we had no leg to stand on. 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 we attempted deeper degrees of change, my efforts quickly became a game of tug of war with management, but this was the time we lived in (2001)—most of my design peers were experiencing similar struggles with development-centric organizations across the industry. Convincing an entrenched executive technology staff that Design needed to have a seat upstream to inform development of what users needed in their interfaces and in a way that would reduce documentation (read: billable hours) quickly devolved into a street fight.
The daily struggle for optimizing how Design fit into a potential innovative space created a blindspot for me to the possibilities of more collaborative opportunities (think Agile). Over the next five years, I unceremoniously took on the sub-conscious 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 in an Environment Not Ready to be a Product
In the period following my uphill battle within the IT world, and just prior to the rapid evolution surrounding Extreme Programming & Goal-Directed Design, I took a position to design streaming applications in the financial industry. Not only was this particular domain ripe for Design to impact innovation, but the industry as a whole was chasm for our craft. As with my previous stop, it took results to seal the deal of institutional change.
Over the three years that I was in their employ, Design moved from a position of downstream, last second patchwork 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; the firm knew they were providing a service to their clients, but at the highest positions internally, the authenticated space simply wasn’t perceived as a proper product. It was treated as the flip side of the marketing layer; the logged-in space that had a lot of traffic who were paying clients, so downtime was not an option.
The history of the (acquiring) firm had Business providing Development with direction that described desired front or backend projects, with Marketing providing all visual assets when applicable.
After successfully navigating the domain for a few years, I was given the opportunity to staff a UX Design team to design the new trading platform. We operated in more of a waterfall manner than not, but since our front-end team was in our group, they were constantly prototyping wireframes. Without this approach we would’ve stopped development in their tracks, but our team collaboration was top-notch. At any given time we had 10-15 active projects (pre-Basecamp or Teamwork era), which could have ground our productivity to a halt if it weren’t for how our internal processes adapted to produce on-time and above expectations.
We pushed forward within a Goal-Directed Design framework to produce solid work for our clients, both internally and externally, though the opportunity to proactively collaborate cross-functionally in a broader manner—addressing the needs of n number of other client touch-points in an innovative manner—was limited as the projects continued to stack. True collaboration between Design, Development & Business had a ways to go.
On My Own… And Sometimes Calling The Shots
Fot the past ten years, I operated a one-man 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 to employ.
For almost two years, we engaged with a huge player in the media industry and our design process with the internal project management and development teams was steeped in an early-stage (2007) Agile method. The project was a ground-up content management system specific enough for the needs of all internal users, but generic enough to be used to publish to a handful of prominent websites with millions of daily viewers driven by television traffic.
After beginning the gig with a large round of research to inform the general parameters of the product, my team (located across the US) 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 which features (from the approved scenarios) that we’d focus on completing over the following three week period to get us close to an MVP. The process gave our design team a week to sketch and specify, and then iterate with dev over the following two weeks.
While that was a rather optimal situation for us to cross-functionally innovate within, the most important aspects of a Lean process had to be handled in more conventional manners. This was an internal application for a huge, high-profile publishing organization with a certain degree of politics surrounding its rollout. We simply couldn’t prototype, receive feedback and ship in a cyclical manner. Those decisions were out of my hands.
These methodology decisions matter, as method—collaboration, iteration, agility, etc.—directly impacts the possibility of creating a useful experience for people and positively impacting the bottom-line. Unfortunately, one only has so much input into design/development processes when one is an external design consultant.
So Can I Have That 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 thrive, even survive at times. While I’ve admittedly operated with an agenda 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 in this space has immensely changed as well.
Just as industries 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 our clients.
My d/Design interests have never led me to submitting entries in an awards chase and my fight to establish Design titles within an organization/across the industry ended when I started my own shop (thankfully, Design lost its training wheels in our industry over the last decade). My interests today lay squarely in the realm of contributing to the formation of excellent product concepts and executing their design to the point of them becoming wildly successful.
Managing a design team within an innovative space whose expectation of designers—once artists free of parameters, input, and time constraints—is that they are not only able to see the forest through the trees, but do the difficult work of collaborating to nurture features into a production lifecycle; to refine a smart idea into a working behavior and onto a great product… that’s the rare orchid I’m looking to catch out in the wild.
UPDATE: I’ve found the orchid in MedBridge. Let’s see how it blooms…