Adaptation: A Framework for the Ages

Inspired by Damien Newman's process
Inspired by Damien Newman’s process of design visualization

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, culminating with the clarity and details of Design.

While such a process is a universal axiom—we all start in a fog as we attempt to narrow down to any clear form of expression or execution—what it doesn’t begin to touch upon are the dynamic methods available to effectively collaborate and innovate within a product development environment.

I’ve been thinking about the evolution of my own method for a while now, as I’ve moved from personal expression to designing large market product solutions over a 20+ year-long career. I’ve documented my journey here, so If you’re inclined to continue on, be warned that I’m going to start at the beginning and that goes waaaaaay back.

Being an Artist

Before art school, I was simply a ‘drawer’—I’d go directly to pad with either pencil or rapidograph pen, often skipping 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 my expression was complete.

As I became more focused on the craft of illustration in undergrad, I’d spend time ideating through subject matter and prepping for pen touching paper by taking photographs, sketching, and cutting images out of magazines. Regardless of whether 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, entering the world of problem solving.

“Dunk” (1988) / Sunkist: Nature’s Temptation (1991)

Undergrad Advertising Design

My illustration focus at Crouse College took a turn to communication design, and with it a whole new set of challenges were introduced.

We were provided with faux business objectives and campaign parameters in studio, sequestering ourselves to research, sketch and write. We’d return to class to present three concepts, receiving a full-on design critique of our thinking and execution.

Refine, repeat, complete.

Being able to clearly pitch an idea, and then take criticism as constructive without presenting a defensive posture was as important to a 20 year-old’s professional development as the ideation approach and execution skills themselves.

Towards the end of my undergrad career, we began collaborating with Newhouse copy writers, which prepared us for the machinations of a real world creative team (note: I never pursued a traditional print & tv agency career). This was a commercial design process, one with greater degrees of complexities than illustration when it came to client input and iteration towards sign-off.

Game Design

After undergrad, I spent my days designing edutainment games after landing an internship at a local studio. The biggest contrast between the gaming industry now and then was that the notion of a downloadable patch or a version update simply didn’t exist. We were pre-web— production houses didn’t operate with the model that developers were always busy shipping product.

We began each project with a clear goal to burn 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.

Big bang: Released all at once

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 artwork

As we made progress, the development team would ramp up technical requirements and begin to shape their architecture, specific to our designs; new details from our team would impact their approach and they’d iterate accordingly. We would intensely collaborate with engineers prototyping 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.

Agency Life

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. My experience in the gaming world prepped me for collaborating with a development team and similar to gaming, the market world of online campaigns, websites, screensavers, etc. were a first impression pursuit; the notion of iterative updates were known, but clients on retention primarily engaged about new work.

As an IA, the work was focused on defining and then translating requirements into sketches, schemas, taxonomies, etc., but the ideation, presentation and executing processes were 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.

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.

Traditional process for one-off production

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.

Collaborative method for ideation

While full development lifecycle innovation is difficult to find in the agency space, outside consulting can foster innovation within this climate through ideation around notions such as brand experience development, ideation workshopping, and targeted behavioral and industrial design execution. The challenge ahead for many 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.

Engineering Leading; Engineering Billing

After stopping by for the tail end of a startup experience—Tripod, where method wasn’t much of a focus beyond design and build—I experienced working within an explicitly focused 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 specific—to develop an information architecture practice that leveraged 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 a UML methodology where user needs were poorly tractable notions.

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 went into those sessions, but the resulting business analyst requirement and hordes of UML diagrams felt more like more ceremony, than necessary especially as I witnessed the majority of the work being web sites with less than complex degrees of business problems and design or engineering challenges.

What was ahead of me was clear.

Documentation, documentation, documentation!

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 being kicking-off across the country in eight independently run offices.

After rounds of discussions both external and within the context of active projects, I realized that IA had to simplify as much of the actor-driven UML documentation as possible to concept diagrams and wireframes or we wouldn’t have a leg to stand on when delivering user-centered experiences to our clients.

As I pressed to attempt further degrees of change, my efforts quickly became a game of tug of war with engineering management. While I was successful in taking ownership of certain aspects of the process—from key insertion points to deliverables—we just couldn’t nudge the overall methodology.

This was a common experience for my design peers in 2001; we were all experiencing similar struggles with development-centric organizations across the industry that built implementation models that drove the user experience.. The attempt to convince an entrenched executive technology staff that an executive creative team—information architects, no less—needed a seat upstream to inform development of what users needed, even with wins in tow, quickly devolved into a stand still.

Technical documentation = billable hours for managing consultants.

Looking back, the daily struggle for optimizing how IA fit into defining and executing may have created a blind spot for me to the possibilities of more collaborative opportunities.

Maybe I could’ve figured out a pre-Lean UX / Agile approach, or complimented JAD with design activities if my charge didn’t weight as much as it did to me. Regardless, at the end of the day, I believe my intent was good—I wanted to build trust and deliver highly useful work—but I was probably too early to a philosophical position to operate 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 impactful products.

Product Design Where No One Considered Product As A Thing

In the period following my uphill battle within the IT world, and just prior to the rapid evolution of Extreme Programming & Goal-Directed Design, I took a position to design streaming applications in the financial industry—well before the FinTech descriptor was anointed.

Not only was Datek Online ripe for Design to impact innovation, but the financial industry as a whole was a chasm for our craft to fill. And 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.

Describe our methodology in a simple paragraph 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 revenue.

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, though paired with, yet under the E. The evolutionary notion of Product was stuck as business analyst gathering requirements from stakeholders and operating as project managers.

I established a modified version of Cooper’s Goal-Directed Design

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.

True collaboration between Design, Development & Business had a ways to go.

Calling The Shots… And Not

For much of the past ten years, I operated a design studio 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.

Small studio, big impact

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, our iterative learning capabilities were limited to what Scripps was willing to expose. If I were in-house, I would’ve pushed 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 Impact, Please

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, design leaders must also evolve in order to produce impactful 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 patents or accolades; I care about results. My interests lay squarely in the realm of leading a team of practitioners, understanding human needs, contributing to a targeted product vision, and refining solutions to the point of wild success.

Nothing in life is certain, but I’m pretty sure that adaptation will continue to be central to my approach.

%d bloggers like this: