In September 2005, I was 26 years old. A decade ago.
I called Scott Upton on the phone and asked if he was happy at his job and if they were hiring. A week later I’d had my interviews, handed in my resignation for a second time at Spiremedia and began a new chapter in my career: I was about to spend 4 years at a company in Boulder called Wall Street on Demand.
Bull Markets and Bear Markets and Financial Collapses, Oh My
Wall Street on Demand specialized in taking hundreds of live-streaming stock market data feeds and turning them into beautiful interfaces for making financial decisions. We designed and built investment research interfaces for everyone from the E-Trade home investor managing their retirement account to the Merrill Lynch institutional investor trading hundreds of millions of dollars at a time.
These were not small local clients whose deadlines could slip when the process didn’t go according to plan, with business plans I’d seen a hundred times before. These were clients like investment banks and cable TV news networks who demanded financial visualization expertise from our staff on a daily basis.
If I put a percentage instead of a dollar amount in a table cell showing Earnings Per Share, it would be called out long before my work made it to the client’s inbox. The amount of training to be done with new hires was incredibly high before we were allowed to run our own projects without a CD at the helm, something as a Senior Designer I was expected to do fairly soon.
Ponds and Fish
Competition is not the best way to get ahead
We had posters on the walls extolling the virtues of collaboration. The design team at Wall Street was not competitive: as a team of teams, we had a lot of design leadership and structure facilitating our collaboration at every level. The structure looked like this:
- Company Creative Director – Chris Allegra was at the top.
- Team Creative Director – My team lead was Kent Hollrah. We had about 6 other CDs at this level when I joined.
- Senior Designers – Many on each team
- Designers – Many on each team
Before my tenure was up, we’d add a couple new titles, Associate Creative Director and Junior Designer. It was a unique system that had the added benefit of Chris, the company Creative Director, essentially working at the C-level with James, the CEO and Catherine, the COO: all three of them were related.
This was more or less a design-focused, family-run business with Goldman Sachs as the Board of Directors.
Chris had domain expertise in interaction design and financial design. He’d been educated at Johns Hopkins for creative writing and this education gave him a passion for concise, effective communication. He’d later go on to do post-grad work at UCLA for data visualization and he was a god-damned whirlwind to work with. It was exhausting to try and keep up.
This was by far the most design-led organization of which I’ve ever been a part. There was a truly talented design brain with actual power in the executive suite who demanded at the highest level that our own organization be true to a specific design philosophy.
Yield Curves and Learning Curves
There was a lot to learn. There was new, insane shit showing up in front of my eyes every day. Page designs containing ideas more complicated than I had ever imagined myself designing were casually discussed over cubicle walls, all around me. It felt like being in college again – except everyone was obsessed with the stock market for some reason.
I’d had a similar feeling before in my life: junior high school with my friends, coding Pascal and BASIC. I’d had it at Spire when I was 20 years old, coding Flash animations for websites whose domain names cost 10 times my salary. It was the feeling of being a little fish in a big pond, and it was good for me. “I will never know everything there is to know here” was something I thought to myself on a daily basis. I engaged in learning without fear, and applied that knowledge immediately.
The design staff carved out many physically-communal design spaces. We started out having our design meetings in a room labeled Aspen, named after the trees that swayed right outside its window. When we leased more space across the street, Chris oversaw the entire design and construction of the new office, building it specifically for designers and developers to collaborate.
We had two rooms separated by a substantial but removable accordion wall made entirely out of whiteboard. These rooms were named after Charles and Ray Eames and were reconfigurable as we needed.
We’d gather every Friday morning, bright and early. Coffee in hand, we’d file into whichever space we were using at the time and we would nerd out as designers together. We’d discuss three things:
- We’d discuss the work we were doing. We’d show what was near or just-launched. This work often wasn’t being displayed for critique but for us to ask questions and to learn from the decisions they’d made. Gathering feedback from the team on how to update the project wasn’t usually the point. Pointed critiques were sought on a 1-to-1 basis during the workday.
- We’d discuss design in general. We’d save up URLs to send to who was running the meeting each week, and view those pages as a group. If we saw a new visualization we liked, or an interesting layout or graphical treatment, we’d put these up on the screen and critique the hell out of them. Other people’s work was up for grabs, critique-wise. What would we change about this? What worked for our clients, and what wouldn’t? Where would you take this to push it further? This way, we’d all critique something together, with no one in the room defending the decisions or backing up their work with client quotes. It was all about working together as a group and creating rapport as well as building our own critique skills so that we could look at our own work with a fresh set of eyes if we needed.
- We’d discuss and iterate on our own internal processes. What about the design process wasn’t working for you? What was? How did you manipulate the normal flow in order to reach that really excellent level of work you just did? New ideas were brought up and digested. If there was promise, we’d try out new official policies, organically growing them and leaving them by the wayside as needed.
We all sat near each other in the office. We went on design- and art-oriented outings together, and we created a culture that really worked to get beautifully-finished work out the door.
Just Pull Up a Chair, I Guess
The funny thing about all of this collaboration was that I resisted it at first. We had a global Creative Director running the entire Design & Development division and I had Kent, a Creative Director, directly managing my work. I’d never had this many bosses before. During the first few months, I was a little unhappy about how much direct contact I was having with Kent. It was the first time in a while where I was working directly beneath someone who checked in on my progress multiple times a day. He’d show up right behind me at my desk and pull up a chair:
Whatcha up to, Kev?
was his usual phrasing.
Fuck you, Kent.
was the usual response in my head. I didn’t say it. I’d stop reading the NY Times article that was probably on my screen, tab back over to Photoshop, and show him my work.
He’s ask me questions that would make me frustrated, because of course I wasn’t done with it yet. He’d ask me something I hadn’t gotten to or he’d challenge me on basic things like color usage:
Why’d you use yellow here? It’s not in the palette.
I’m designing the warning panel you assigned me. I chose a yellow with similar attributes to the family of colors already on the page, so it works to add it.
and he’d go
to which I would again in my head reply
Fuck you, Kent.
This didn’t last long, and I’m giving Kent a hard time about it. We got past it and I moved on to learn an incredible amount of data visualization and general financial knowledge directly from him.
The moment of truth was when work started getting really hard. I was driving home to Denver every night in a daze, feeling like I wasn’t keeping up. Kent’s own design work was taking up more and more of his time, and yet I was not owning much about my designs or my clients. Even though he didn’t change my work much any more, it all seemed to hinge on his opinion, and so I felt powerless. The day he shocked me out of my daze was when he sent me a heart-pounding email. It said simply:
I need to you to engage now.
I had no idea what this meant. I went to Chris and asked him what on earth I was supposed to do with this. Chris told me:
If you ask me, it sounds like he’s saying it’s time for you to jump in. If you don’t know what that means, then it’s up to you to decide.”
I was afraid at first. I was the only designer on a project for the very first time here, and I knew I didn’t know very much yet. All of the experienced designers were working on the cool stuff like stock charts for BusinessWeek and CNN. I was designing UIs for people to get email alerts. I wanted the big-name work, but was terrified when I was given something serious to handle on my own.
I decided it was time to start using my design skills to actually get design accomplished. I started drawing diagrams of how I understood the system I was designing to work. I took these diagrams to the client and then to my company’s developers and we iterated on them until they made sense and everyone agreed. Then I started wireframing in HTML. We had clickable prototypes with no CSS before we had a design language, which followed on quickly. I scheduled meetings with people downstairs I’d never met but with whom I needed to create relationships because my client was requesting a brand-new way of handling incoming data feeds, which needed to be written from scratch. I worked closely with the client to determine their systemic and visual requirements. At the very end, some crucial final understanding of the client’s needs came from Kent’s involvement in days-long meetings.
By the time it launched, I’d written the final production HTML and had handed it to our developers who plugged in the data calls and re-arranged things to work with our nascent pre-ajax technology.
In the end, what got us ahead and to a good place was that the whole team came together and collaborated, not that I could do the design work perfectly in a silo on my own, which was what I thought my role as a designer had been up to this point.
At the end of that project I had a sense of pride I’d never felt before. Many teams worked together, and I learned to lean on my team lead at crucial moments, pushing through a UI I knew was up to speed with what the rest of the design staff was producing.
Past Performance is Not Indicative of Future Results
I just described an intense project, and it was the first of many to come. Over the next 4 years, I’d learn that some resistance from the first-floor engineering teams was something of a common theme. As we grew and grew quicker and quicker, more inexperienced project managers were being hired to manage more and more work.
By 2009, people like me who’d been at the company a while and had shown leadership promise were moved into new positions. On the design team, this new position was called Associate Creative Director. It was our job to essentially work closely with our CD and start adapting their responsibilities into our workflow, namely managing the relationship alongside the Account Director and selling the client on new work at every turn.
This was new! And challenging! And I didn’t take much to it.
What I could do: execute high-quality UI and UX work on a weekly basis, in a novel and compelling way, driving the less-experienced designers on my team to do the same. As Associate Creative Director I really tried to know everything there was to know, just like it looked like the other CDs were doing when I started, and I began to lust after the wrong thing: prestige.
I started forgetting to collaborate. I’d react strongly in internal meetings where I felt developers didn’t care as much as I did about turning out a great product. I’d push clients toward what I thought the correct solution was, without really listening to what they were trying to accomplish. I’d bully other designers into trying to learn to code, despite their protestations that they just never really understood it. “Every designer should learn to code!” I’d say, dismissing their views entirely.
And so I burned myself the hell out. I burned everyone around me out on working with me. It’s true that when I left this job, my clients called emergency meetings in Boulder to plan the roadmap for how they were going to continue working with Wall Street in my absence, but I was fending off internal talk from above that I wasn’t quite working out in this position. What I needed though was something I couldn’t find at this company anymore: I needed to be a little fish again.
I needed to learn to collaborate with other designers again, without the ego attached as I rose the ranks and earned respect. I didn’t know it yet, but what I needed was to go work at Automattic, something I’d have the chance to do sooner than I’d know.
Then something funny happened that we weren’t expecting, but sort of hoping for: the web became a tool everyone used, all the time, for a ton of reasons.
New users were arriving online every day, and new services were popping up in droves to give them fun stuff to do there. Years after Wall Street left the “dot-coms” to die in the gutter, the former employees of these companies built new tools, with new ideas about what a web interface could accomplish.
Web users adapted and started to actually love the products they used online. Flickr, Twitter, Tumblr, Del.icio.us: we all have memories of what was new about these things when they first appeared that delighted us.
The web was a super-fun place to be, both as a user and designer.
2001 – 2010
I spent the intervening years doing the following:
- Being unemployed Lots of freelance
- I built a web page with only 5 kilobytes of code
- Building PHP and MySQL from source on Mac OS X
- Building custom Content Management Systems in PHP every time I launched a website for a client
- Getting a job where I helped Einstein sell bagels on the internet
- Securing just a few long-term freelance clients that would support me for years
- Getting a low-paying job for health insurance reasons, then quitting that job because I found myself editing .NET code in a shirt and tie
- Getting a job doing data visualization and financial design for investment banks
- Traveling to New York to work with clients on Wall Street
- Learning and forgetting Flash, ActionScript and Flex
- Building in CakePHP and taking offline a web app for people to record very personal data
- Spending 6 months designing a 15×10 GIF (among many other things) for the front page of the New York Times
- Getting a job where I designed screens for people with mental disabilities as well as for people whose job was to support those with mental disabilities
- Watching the idea of “mobile” evolve from WAP-based apps rendered on Handspring devices to the responsive web and iOS/Android apps we have today
- Getting a job at Automattic, working on the blogging system I’m using to publish this very post.
I can honestly say that during those 9-10 years, my work was used by millions of people, and that by 2010 my work reached that many people daily. I learned a lot during this time about how people use web applications, how they share content on the web, and how they talk to one another with the tools we build. I learned what my medium was being used for (fun fact: in 2002 I owned the domain “automaticmedium.com”) above and beyond what I was personally using it for. And all this time, I blogged.
The Importance of Blogging in Earnest
I used a system built in PHP3 my friend Tai and I paid $500 for and then I ported that blog to a custom system I wrote in PHP 4 which I then wrote a custom importer for in 2007 that pulled it all into WordPress. Blogging was and is important to how I work.
Ego & Empathy
While designing and building the tools my clients asked me for, I was simultaneously either plugging away at a new CSS idea on my blog, or trying out a new language to build a web app. My craft and I grew up at the same time and I tried to stay involved in it above and beyond my client work for two simple reasons:
- Ego: I needed a place to play. Client work was now very serious and very important and playing with new ideas often wasn’t the best choice for these projects. Not to say we didn’t pitch new ideas, they just often weren’t chosen for development. Knowing I should and could keep my code chops up by playing on my blog was important to me for increasing the quality of my work.
- Empathy: I really wanted to have my own site with an audience and user base that I considered my own. This way, I could truly understand a client’s desire to do right by their users because I spent evenings and weekends making something for my own group of people I wanted to please.
These two concepts seem diametrically opposed: Ego and Empathy. I contend that to design a web application that people want to use on a daily basis you need both the ego to say:
“I can make something people will want to use that’s better than what exists”
and the empathy to listen to what your users actually say when you launch it. Additionally, your empathy for what you’d want on the screen you’re designing goes a long way toward making something your users may want to use.
Try All of the Things
How do you build this empathy? One of the ways besides maintaining a web app by yourself is to be a die-hard trier-and-user of any and all web apps. Really use them for really real things. See what making boards on Pinterest is all about. Follow art blogs on Tumblr and check it every day. Try Snapchat and get confused and close the app forever. Stuff like that.
You can start to understand what else the rest of the world is doing with their digital devices on a daily basis; you can see where your app fits into your users’ lives, not just how your users’ lives fit into your engagement cycle.
Empathize with what your users do on a daily basis with your tool by doing the same things with it and by doing the other things they do on a daily basis on the web, too. Pay fucking attention to what works and what doesn’t and why. You can start to synthesize this information with the designer’s ego telling you that you actually can produce a better product. What can result is remarkable: an app that people love using.
That’s always been my goal for my work on the web: to make something that people love having in their lives, something that feels like humans made it for other humans. They’ll come back over and over and give you their money for things you’re building that they want to use. You won’t have to beg for money from people who want to pay you for what you make.
Up next, part 5: Designer-Driven Design