The time when I was first becoming acquainted with designing for the web coincided with the dawn of the MySpace band. An industry once controlled by a select few who had, over the years, entrapped hundreds if not thousands of artists into unfathomably hostile record contracts had finally been unshackled from its tyrannous overlords, allowing anyone with a pirated copy of Pro Tools to turn their three-song EPs into global rock and roll tours.

This was not unlike my own experience of the web which, from the time I was in secondary school, had granted me the ability to make what I wanted and share it with the world. My pirated copy of Photoshop and a few lonely evenings and weekends introduced my ideas and personality to more people in a month than the total population of my hometown.

My own nascent musical proclivities, and later an opportunity to swindle some free studio time from a buddy of mine, allowed me to record an album of charismatically Christian choruses to publish in that god-awful Flash player for anyone with a web browser to hear. And that led to some shows, and some friends, and some opportunities to practice my also-nascent craft of web-making with some MySpace artist profile designs.

I don’t know if I even own the hard-drive that once housed those early PSD files. Maybe one or two out of a dozen or so would be worth spending an hour or two recovering one day. The rest could rot in ferromagnetic hell for the rest of eternity for all I care.

But it’s the memory of those early struggles that is as familiar today as any day since. It’s where I first learned to never, ever, ever do critical work in a web text field (Tom was way too popular to spend his time implementing autosave); where I could no longer rely on ImageReady’s auto-generated rollover JavaScript to change my fancy menu links on hover for me; where I experienced my first client-relationship clusterfucks.

So it was not without some feeling of nostalgia that I read this evening a quote from Frank Ze, recently shared by Mandy Brown (in a beautifully written piece sharing her thoughts on the world’s transition from text to other, more modern mediums):

Regardless of what you might think, the actions you take to make your Myspace page ugly are pretty sophisticated. Over time as consumer-created media engulfs the other kind, it’s possible that completely new norms develop around the notions of talent and artistic ability.

This rings true to me. As my friend James Shelley once pointed out, the technology we create in turn creates us. My time designing and building MySpace templates for bands and songwriters introduced me to the skills I needed to learn so I could create my own future. It taught me that I need not be a victim of a system that rewards conformity and demonizes individuality, and that even your best friends can forget to pay an invoice on time.

There was no post-secondary syllabus with “Client Tomfoolery 101” emblazoned on a title page. My local library didn’t have a book explaining just what the fuck a spacer.gif was. I had to learn these things like everyone else who had uncovered the secret of View Source: through trial and error.

I believe young designers need this opportunity to experiment, to make mistakes on a smaller scale and learn from them so they are prepared when they’re pushed out onto a larger stage.

Occasionally I am asked how to get started in this industry. The truth is, no two paths are alike. But, I do believe that what separates those who make it and those who fall by the wayside is an understanding that it’s ok to make mistakes, to fudge a project or two or ten, to make something ugly in order to understand what it takes to make something beautiful. Character is developed not from the avoidance of falling down but from falling down and fighting your way back up again.

※ Permalink for “MySpace” published on date_to_rfc822

This past week, the design team at Brewhouse experimented with a process new to the three of us called a Design Sprint. Developed and popularized by the design team at Google Ventures, the design sprint takes a product’s stakeholders and those intending to design and build it through a 5-day design process encompassing 5 phases: understanding, diverging, converging, prototyping, and testing. Each of these phases ebb and flow through any product design process, but the 5-day design sprint allows designers and product owners to quickly and efficiently prototype and test a design solution.

Before embarking on the sprint, we set out to accomplish three goals by the end of the week:

1. To gain a better understanding of running a design sprint as outlined by teams like Google Ventures and Thoughtbot.
2. To attempt scheduling the standard 5-day sprint within Brewhouse’s standard 4-day client work week (we generally save Fridays to work on administrative tasks and activities intended to improve our knowledge and skill sets).
3. To design, prototype, and test a new interface for the newsletter builder in Goodbits.

We did not successfully complete all three objectives.

But, it was not a complete failure, either. We did improve our understanding of design sprints, especially the purpose and approach to the activities associated with each phase of the process. We technically did schedule the 5-day sprint into four days. And, we did make significant progress in our understanding of the problems we need to solve with the Goodbits newsletter builder.

In the spirit of transparent collaboration, I want to share what went right and what went wrong so that those on our team and those in other product companies can learn from our experience.

First, the good

Up until May of this year, Brewhouse had marketed itself as a Ruby on Rails development shop. When I was hired, the company began to build up the design side of the business. It was thought that we’d make do with just me handling all of the design work until just a few months in when it was clear the design business was growing faster than anticipated. In September, we hired Lee to help with design, but it wasn’t until this week that he and I had a real opportunity to collaborate on a project.

