This week marked a major milestone in my life: for the first time ever, I left the continent of North America.

I’ve long had an interest in travelling and spent a good chunk of the last decade flying and driving all over my home continent. From Burns Lake, BC to Atlanta, GA and many places in between, each city brought exciting new experiences and memories I’ll not soon forget.

As great as each of these trips has been, ultimately the foundations of North American cities share more in common than they differ. Consistently paved roads, clear and legible wayfinding, generally solid infrastructure, and — well — safe drinking water.

None of which can be said of the city where my partner and I are currently staying. While paved roads exist most are dirt, street signs are often non-existent, electricity turns off for seemingly no rhyme or reason,¹ and the water is best served post-boiling.

This city, for those who missed the news on Twitter, is Kampala, Uganda.

Home to ~1.5MM people, Kampala is the largest city in a country of over 37MM. For a bit of perspective, the population density of Vancouver — Canada’s most dense city — is 5,492/km² while Kampala’s clocks in at 7,928/km².

Of course population density isn’t the only difference between these two cities. However, when you also consider the state of each city’s infrastructure, cultural differences, and overall quality of life, it becomes clear that we aren’t comparing oranges with oranges.

Not to mention the rest of Uganda, both urban and rural.

All of this is simply to point out one simple truth: Uganda is unlike any country I’ve ever been. And as a designer that both excites and scares the shit out of me.

A couple of months ago, my friend and colleague Boris Mann introduced me to Ed Levinson. Ed is an angel investor who has has been traveling to Uganda every January since 2011 to run umpiring training camps for Kampala’s little league teams.²

Through this experience, Ed “[became] interested in the educational and entrepreneurial aspects of international development” which led to a relationship with Ugandan founders David & Gerald. Their startup, Ensibuuko, provides cloud-based banking software solutions to microfinance institutions.

These institutions — Savings and Credit Cooperatives and Village Savings and Loans Associations — serve sub-Saharan Africa’s 500 million unbanked individuals. Unlike a bank, which in Africa provides its services at rates unaffordable by many people, these microfinance institutions aim to provide people the ability to save and borrow money when doing so with a bank is cost prohibitive.

Like many other aspects of Ugandan life, these institutions lack the infrastructure commonly found in North American financial institutions. Ensibuuko aims to provide that infrastructure and to do so in a way that is native to Ugandan culture.

As a product designer, it is my job to uncover the jobs for which a customer will “hire” a product. Through a discovery process that involves user interviews and discussions around business models and strategy, I try to help founders and product managers understand what their customers need and design solutions to bring that value to the customer. Perhaps I am a bit naive, but I believe a significant portion of our collective understanding comes from a familiarity with North American culture — people, for the most part, work roughly 40 hours a week and are looking for ways to save time and get more done, faster.

Now two days into my time here in Kampala, I realize none of that familiarity applies.

And so, it will be my job to figure out how to apply best practices of product design to the problems Ensibuuko aims to solve. My hope is that the processes and methodologies I’ve learned over the last decade will help. User research, design sprints, job stories, prototyping, and user testing are the tools I intend to use to discover how to design a product for the Ugandan people. I’m sure I’ll have some missteps. Perhaps I will find it difficult to translate processes and skills I cultivated in North America to an African context. My goal is to write and share the lessons I learn along the way for those who will surely follow in my footsteps.

This past month I had the wonderful opportunity to design and develop a Shopify theme for my friends at Rye 51. While a case study will be forthcoming, I wanted to share one aspect of the site’s development that really got my gears turning.

One of our goals for this project was to allow Matt and his team the ability to publish weekly collections featuring interviews and other editorial content. Out of the box, Shopify allows you to display collections of products with a collection name and description followed by a list of products. While this is perfectly suitable for common category collections, for custom collections we wanted to include images of and links to products throughout the long-form editorial content.

To accomplish this, I employed the help of Culture Kings’ Shopify Shortcodes library to create a product shortcode. Using Shopify Shortcodes is pretty simple:

