Category Archives: Business

Reality is messy

We like to believe that the right framework, method, approach, or conventions will allow us to create perfect projects. Our code will be beautiful, pure, performant, and maintainable. Outside of some developer blogs however, this is often not the case.

Reality is messy.

Some people are fortunate enough not to have to deal with this reality on a daily basis. There are people who work for browser-makers. Their projects are not most projects. There are people who work for large-scale and popular “startups”, who have the luxury of focusing on a limited number of components. Their projects are not most projects. Although we can (and do) learn a lot from posts on Medium about month-long experiments in link underlining, many of us have pressing deadlines. Processes can be messy because they involve other people and limited resources, tight budgets, difficult stakeholders and ridiculous time constraints.

Outside of the product world, many of us work in creative and/or technical services. Our job is to help our clients. These clients have concerns during the design and development process that we need to address. Sometimes, we can’t do everything exactly as we would like. Client needs trump our own.

I’ll give you an example: a project I worked on where my job was to help take an existing desktop-centric design and make it responsive. My task was to determine exactly how everything would work responsively. My deliverable was a series of more than 20 design comps built with HTML and CSS. The comps were themselves responsive, so stakeholders and the developers knew what the end result should be.

Here’s the thing: there were extreme time constraints. We basically had two months to get this fairly complex website responsive. In order to do this, the developer would change as little HTML as possible, as this would mean rewriting components all over the place. Yes, we wanted to see that happen, but it wasn’t feasible. So I used the existing HTML whenever possible, and I cringed while doing it, because holy shit, this HTML (with all due respect to the developers; you know CMSes). But it was practical and allowed the developer to reuse a lot of my CSS. Which was a lot more CSS than I would have had to write if I were able to rewrite the HTML.

Could I have said no? Sure, but I wouldn’t have been helping anyone, least of all myself, by doing so. This client has interesting challenges, and I wasn’t willing to just say no to four months of work with them because of a tight deadline.

Another issue I had to deal with was working in weekly (!) sprints. Coming up with responsive strategies for each component of certain screen types and then prototyping them in one week was not easy. In order to do it without creating conflicts and still get things done on time, I had to namespace each logical group of components, like this:


.product {
  /* Styles, including media queries, here. */
}

.account {
  /* Same idea, different logical group */
}

While doing this for each round of logical prototype groups allowed me to avoid conflicts with prototypes I had done or those I would do in future sprints, it made me repeat myself across those blocks, since I had literally no time to constantly refactor. And it was not my job to create the front-end code, though I knew the developer was using and altering snippets from my CSS to save time. Result: my comps had way too much CSS.

Could I have an approach like BEM? Yes, I could have. But since some CSS methodologies eschew inheritance, I lose a huge time benefit. And remember, HTML changes were required to be minimal, and that’s not feasible when choosing a CSS approach that involves moving the dirty work into class attributes.

What’s your goal?

In the project above, the thing that kept me sane was focusing on the specific reason I was asked to join the project: to decide how everything should look and work responsively, and to visualize this for stakeholders and the developers, in such a way that they could actually experience it on actual devices so that it is clear what needs to be done.

That had to be my focus.

We finished the work in two months with just a few people. And a phase two was planned to go in and refactor, to improve lots of things, including performance. That’s the right time for optimizing HTML and CSS, and improving things like performance. Ideal? Certainly not. Realistic based on the needs of the client? Absolutely. This particular client sees their website (100% of their revenue comes from the website) as a process rather than a product. I think that’s a healthy way of looking at things. It means they have a responsive site, built within two months time, that customers could enjoy right away. That site, even with sub-optimal HTML and CSS, performed twice as well as the previous desktop version. Customers don’t care about what the source looks like, and phase two, almost underway, is intended for code optimization and other quality improvements.

Messy, isn’t it? It certainly is. But really, it’s often the reality of a service business. It’s natural to try and find processes or approaches that work for every project, but you won’t. And they don’t. Embracing this fact is one step toward pleasing clients, and also helps deal with the frustration that we can’t always make everything as perfect as we’d like it to be. Of course, that shouldn’t keep us from trying.

I start every project with a lofty goal of achieving perfection. I’ve never reached it. I make mistakes all the time. I look back and immediately see things I would have done differently. I try to learn from those mistakes. I try to remember that making those mistakes and dealing with the messy reality of the work, while still trying to do my best work, puts me on a path of constant improvement.

We need to give ourselves a break. I hope I’m learning more and becoming just slightly better every day. I hope you are, too. In our line of work, where everything moves so quickly, that’s something to be happy about.

Here’s to a better imperfect year than the last one.

My name is Stephen, and I’m a generalist

This week I had something akin to an existential crisis. The whole thing was solely in my head, and alarming in intensity. If you ask me what triggered it, I couldn’t tell you. Though it might have been that potential client that needs to learn about how to deal with potential contractors, but that’s another post entirely.

Part of this mental hurricane was me questioning what it is that I actually do. What is my job, exactly? I’ll spare you the worries about how this question might tie in to age discrimination and how I must remain my own boss in order to continue working. No. I can hear you thinking about it. Stop it.

In the 20 years I’ve been designing and developing for the web, I’ve considered myself a designer. A designer who can code, but still a designer. And indeed, when I started, I designed a lot. I came from print design. Design, especially typography, was what I loved to do. In the work realm, at least.

I wrote my first BASIC program when I was 12 years old. On a Commodore PET. Yes, I see you oldies nodding. We had an Apple II in a special room at school. One Apple II. Programming was like magic. Someone wrote code and made these computers do amazing things!

I was fairly good at math(s), roughly two years ahead of my fellow students, but I’m also easily bored. So after advanced trig, I kind of lost interest in both math(s) and programming. I liked it well enough, but I encountered a dull patch. Other things, like art and theatre, grabbed my interest.