As well as collaborating with Lee for the first time, this was also my first full week working on Goodbits. While I had been involved in discussions and have made small contributions to Goodbits, I had not yet had the chance to dedicate an entire week to our own product. I also relished the opportunity to work with our product manager, Mark, on our own product rather than a client project.

Practice makes perfect

Reading through the details of the Design Sprint exercises, I was struck how they felt both familiar and alien at the same time. I have years of experience researching, sketching out different user interface ideas, prototyping and building products of various sizes and levels of complexity, however I would tend to start generating ideas with pen and paper and move rather quickly to wireframing in either Keynote or Photoshop as quickly as possible.

In the design sprint process, sketching ideas by hand is the primary means of coming up with multiple possible solutions in a short period of time. Exercises such as Mind Mapping and Crazy Eights are intended to help us get to the heart of the problem and propose as many solutions as possible.

It was great seeing the various options that each of us came up with. However, it wasn’t until we had completed a few rounds of this process that we realized we had missed the Storyboarding exercise to refine the ideas we were brainstorming.

During this phase of the sprint, I found my own ability to sketch ideas paled in comparison to both Lee and Mark. I also noted that my frustration with my limited output caused anxiety that I was unable to contain. Not my proudest moment during the week, but I hope by acknowledging it I will be able to improve my output for our next sprint.

By practicing the activities that make up a design sprint, we were able to gain a better understanding of the purpose of each activity as well as improve our ability to critique and collaborate on our ideas. By the next time we attempt a design sprint, we should be more comfortable with each activity and more efficient moving through each phase of the process.

The importance of documentation

Though it was not one of the goals we had stipulated at the outset of the project, we did use the sprint as an opportunity to test a new tool, Paper by Dropbox. We used Paper as to document our ideas and decisions throughout the process. Overall, it was an excellent experience.

Having our assumptions and solutions derived from the sprint available to us as we embark on building out our ideas insures that we won’t be scratching our heads when a we need to explain a particular decision to the developer responsible for implementation.

---

As stipulated in the goals we established before the sprint, we were able to gain a better understanding of the activities involved in the design sprint process. The ideas we developed during the sprint are far stronger than what any one of us could develop on our own, and I believe Goodbits will be a better product as a result of the thinking we did during this sprint.

Then, the bad

There were two fundamental flaws in our approach to our first design sprint.

Scheduling

Scheduling our first sprint into a 4-day schedule was a mistake. Our team had never completed a design sprint together, and thus spent considerable time understanding each activity and its role in the process. I believe as we gain a deeper understanding of each activity, we will develop the ability to move from activity to activity far more fluidly.

By scheduling the 5 phases of the design sprint over a 5-day week, each phase experiences a natural beginning and end. You can show up to the office, begin the day’s phase, and be more relaxed knowing that you won’t have to switch mental contexts until the day is done.

The cognitive expenditure of switching from phase to the next in the middle of a day proved to be rather taxing on us. This is likely exasperated by the fact that the process was new to us, but I’m not sure that’s entirely to blame.

As each phase of the process builds upon its antecedent, it is important to carry each phase through to its natural completion. There should be no lingering doubt that the goals established for each phase were successfully accomplished. By scheduling each phase down to the minute, not enough time was left to reflect as activities were being completed, causing us to rush through decisions just to keep moving forward with the process. Many activities were only half finished or worse, ignored altogether.

Though we had scheduled our activities down to the minute, interruptions throughout the week caused our forward momentum to become inert. I bare much of the responsibility for this — I accepted requests for meetings at times when I knew I was meant to be focused on the sprint. Back when I was a freelancer, these interruptions could be mitigated by the fact that I was working alone more often than not. When two other people are waiting for you to wrap up a podcast that was rescheduled to a time you were all meant to be prototyping, it can be tragically debilitating to progress.

There were several times I felt I was being brought back up to speed on discussions I had missed. Perhaps this could have been mitigated by better documentation, but that too requires either further resources to be assigned to the sprint or a slow down in productivity on the part of those participating.

The elephant is the room

The room where we engaged in this week’s sprint was our company board room. Brewhouse works in a loft apartment which has been converted into an office. Our board room is a dark, narrow room with windows looking out at a brick wall two feet away and a sliding door which acts as a somewhat ineffective white board.

But worst of all are the chairs. Due to Brewhouse’s disdain for meetings, a decision was made early on to purchase chairs which would act as a deterrent from spending too much time in the board room. However, if collaboration is a value that we care about at Brewhouse, we should care about designing a space that best supports our collaborative efforts. There were many times we simply wished not to be in that room, even though the actual work we were doing was both challenging and engaging.

What’s next?

This week I plan to schedule a retrospective on our initial design sprint, so we can do it again the following week for another area of Goodbits. I want this process to be ingrained in us to the point where it becomes routine, so that the output of our work is of the utmost quality.

※ Permalink for “Our first design sprint” published on date_to_rfc822