1. Install the Shopify Shortcodes library.
2. Create a shortcode using the naming convention shortcode-NAME.liquid in your snippets folder.
3. Replace tags such as {{ collection.description }} with {% include 'shortcode' load: collection.description %} in your collections.liquid file.
4. Add [shortcode] to the description field in your Shopify admin.
5. Watch the magic unfold.

The Shopify Shortcodes library comes with example shortcodes for FlexSlider, FontAwesome, and YouTube. Looking at these will give you an idea of how the library parses information passed through a shortcode. The basic structure is something like:

[shortcode-name attribute='value']

To create a product shortcode, I started by creating a file in the snippets folder called shortcode-product.liquid. The shortcode I want to provide for my client should be simple, so I’m going to use the product’s handle (or URL slug) in the shortcode, like so:

[product name='product-handle']

To pass the name attribute to your shortcode snippet, we’ll need to capture it near the beginning of the shortcode-product.liquid file:

{% capture productHandle %}
    {% include 'shortcode-render' render:'name' %}
{% endcapture %}

Now, I can use {{ productHandle }} in my snippet to pull in the shortcode’s name attribute and use it to assign product:

{% assign product = all_products[productHandle] %}

From here, it’s just a matter of using the attributes available through Shopify’s product object to display the product’s title, image, and URL.

'<h1 class="title">
    {{ product.title }}
</h1>
<a href="{{ product.url }}">
    <img src="{{ product.featured_image.src | product_img_url: '1024x1024' }}" alt="{{ image.alt | escape }}" />
</a>'

You can add other attributes, such as a float to allow the product to appear on either side of the text or to add more content. I’ve used this same method to create image galleries and fancy block quotes, as well.

Shortcodes are a simple way to give your clients the power to create even more engaging experiences for their customers.

On April 24, 2016, I quit smoking. Unlike most who take up the habit young, I started in my late twenties. It was a stupid decision to start, bolstered by my arrogant belief that I could quit whenever I wanted. Turns out, quitting is tough.

My first attempt to quit was on a drive home from Vancouver to London. Stuck in a car for four days straight was the perfect situation to quit, however my willpower wained about a week after I got back to Ontario.

I’ve tried to quit a number of times since; sometimes trying the cold turkey approach, others with the use of nicorette gum or over-the-counter e-cigs. Each time I would either quit for just a day or two, or at best reduce my intake by about half for a few days.

Sometime before April 24, I purchased a Kanger SUBOX Mini from a small vape shop in Gastown called Vaporologie. While in the shop, one of the other patrons pulled out his phone to show me an app which tracked when he had quit smoking and how much money and time he’d saved since.

I returned home with my new toy, pulled out my phone, and downloaded the Quit Now iPhone app. It’s a simple app that tracks the days since your last cigarette and offers insights and encouragement along the way.

There were some false starts in the early days, but the pain of having to reset my quit date in the app grew stronger each time.

When friends of mine and I went on an incredible two-day hike to camp at Greendrop Lake in Chilliwack Lake Provincial Park, I made the decision to not pack my cigarettes. It was a gruelling 6km hike across four boulder fields and partway up a mountain to get to Greendrop and by the time I got home all I wanted was to relax and have a cigarette.

I went downstairs, lit the cigarette, inhaled, and filled my tired lungs with that sweet, sweet nicotine.

That was on April 24, 2016 and it was the last cigarette I smoked.

Until yesterday, that is.

On August 10, 2016, I got to spend the evening with my globetrotting, skydiving brother for the first time since Christmas. His team are in town this week for an airshow in Abbotsford. Rob and a couple of his buddies came by for a couple of drinks and to see my new neighbourhood. Not long into the visit, someone suggested we head downstairs for a smoke.

And that’s when it happened.

I asked for a cigarette.

It had been 6 months since the last time my brother and I smoked together. A lot of our deepest conversations over the last few years were with cigarettes in hand. The last time (and the first time in nearly a decade) I saw my father smoke was when he, my brother, and I were standing outside of the funeral home having just carried Mom to the hearse.