Programming never did let me go. I came to realize that some things are simply more effectively done in code, and that there was space in my brain for both the technical and the creative. But people seem to fight against that particular brand of collaboration between the different parts of the mind. We’re told to specialize. You can’t just specialize in JavaScript; you must specialize in a particular aspect of JavaScript, such as performance. Or a particular library (good luck with that). You also can’t be a “designer”, because what exactly does that entail? Do you do interaction design? Visual design? Or as ambiguous as they come, user experience design?

If I put 10 people in a room and asked them to describe user experience design, I’d get 10 different answers. 11 if it’s a really creative group. While speaking recently at UXLx, I encountered UX designers who don’t draw. “I only do research”. Others design the user experience of websites without venturing into the browser. Graphing software is enough; after all, they’re UX designers, not UI designers. (Oops there’s another one for you.) Some UX designers did more visual design. Confusion ensued.

Not that these disciplines are bad or unnecessary. On the contrary. Nor is the fact that we might soon need a complex table to map out the various types of design we’ve created and their relationships to one another. But where we can complicate things, we tend to complicate things. And when specialization means money, we’re quick to specialize.

And now we’re entering a period in which the spectrum of specialists is just a bit too large for some projects. Like a feature film, all the disciplines need a lot of overhead to work together smoothly. And we look to the generalists. We might call them “product designers” or “full-stack [insert title here]”. Proficient in many areas, expert in one or two. For me, I’m an art director at heart with a lot of experience in graphic(visual) design, interaction, design processes and dealing with large-org project politics. And I can code.

When people ask me for a portfolio of recent design work, I’m shocked to discover that I really don’t have a clear one. The work I’ve done since going freelance five years ago is mostly front-end development combined with design and interaction work. Which all, believe it or not, is part the user experience. Thus, I’ve done front-end design and development consulting work. Accessibility work. Speaking. Writing a book. Co-organizing conferences.

Holy hypertext, Batman, I’m a generalist.

The thing that’s both scary and exciting at the same time is that no generalist is the same. This week I came to realize that I have no clue how to market myself effectively. (No that is not an invitation.) I’m an expert in a few things, and proficient in several more. But for every project, emphasis shifts within those areas.

This week, a friend told me that he doesn’t know what to call himself. Then he said, in his typical manner of a man who believes that every workday is just a holiday that starts with a “W”:

“Embrace the chaos.”

I like code. I like design. I like the place where design and technology meet. Where art and technology meet. It’s a special place. It exists and we should embrace it.

On leaving Cinnamon

Last Thursday, 30 september 2010, was my last day at Cinnamon, the company I helped build and where I’ve worked for the past eight years.

Ten years ago, I left my career as art director in print design and joined the company that—two years later— would evolve into Cinnamon. I had been learning about and creating websites since 1995 and I welcomed the opportunity to work full-time on the Web.

As many baby-faced entrepreneurs, I knew nothing about running a business, and less about “doing” business. Hungry as I was for new opportunities, I didn’t stop to think about what running a business meant; I was on board to lead creation of the product.

Cough.

After some management Musical Chairs, I found myself in the position of having to get clients, keep those clients, and lead our team. Not to mention the usual financial responsibilities. I was schooled as a fine artist and graphic designer. The first time I sat across from a potential client, knowing I needed to get the business, was terrifying. I didn’t know this stuff, I just learned as I went.

It was hard at first, but I began to get the hang of it. We built a pretty stable team and decent focus. The main team has been, with one exception, the same since 2006. It’s kind of like family, and that makes it hard to step out and move on. So why?

I love the Web. I love what we do. I can imagine no better job for a creative person who always craves New Stuff. Making the Web means parsing information, giving it meaning, making it accessible, making it usable and (in my opinion) making it beautiful. There are new challenges every day, and with those challenges come new ways to meet them. And if those methods don’t suit you, you can come up with your own. There are rules, yet there are none. The Web, for me, is where my main interests—art and technology—meet, flirt and make babies.

When I started this adventure, I did it because I wanted to make cool stuff. Pretty stuff. Useful stuff. Through the years I ended up selling stuff and managing the People Who Make the Stuff (while periodically sneaking some art direction, design and production work in for myself). And we did do cool stuff. Cinnamon was one of the first companies to combine professional design with web accessibility. Lots of firms do that now, but in 2002, accessible almost always seemed to mean “looks better to blind people”.

But now it’s time for me to get back to why I got in the game. It’s time to focus by removing operational distractions. It’s time for me to create a more balanced work-world, which can allow me freedom to do what I love to do and enjoy my personal life as much as I can. I’ve learned a lot about clients, and as an independent contractor, I want to help them stop being their own worst enemy. I want to help developers do the same. I want to spend more time with the technologies which will allow designers to do more with the web (yes, that includes CSS3 layout). I want to focus on helping clients with what we now call the Mobile Web, which I believe will catalyze some new, platform-agnostic thinking about information, what we can do with it, where and how. And I’m always so full of ideas… it’s time to write and speak about these things more frequently.

I wish my colleagues at Cinnamon all the best. They’re all great and talented people and they’ve been incredible, and they will continue doing great work for some really exceptional clients. And they’re not rid of me completely; there are at least a few projects we’ll be doing together (do I hear profanity?). And next time we go for beers, I’ll be their peer and not their boss.

I’m pretty nervous about it, to be honest. It’s like bungee-jumping—I’ve never done that either. It’s too easy to look down and imagine what it will sound like when the cord snaps. But I’ve done a lot of good work. I’ve helped other people do good work. And I’m looking forward to doing that in the future—of my own design.