I can’t blame my brother because I asked for the cigarette. I asked because I wanted one. I had been wanting one for 108 days. I just hadn’t found the opportunity for rationalization until I’d had a shot or two of whiskey in me and my little baby brother next to me. But he didn’t offer, I asked.

After a second cigarette following a walk down to the beach, I went right back to my vaporizer — a new Sigelei 213 I purchased just last week on my 101st day — and have not felt the urge to smoke since.

Last night I sat down, told my partner, and once again felt the pain of resetting my quit date again.

That was on August 10, 2016 and it was the last cigarette I smoked.

During the last phase of a product design sprint, or as part of any product design process, you will want to test and validate your assumptions and design solutions with real customers. Often, you will want to bring your customers into your office in order to perform these tests, but won’t want everyone involved in the project to be physically present in the room while the test is taking place. Complex and expensive systems have been built to allow teams to observe a user test remotely in another office, but you can replicate this experience while also capturing the test to review at a later time with tools found in most modern offices.

This approach will work regardless of the device you are designing for and is made possible through the use of Lookback. With Lookback, you can record user tests of mobile and desktop apps and websites while also recording the user’s facial expressions and eye movement as they use your prototype. These recordings can than be shared and discussed amongst your team and referred back to throughout the design and development of your product.

Though Lookback only supports native mobile testing of Invision and Marvel prototypes or native apps with the Lookback SDK installed, you can record tests of mobile websites or prototypes built with other tools. To do so, connect your device to your Mac via USB and with QuickTime or other screen mirroring application stream the view from your mobile device to your Mac. While you do lose the ability to do eye tracking, you can still record facial expressions using the FaceTime camera on the Mac.

What you’ll need

• Lookback.io
• A Mac
• An Apple TV
• A TV
• A test subject

The setup

To start, download and install Lookback onto your Mac. If testing an Invision or Marvel prototype, connect either service to Lookback and download the appropriate prototype viewer onto your mobile device. If testing a native app, install the SDK.

If testing a mobile prototype or app, connect your device to your Mac via USB and use QuickTime or another app to mirror the stream on your Mac.

Open Lookback on your Mac and the app or prototype you wish to test. You should see a video stream of the user and either the desktop app or site or the stream of the mobile app.

Then, turn on AirPlay on your Mac and select the Apple TV located in the office from which your colleagues will observe the test.

The video of your user and the product you are testing will both be streamed to the TV where your team is observing and taking notes. For bonus points, stick an earbud in your ear and have your team call you on speaker phone so they can prompt you with questions they would like you to ask your test subject (protip: if you’re observing, try not to cause the person administering the test to break out in laughter over your fart jokes).

That’s it

There’s not a whole lot more to say. With a clever application of Apple’s AirPlay and the tremendously useful Lookback testing suite, you can easily observe and capture user tests at the same time.

If you have tips or tricks for capturing and observing user tests, please let me know on Twitter.

I have two blog posts in draft form sitting in nvALT at the moment. One is about my time mentoring students at Red Academy. Another is about the hiking and camping trips I’ve taken over the last year. Add to that another half-dozen ideas that have been percolating in my head for far too long and it all adds up to feelings of disillusionment, discouragement, and discontent.

It’s never been easier to publish writing online. Hell, it’s never been easier to publish just about anything online. It’s not a technical challenge I face. It’s a psychological one.

Truth is, those same feelings apply to a number of areas in my life. I do not feel that I’m living up to my potential, nor do I feel a true sense of what the limit to that potential is. It’s not a matter of talent or inspiration or even time. It’s a matter of discipline. And discipline is born of routine.

In 2013, Julie Zhuo made a commitment to herself to write once a week. Her first post — a denunciation of January — has absolutely nothing to do with her article about Imposter Syndrome that brought her work to my attention. Nor did it have anything to do with the lessons she’s shared from her career on Facebook’s product design team. But that article set her on a path that has enriched not only her own life but the lives of thousands upon thousands of designers around the world, yours truly included.

I have long dreamed that my work would have that kind of effect. That the words I transmit over these wires would impact people the way countless others’ have impacted me. But I’ve allowed fear and doubt prevent me from even trying.

Two weeks ago, I attempted and failed for the second time to complete Shawn Blanc’s Focus Course. Despite the fact that I designed his website and had access to the content well before it was published publicly, I neglected to take advantage and allow it to cause the type of change I’ve witnessed it cause in others. It’s not that I haven’t had the time. With no kids, no pets, and an enviable work/life balance, I have no excuse.

Back when I was recording the Hundred Down podcast, one of the key things that kept me going was the accountability and encouragement from our listeners. Their support combined with that of two good friends gave me the strength to lose nearly sixty-five pounds in a matter of months. When I gave up, it had been several months since we had recorded a podcast. I had secluded myself to a windowless basement apartment and settled in for a long winter.

Save for popping up to post the ocassional offensive joke on Twitter and, more recently, share my experience working with HabitStack, I’ve still been living in hibernation.

While my team and I have been growing and building awesome products, I’ve been silent about the mistakes we’ve made and what we’ve learned from them. While I’ve been learning about and practicing design sprints, I haven’t shared my experience and how this wonderful tool can help people in any industry solve really tough problems.

That’s not how I envisioned my life would be. That’s not why I’ve spent over 10 years publishing my thoughts online. I did it so I could find a community of like-minded people who just want to create something amazing and learn from those around them.

It’s not January, but like Julie I think it’s time for me to make a resolution. I resolve to write and publish something — anything — once a week. It might not be good and it likely won’t be well-received. But if I don’t start fucking up now, then when?

After publishing my Q1 review of my 2016 goals, I was able to sit down with Scott Ward from HabitStack to discuss my strategy and progress to that point. After an hour of conversation, I realized that Scott was able to provide exactly what I needed in order to achieve my goals: guidance, scrutiny, and accountability.

I made the decision that day to personally hire Scott to coach me towards achieving my professional goals, with the hopes that once my Q2 goals had been realized, I could potentially convince Brewhouse to continue paying for Scott’s services. When I communicated this decision to the team, the response I received was even better than I’d hoped:

The company would hire Scott to aid the leadership team in setting goals and tracking progress across the entire business, starting with the leadership team.

Though this meant that I had to wait a couple of weeks before we could kick things off with Scott, I was excited that we would be working on this together. Though team had spent some time back in November setting individual goals and the leadership team business goals for 2016, we had not yet put a system in place for measuring our progress on a quarterly and monthly basis nor established the weekly habits needed to make the necessary progress.

Our team is still working on refining our 3–5 year “big dream”, but the fact that we’re working on it together makes me feel really good about sharing my Q1 review. I believe that through this experience, we’ll become much better at defining and measuring goals throughout our entire business, allowing us to improve the areas where we are struggling and celebrate the areas where we’re succeeding.

Last November, I attended a seminar presented by HabitStack founder Scott Ward in which he explained the difference between two types of work. According to Scott, work that is urgent has a deadline and a perceived risk of loss, whereas transformative work has the potential to permanently raise the business to a new level. Neither urgent nor transformative work is necessarily more important than the other. However, for a variety of sociological and biological reasons we have a natural propensity for favouring work which is urgent.

Scott argues that trying to circumvent our natural bias towards urgent work in favour of transformative work is a lost cause. The mental energy and discipline required to consciously choose transformative over urgent work is too high of a toll for our lizard brains. As such, the solution to the problem of how to focus on transformative work is to make it urgent.

Yearly Goals

This past January, I did something I had never done before: I set goals for what I want to achieve professionally by the end of the year. They are:

• Reach $300,000 in design revenue at Brewhouse
• Add 1 product designer to our team
• Attend 1 leadership conference
• Attend 1 design conference

I set these goals because they all speak to what I hope to accomplish here at Brewhouse: to build the city’s best product design team. To do this, I need to continue growing as a leader and set goals to grow and improve the team.

I set this year’s revenue goal based on what we were able to achieve last year — $121,500 in design revenue from May to December 2015 which, extrapolated for the time I wasn’t here, works out to $182,250/yr. Because our design team doubled part way through the year, our capacity to generate revenue through design doubled as well. Therefore, $300k in design revenue for a year is absolutely an achievable goal. This goal also sets us up to achieve my second goal of adding another product designer to the team. $300k will pay for 2 salaries for the first two or three quarters as we build our nest egg.

The latter two goals are geared more toward my own professional development, in the hopes that by improving my knowledge and understanding of both design and leadership, I’ll be better positioned to achieve the primary goals.

Of course, setting goals for the year doesn’t solve the problem of turning transformative work into urgent work, and that’s where goal-chaining comes into play.

Breaking it Down

During the seminar, Scott recommended setting quarterly and monthly goals which together form the habits that will help us achieve our yearly goals. This is where I believe I fell short.

For Q1, I set the following quarterly goals:

• 19 design iterations
• 2 design sprints
• Research conferences for Q2–Q4

And the following monthly goals:

• Meet with 1 less experienced designer in the community
• Meet with 1 more experienced designer in the community
• Write and publish 1 blog post to brewhouse.io

As you can see from the following screenshot, I did not do very well at following through with my quarterly and monthly goals:

See all of those red lines? Those are goals I failed to achieve. That’s right, I missed almost every single one. I believe there are two key reasons why this is:

1. The connections I drew between my monthly, quarterly, and yearly goals were tenuous at best. Some yearly goals aren’t represented at all in any of these lists.
2. In an effort to set appropriate expectations, I believe I failed to set enough goals to ensure I gained and maintained momentum.

Because there were so few monthly goals, I found I wasn’t checking in on my Trello board as often as I should have. Because I wasn’t engaging with the list of goals, I wasn’t considering them to be urgent.

Now What?

The first question I asked myself when planning for Q2 was whether or not I needed to adjust my yearly goals. Can I still reach $300k in design revenue this year? Will I be able to hire another product designer by the end of the year? Or, am I completely fucked?

After a great discussion about this with Adam Saint, I realized that I could still make this work. It would require some rethinking and refactoring of my strategy, but overall I believe I can still achieve the goals I set for myself this year. It won’t be easy, and will require more planning and discipline than I exhibited during Q1, but it is possible.

To start, I’ve added more monthly goals. “More monthly goals?” you ask? “But, you couldn’t even accomplish the three monthly goals you set last quarter!“ You’re right, I didn’t. However, the hope is that by adding more goals, I’ll be more diligent in checking in on my monthly progress and thus more engaged with what I hope to achieve. And, should I be successful in completing these new objectives, I should increase the likelihood of achieving my quarterly and yearly goals.

Also, I plan to reach out to Scott Ward as soon as I publish this post to get his feedback and also secure his coaching services to improve my goal setting process and to have someone outside of Brewhouse I can be accountable to.

And with that, I am off to write that email.

Update — Apr 7, 2016

After reading this post, Scott offered the following response:

I think your analysis is almost right. You did have too few goals, but I wouldn’t recommend adding more monthlies. To finish off the goal chains, I’d recommend adding weekly goals that contribute to your monthlies. Those short deadlines give you the urgency.

I totally understand what Scott is saying here. By setting weekly goals, you not only create an even greater sense of urgency, you also get the satisfaction of constant small wins. My friend Shawn wrote about this last year:

When we see that we are making progress — even small victories — then it strengthens our emotional and motivated state. We are happier and more motivated at work. And [therefore], we are more likely to be productive and creative.

He then asks us to consider the inverse, where we begin to feel like cogs in a machine. As much as I love working at Brewhouse, there are days where this rings true. Not all the time, thanks in large part to our constant, iterative product design and development process. But, when I’m not dedicated to a project and am spinning a lot of plates, I can sometimes feel like I’m playing a neverending game of whack-a-mole.

Scott and I plan to chat about this over coffee tomorrow; I am sure I’ll have lots more to share over the next week.

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.

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.