Transitioning My Career

Last June, I left my full time employment designing software. It was a bit rough, but I’ve been running Oaktree Media part time since 2009 so I had a lot of work to fall back on. With my departure from the 9 – 5 job, I thought it would be a good opportunity to put a bit more effort into Music Lives. Since then, we have launched a magazine (now newspaper) and opened a space-sharing office with 6 other people. It’s been quite a ride.

Along with the increased focus on Music Lives, I also started picking up a few volunteer based or “pro-bono” jobs to help get my name out there. While working for free when freelancing is your only source of income may seem like a crazy decision, a few of the projects have led to more paying gigs, so I’d consider that a good business move. Beyond that, though, volunteering my time and skill set meant that I had the opportunity to work with some organizations who’s goals and ideals align very much with my own. One of these organizations was Transition Guelph. If you haven’t heard of the Transition Movement, I highly recommend watching the video below. It’s a bit long, but eye-opening.

After my experience with 52 to green, I’ve become passionate about learning more about environmental movements, and the motivation behind the Transition Movement is something that excites me and fills me with hope. Over the last year, I’ve had the chance to work with some amazing individuals who share my passion for positive environmental change, and the new Transition Guelph website is one that I’m really passionate about. Since meeting the TG crew, I’ve also done work with eMerge Guelph, The Guelph-Wellington Task Force for Poverty Elimination (new site coming soon!), and Minga Skill Building Hub. I also worked with a New York based not-for-profit through Catchafire called Folk Arts Rajasthan. All the projects have done more than put money in my pocket – they have been incredibly rewarding and work that I am truly proud to be a part of.

Coming soon, I may have the opportunity to work with one of these organizations on a more full time basis. The position isn’t 100% aligned with my work history, but I’ve never been more excited about an opportunity. I have realized over the last six months that there are certain ideals that I strive to maintain, and working with organizations and in industries that support my ideals makes the work more fun, more passion filled, and more rewarding. I believe that this realization has marked a transition for my own career. No longer will I be satisfied to simply earn a paycheque. I choose to hold out to find work that I enjoy doing on a personal level, and I believe that quality of my websites will improve.

I am also beginning to really understand how the work I can do building websites and sharing messages fits into a broader picture through communication strategy. This understanding now opens up a number of doors for me to work with awesome people to help the right message reach the right audience. Being passionate about what I’m creating allows me to see the broader picture, and how all the pieces fit together.

While I might not be making as much money, I know that I’m putting my skill set to use to help solve some very important issues, help some very amazing people, and feel more morally aligned with the work that I’m doing. 

Running a Non-technical Startup

Over the past few months, my life has transitioned a fair bit. I’m not longer designing software full time, but I have been working on a number of personal projects. One of those projects in Music Lives, a website that a friend of mine and I launched a few years back. Music Lives helps promotes local live music events in my hometown of Guelph, Ontario. You can check it out at Go on, I’ll wait here…

Back? Who knew that a city the size of Guelph has such an amazing music scene, eh? That’s what we think too, which is why we’ve taken a few steps lately to help Music Lives reach the next level.

Printing a Magazine

The first thing we decided to do was print a magazine. We were generating enough content from the blog to fill out a 20 page magazine with little effort (or so we thought). Our goal was to print off the magazine on our own to try and minimize the cost of printing. We ran an Indiegogo campaign and raised enough money to buy a cheap printer and get our first edition out the door. Since then we’ve launched two more editions and the magazine has been really well received.

Registering as a Not For Profit

Because really, we aren’t trying to make a profit – we are trying to help out the local music scene. After looking into grants to help fund the magazine, I realized we would have much more success as a NFP. And we don’t really have a solid business model, so it was move that just made sense. We found some friends to make up a board and sent the paperwork in to weeks ago. We are really excited about the opportunities available in Guelph to help out with the local music scene, and registering as a NFP gets us a few steps closer to turning those opportunities in to reality.

With these changes to our operation, that has been a lot of learning happening lately. Aaron and I were hell-bent on printing the magazine ourselves to have full control over the process, and I’ve learned what makes for good layout in a print magazine versus online webapp or website. I’ve found myself retelling people the stories of how we have changed our process a fair bit and it wasn’t until recently that I realized that all the pitfalls of running a software startup also apply to starting a non-software startup.

Product Market Fit

While pointing fingers at music fans is easy enough, getting people of all ages and demographics out to live shows night after night, band after band, can be a challenge as any promoter will testify. It may seem that Music Lives has a very specific market that it caters towards, but as we are reaching more and more people, we have found that our initial assumptions about who we wanted to reach have changed. Aaron and I both have friends that we know will go out to every show – the goal with Music Lives is to reach NEW people that don’t already know what an awesome scene we have.

One of our long term goals is to break into the university crowd. The University of Guelph is home to 2000+ undergraduate students that make up the bulk of the nightlife in the downtown core. Many of them will hit up dance clubs or sports bars rather than going to see an awesome live show by a local indie band. We want to change that. We want the students to be a huge part of our market, but it won’t be something that happens easily. Finding the right product for that market, and developing the right strategies for reaching them is going to be an important part of our long term plan.

Being Agile

I mentioned briefly above that Aaron and I REALLY wanted to print our own magazine on our own printer. We were convinced that it would save us overhead, keeping the operating costs of printing the magazine cheaper than if we outsourced the job. Well, after three months, I can say with 100% certainty that that is not the case. We tried two printers, two types of paper, toner versus ink, refills… and it was still cheaper to outsource the monthly printing. Mind you, we managed the find a very cost effective print shop in our province that ships for free.

The point being here: we had to revise our plan, give up on initial assumptions, and grind through the pain if we were going to succeed in the long run. While we aren’t necessarily following the agile principles of software design, we are staying true to the dictionary definition of agility and keeping light on our toes.


Ugh. Funding. It’s the last thing we want to deal with, but with the addition of the print magazine, we now have overhead costs as well as the fact that Music Lives is taking up a significant portion of both Aaron and my lives. Registering as a not-for-profit was an excellent way to increase our likelihood of finding grant funding, but doesn’t guarantee that we will even cover our costs over the next year.

As an alternative, we decided to hit the streets looking to local business and members of the music scene to help us get the ball rolling. We now have one official sponsor of Music Lives, with a few more potentials on the way. We are also selling ad spots in the magazine that will make sure that we aren’t digging too deep in our own pockets to fund what we love doing.

Wearing Many Hats

If you’re ever read a job description for a position working at a startup, one of the requirements is that you know how to do a lot of things really well. Over the last 3 months, I’ve worn the hat of designer (I wear that one pretty well), sales person, marketing, support, technical services, journalist and finance. I’ve written grant proposals, haggled down costs, interviewed bands, designed advertisements, and posted some events on the site when I have time! If you’re ever looking for experience in a specific field, my advice to you would be to join a startup because you’ll be doing a little bit of everything.

Who knows what will happen to Music Lives over the next year. I’m sure we will grow, but I’m not sure in which direction. And like any good software startup, we will continue to be innovative and respond to the needs of our users in order to consider the project a success.

Design Thinking

Design thinking is a pretty broad term that refers to the approach that problem-solvers use to troubleshoot complex problems, collect information, and find solutions. Traditionally, design thinking has been employed to tackle design issues, namely how to build a new product or solution to solve a problem that exists. If that feels like a really general definition, it should. Design thinking approaches can be applied to almost any problem that exists in the world. It’s a problem-solving approach that breaks away from traditional analysis, and employs empathetic, creative, and (hold on to your hats) emotional strategies for getting to the root of the problem.

Design ThinkingFor those of us who have worked in the creative field, design thinking is a nice way to label what I consider good brainstorming techniques. One element of design thinking is the solution-based approach that it uses to look at problems. What that really means to me is the design thinking approach to problem solving is inherently productive. It seeks to find a solution to the problem while taking time to define the root issues of the complex problem.

While there are many techniques and approaches which fall under the design thinking umbrella, there is an article published on FAST Company that does an excellent job of breaking down the basics and I’ll use that as a template:

Define the real problem

The really appealing part of design thinking for me is the way that you define a problem. Often, problems present themselves wrapped in layers of subjective, confusing details. Getting to the root of the problem can often be difficult for people who are emotionally invested in the issue being addressed. The design thinking approach for getting to the root of the problem is primarily concerned with one question: WHY?

Remember when you were a kid and you realized that statement could be countered with the question “why?”. I’m sure we all have conversations with teachers, parents, and friends that went something like this:

boy and cooked vegetablesKid: Why do I have to eat my vegetables?
Parent: Because you do.
Kid: Why?
Parent: Because they are good for you.
Kid: Why?
Parent: Because they help your body work properly.
Kid: Why?
Continue on to parent giving up…

Despite how annoying this pattern can be, it’s so important in understanding why we behave in certain ways, and forces us to question regular behaviour. Design thinking looks to find NEW solutions, and that process really requires diving into the everyday behaviours that we assume to be true. The a-ha moment in design thinking often comes when you realize half way in to the problem definition phase that there is a habit or behaviour that is actually contributing to the root problem. Once you make that discovery, you can switch gears and start thinking about how to change that behaviour.

Create and consider all options

I think one of my favourite things about the design thinking approach is that it is brainstorming in the truest sense of the term. There are no bad ideas. There are no dumb questions. Everything should be taken into consideration when building a solution to a complex problem.

You can’t solve every problem with the same solution. Too many organizations fall into bad habits and patterns of using the same tools, people, and ideas to solve different problems. Design thinking prescribes this brainstorming activity to try and break the mold to find new and different ways to approach problem solving. While 95% of the ideas may not work, 5% will be more efficient, longer lasting, and simply better solutions than what you’re already using.

Sometimes it might feel like you’re moving in a silly direction with a troubleshooting exercise, but it’s only when you reach the end that the thought pattern informs you and gives you greater insight into the complex problem you are trying to solve. If we didn’t give ourselves to explore all the possibilities, that insight would be lost.

Reframing the problem

One great way of brainstorming to look for new ideas is to reframe the problem. I took a design process class last year, and we were tasks with a generic problem that each student was expected to explore on their own. The biggest problem I had (along with many of the other students) was coming to a solution to early in the process. Most of us saw the problem laid before us and instantly wanted to start developing a solution. Instead, we should have taken time to do research, explore different options, and develop prototypes.

BrainstormingIt wasn’t until we came to the “reframe your problem” week of the course that this approach truly took hold. Trying to work backwards from a solution to actually re-define the problem is exceptionally challenging, but often extremely rewarding as well. Reframing the problem really comes from asking the design problem question in a different light.

Recently I was working on navigation restructuring in TribeHR. I wanted to create a simpler navigation system that was going to grow with the app. I decided to approach the problem by listing out all the different actions that can be taken in the app and look at the navigation from that approach. It was a really successful process, and I was happy with the solution that I had developed. But rather than going to town, I figured I would try reframing the problem as I had recently in my course. I asked a new question: “What KIND of actions are users looking to complete?” I started listing all the tasks that people do in the app, and what triggers them. I ended up coming up with two categories 1) app-driven behaviour (actions that people do in response to something that happens in the app) and 2) real world driven behaviour (something happens in day to day life that requires you to log in and complete a task in the app). While this understanding didn’t pan out with the navigation restructuring, I realized that if we could maximize the app-driven behaviour, in the form of notification, we would have a better chance of drawing the user back in to the app. Now as I design out more features, I look for smart uses of notifications to engage the user!


Stuck in the SieveAt this point in the process, you should have a ton of awesome ideas on how to approach your complex problem. It is now time to take those ideas and refine them into an action plan. Sometimes multiple ideas from the brainstorming session can be combined to form a solution. Sometimes one idea will stand out in the forefront. Taking those ideas and forming actionable items that can be tracked and measured is a great way to move forward.

This is also a great time to break down the big picture ideas into smaller tasks. Smaller, actionable items are not only less daunting, they are more likely to get accomplished.


As I’ve mentioned before, it’s okay to fail. Failing just means that you’ve crossed one possibility off your list of solutions. Head on back over to your pile of ideas and try again.

Execute and Learn

One of the great qualities of design thinking that has been adopted by so many start up companies is that methods which they use to execute, and in turn, learn from mistakes. While the whole process is focused around creating many ideas, filtering down to a few, and then discovering a solution, the true value is the way in which you execute, sometimes fail, and then start over.

If you have used this process, failed, and iterated, sometimes you’ll find that the problem that was defined early on is actually a problem that isn’t best solved by you, your team, or even your company. Some designers will claim that you should have a solid solution by the time you’ve made your way through the design thinking process, but I will argue that you can never stop learning and never stop making mistakes.

Keep Learning!

Looking for more resources on design thinking? Look no further:

Humility and the art of revision

As a designer and an idea person, I often get carried away with new ideas and designs. I’m a brainstormer, and when I hit something that I like, I have a habit of latching on … hard. Most of time, however, my ideas are just that: ideas. They tend to be really big picture at the beginning, and rarely based on customer or user feedback. As a result, when I start diving into the details, ideas that seemed awesome at the start fall apart quickly and leave me feeling a bit disappointed.

I am not alone in this behaviour. I am fortunate to know a lot of people who love big thinking and design. One of my best friends used to have a blog titled

So the question becomes, how do we take these great ideas and turn them into great solutions?

squareLogoWhitespaceRecently, I’ve been working with a number of friends on a new project called Eleven Media. The goal is to provide up and coming bands with little or no money with a solid online presence. This means a professional website, photoshoots, maybe video or recording depending how far along they are. The initial idea came because Aaron and I noticed that so many bands are using services that take a cut of the record sales, and don’t actually have a home on the web. Since we planned on offering the service for free (taking kickback from any online sales in the future) we thought bands would be all over it.

They weren’t. 

In fact, most musicians and bands Aaron spoke with flat out turned down the service saying it wasn’t something they thought y could make use of. We were obviously confused. Most people pay money to have systems like this custom built for them. We were obviously missing something.

Do customer research

Rather than giving up altogether (which has been tempting) I set about trying to understand where the problems were in the system we had developed. I spent some time talking to promoters, bands, and musicians to figure out where our idea was flawed. The issue finally surfaced after a few pints with a friend who is part of the two piece electronic band:

Me: So would you be interested in a custom designed website?
Him: No. If I really need a better site, I’d rather learn how to do it on my own.
Me: What if you could manage all the content, add pictures, songs, and connect it with all your other social networks?
Him: That sounds like a lot of work.
Me: What if I could give you the ability to sell your own music and merch without having to pay another website a cut?
Him: *Eyes instantly brighten* YES. That sounds good.

In that quick conversation, I learned where the problems were with our proposed idea, and what actually had traction that we weren’t paying enough attention to.

Listening to customers is not a new concept, but often user experience designers will tell you to get something in front of your customer in order to get feedback. Prototyping is a great way to get feedback on workflow, design ideas, and general user interface elements, but when you’re working with the initial concepts, and nothing tangible, it’s hard to find the right questions to ask.

User interviews are not a new concept. People have been using formal interviews to help establish market research for decades. In many cases, however, the early stage development of an idea can be hindered by structured interviews because you’re not always going to get all the information you need. By asking specific questions, you may be missing out on an important answer to a question you haven’t asked! So I say go unstructured and let the interviewee lead the conversation.

Being wrong is hard, but it’s also important

Our initial idea with Eleven Media was built around the assumption that bands wanted awesome websites, but just didn’t have the resources (read: money) to obtain them. When people started turning us down, we were genuinely confused. And it stung a little bit. Essentially people were telling us that we were wrong, and that never feels good.

But as they say in the entrepreneurial world, failure is an important part of building success.

If you feel confident that your initial idea still has merit, don’t give us. Regroup, refocus, and relaunch. Every time you’re wrong about something, it gives you the chance the learn, grow, and then be right about it next time!

Revising big picture ideas

When we learn that our initial awesome amazing idea was wrong, it’s sometimes hard to bounce back. The natural reaction is to throw out the idea and maybe, or maybe not, start over again. Maybe I’ve been working in an agile workplace for too long, or maybe it’s just starting to have positive effect on my design outlook, but I think a better approach to trashing a project is to simply revise and move forward. Just because you weren’t right the first time, it doesn’t mean that you have to be wrong forever.

If you have the chance to talk with potential customers, running elevator pitches past them is great way to gauge if you’re on the right track. Brainstorming with like minded people is also a great way to get feedback on changes that you want to make to big picture ideas. If you’re lucky enough to have entrepreneur meetups in your area, make use of that resource (I’m totally guilty here…) and see what other professionals think.

Last but not least, translate your ideas into marketable materials and see how they are received. Eleven will be launching a new website next week with the changes and ideas that I’ve heard from other people. I’m feeling more confident in my ideas now based on the revisions that we’ve made. Ultimately I know that we are providing a better service because I knew when to give up on an idea, and how to recover by revising rather than discarding!

User Experience Design Isn’t Always Pretty

Behold! My beautiful white boarding skillz! Not quite a work of art...

Behold! My beautiful white boarding skillz! Not quite a work of art…

This is one that has taken me a long time to learn. Often, I look at other designers’ work with awe and reverence because it’s so damn pretty, and wonder why I can’t make pretty things like they do. I get jealous and frustrated because I really don’t have the opportunity to practice my skills on cool typography, textures, lighting effects, or colour schemes. I work in the same software application where many of the design patterns are already established. Every once in a while I get a chance to make some cool new UI element, like menu tabs, but for the most part, the look and feel needs to stay consistent with what has already developed. No new shiny buttons for me :(

As a designer, I love making things pretty, but I’ve realized that my job has become much more than that. There are periods of time where I don’t open Photoshop for weeks. I spend more time in UXPin and white boarding, in meetings and listening to client pain points (and sometimes praise!). And while I long for the chance to learn new Photoshop skillz, for the most part, I’d rather be using big picture design strategies to problem solve user experience issues.

Creating Pixels versus Big Picture Problem Solving

As the digital design world becomes more stratified, I think there are some places where the graphic designer and user experience design roads cross, but for the most part, they are diverging more every year. Design thinking plays into both professions, but I think user experience designers spend a lot more time thinking about the big picture and theorizing about workflows, where graphic designers get to spend more time focusing on the details and making truly beautiful works of art.

I love browsing Dribble to see what people are making. I am awestruck at some of the work I see being created by such talented individuals everyday:

WeSC by Martin SchmetzerIcon 2 by Tunguska_eventDiva Liebe - book cover by Michæl Pauknerrocket by CDY

These are things that take a lot of time, patience, and practice and I’m honestly really jealous that I don’t have those skills. But, I can’t beat myself up too much, because my skills are just as important to software and web design; they just exist a bit more behind the scenes.

To add in the infamous Jared Spool quote: “Good design, when it’s done well, becomes invisible. It’s only when it’s done poorly that we notice it.”

Simon Norris does a good job on his blog talking about how good user experience design is invisible. This is a UX catch phrase that is a bit under debate right now, but I think that is only because it depends on how you interpret the phrase. I think invisible is a bad word to describe the way people use things that have been designed well. I think a much better (although less impactful) word is intuitive. Good user experience design doesn’t stop you in your tracks, and very rarely brings about strong emotions, but often just makes that user say to themselves, “Huh. That was easy.” There are no works of art, nothing beautiful to look at, just internal warm fuzzies that a user gets for a job well done. In that sense, good user experience design isn’t completely invisible, it just doesn’t stop you in your tracks.

Finding the balance

It’s unlikely that I’ll ever be totted as one of the best designers out there, because I don’t create tangible works that can be displayed. Okay okay, I do sometimes and they fall into the realm of customer website that I make through Eleven and Oaktree. But even in those cases, I’m designing for a client and trying to push the boundaries of creative expression can often be quashed in the name of familiarity and simplicity. I try to push the limits of my website design, but I still lack a lot of the graphic design skills that designers use to make those tiny details that shine. As I move forward in my career, I think I will try really hard to keep both types of design in perspective. For the design that can master both will ultimately create better experiences across the board.

If you’re looking for more on what makes great design in both fields, and how they tie together, take a look at Smashing Magazine’s chapter from one of their eBook’s focusing on Visible versus Invisible design.

For more of my work, visit Oaktree Media. You can always get in touch with me if you have any questions!

UX in Agile

We are jumping right into the meat here. I know this blog is pretty new, but this problem is not, and it’s one that I deal with every day.

How do user experience designers fit into an agile development team?

If you’re unfamiliar with agile development in a software environment, it’s a process of building software that comes from the Agile Manifesto:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

For a more practical explanation, agile develops in short, fast sprints, releases often, and iterates on features rapidly. Die-hard agile fans will tell you that there is a right way and a wrong way to employ agile methods. Most companies, however, use the strategies slightly differently to learn what works best for them. At TribeHR, we are always changing and adapting as the company grows and we find strategies that work well for our team. One challenge that we have always faced is how to fit feature design into the agile process.

To fully explain the problem, I’ll quote some UX experts that were interviewed for UXMatters:

“Agile is a development methodology and UX design is a design methodology, so right there is a reason why there are gaps,” answers Tobias. “Principally, in agile development, developers are fully aware that they don’t have all of the inputs and knowledge up front—that is, they don’t know what the final product will be like until they’ve completed the last iteration’s build. During each sprint, the team looks at a part of the whole product and works on that. Therefore, the team acquires knowledge and understanding during the individual sprints. Yes, there is a master set of features that the team determines up front and that carry through in the project’s backlog, but there are a lot of issues and details that they’ll identify during the course of the project. For an agile purist, there’s nothing worse than ‘Big design up front.’
In contrast, in UX design, we want to know everything that’s relevant up front; that’s why we make so much effort to carry out proper context-of-use analyses. We want to anticipate and envision the product holistically—and not just its parts—as soon as possible. What will it look and feel like? This does not mean that we take only one shot at the design—we do ideate and iterate, but we typically want the knowledge to be as complete as possible at the beginning. For UX folks, it’s all about the big design up front, because we want to define and design the product as one holistic user experience and, at the same time, minimize concept ambiguity during implementation.”

To summarize, good design requires time: time to think about the feature from different angles, time to brainstorm, time to research, time to wireframe, and time to collaborate. When that time is taken away, the result is often a poorly designed experience that misses the mark. For development, that’s ok – the agile method tells us to iterate, fix, and release. For user experience, however, that method doesn’t work so well. We don’t want to constantly be changing the interface that users see. Also, we want to make sure that we’ve done the big picture thinking about how the feature will fit into the software before we even start working on the details.

So, now we have a good grasp of the problem. As I’ve mentioned, this is one that I’ve been working in everyday for the past year and a half. Over that time, I’ve tried a number of different strategies, but I’ve never really been satisfied with the results. Until now. Over the past two months, I’ve been tweaking this process to attack epics from a design perspective. Ideally, this process takes place a week or so before development, so having a good backlog prioritized is key!

Designing in an agile environment

1. Define the problem.

The first step in designing a new feature is to look at the problem that you are trying to solve. The definition of this problem comes from a few different places: the customer, your support team, stakeholders. What exactly are you trying to accomplish? It’s important to get to the root of the problem, rather than getting potential solution input (eg. the profile list should allow me to do X is not a problem. As a user, I can’t find a way to do X is the problem).

2. Hypothesize a big picture solution informed by the design principles.

In my last post, I talked a little bit about design principles. I am a firm believer that each project should have it’s own principles. Here’s a great example of some principles to borrow from designer Joshua Porter. Once you’ve decided on principles for your project, use them to help solve design problems. Look at the problem in the perspective of the software as a whole. Whiteboard, brainstorm, reframe, and come up with some initial assumptions that can drive your solution.

3. Break it down so that you can take small steps keeping the big picture solution in mind.

Here’s where we get a little more “agile”. Once you’ve got a good grasp on how you want to solve the problem, break the solution down into smaller pieces. Even a complete site redesign can be broken down into navigation, content area, footer, blog posts, etc. Agile is all about doing one thing at a time rather than everything at once.

A great example of this is my current project at TribeHR of updating the navigation structure in the software. The general goal was to improve the visibility of different areas, and increase the speed at which users could move around the software. This was broken down into a few different steps:

  1. Update the main navigation
  2. Include drop down menus
  3. Give users access at adding new items easily
  4. Give users access to administration tools easily
  5. Give users access to related reports

These five steps help improve the overall navigability of the website, and are much more likely to get built in a sprint that undertaking a whole “Improve the navigation” story.

4. If replacing a feature, take baby steps towards a new workflow rather than removing one altogether.

It happens to everyone: you release a new feature and users start using it in ways that you didn’t anticipate. The workflow is wrong, the feature isn’t properly integrated with the rest of the software, the results are poor. It’s time to revisit the feature as a whole. You get customer feedback, do some competitive research, and embark on version 2.0.

I know how it feels to have a major feature that you don’t like in your software. The knee-jerk reaction is to rip it out and start over, trying to solve all the broken things at once. The problem with this type of solution is that it usually reproduces the original problem. You can’t monitor the results of a huge feature change that completely changes the interface and workflow. Rather than tackling the whole thing at once, the agile process prefers that you make small changes, and then monitor the results. Try re-factoring one step in the workflow and see if that increases usage. Add or remove elements and talk to your support people to see if they get any feedback. Taking baby steps ensures that you can monitor the changes, and allows you to confirm (or deny!) that the changes you are making are the right ones.

5. Spec with customer and development.

Making sure everyone is in the loop is so important. No one exists in a vacuum, and everyone on your team has knowledge that they can contribute to designing a solution. At Tribe, I make good use of our customer-facing people to make sure I know what the problem is. I also go back to them with a solution when I have some rough ideas. Bouncing solutions off of customer support reps can often generate excitement AND make sure that you’re addressing the problems that the client is presenting.

At the same time, I’m no developer, and I don’t want to create a solution that is over engineering. While I’m working on a spec for the feature, I make sure to run everything passed at least one member of the development team to ensure that I’m not designing a behemoth.

On that note, it’s also worth mentioning that our feature specs are not strictly technical. We use them for communicating with sales and development a like. The specs are written in friendly language (with a technical section at the end of the code talk), using scenarios to outline the need, problem, and solution, screen by screen details, non-goals, etc. Making specs that everyone can read and understand benefits EVERYONE in the long run.

6. Wire frame / design

Once the spec is done, the stories, have been created, and the iteration is planned, I can look out a few weeks in advance to see what specifically is coming up. If anything touches the user interface, I try to make sure there are either wire frames (we use UX Pin) or high def Photoshop mock ups for non-interactive stories.

7. Build and release.

Enter the regular agile iteration! Ideally, every story has a spec and wire frames associated. One spec and wire frame may cover a whole epic, but at least the developers are informed on the bigger picture while being able to dive into the details.

8. Test everything.

Unless you have a close relationship with all of your users, it can be really hard to tell if a feature release has been a success or not! For UX designers, track hits is often not enough. We need to know HOW the user is interacting with the new feature, and this is something that I’m still learning on how to track. We are currently using a combination of Google Analytics and Apptegic to test how features are being used. We also have some product champions that give us regular feedback, which is awesome!

Getting metrics is one of the most important and often enjoyable parts of my job. I find it really cool to see how many people are using the software, what people seem to enjoy, and letting the user really drive the process of improving the software.

9. Revise the hypothesis based on the results.

Sometimes, looking at the metrics can produce results that you didn’t expect. Dan McKinley from Etsy gave a great presentation on his experience on building out a new feature that didn’t go as expected: Infinite page scroll. His presentation was one of the major influences to my current process. What we can take from his experience is that things don’t always go as expected, and sometimes you need to revise your original solution based on the results.

Don’t be afraid to make changes! That’s what agile is all about, right?

For more of my work, visit Oaktree Media. You can always get in touch with me if you have any questions!

Designing Websites versus Web Apps

Growing from websites to software

When I started my career as a web designer, I really had no idea where it was going to go. The field of user experience design really hadn’t been born when I started my post secondary education, so I wasn’t aware of what my options were. I knew that I like building websites and I knew that I was pretty good at coding, so after I finished up my B.A., I decided to pursue web design.

Moving through my career, most of my jobs have been designing and building websites for businesses and organizations. The SaaS and web based software model didn’t come along until more recently, and that’s when it all really came together for me. I realized that I could take my design skills for websites and apply them to software. The idea was pretty cool for me, because it really gave me time to focus on the behaviour and patterns of users in the software, track usage, and actually make edits to the interface based on that behavior. Pretty cool stuff.

Don’t get me wrong, I still love doing websites. If I didn’t, I wouldn’t have started Oaktree. But there are perks and downsides to both types of web design, and I’ll focus on those differences below.

Designing with the user in mind

The primary different between designing web apps and websites is the user. The intentions of someone visiting a website are totally different than what people expect to get out of a web app.

Most web apps out there have a specific purpose. Facebook focuses on connecting with friends and sharing information. Pinterest focuses on social bookmarking. Soundcloud focuses on sharing music. Even business apps like TribeHR focus on booking vacation time or filling out a performance review.

Websites, in contrast, are designed to give your customers information about your product or service. The focus of small business websites, as a general rule, are to share information about your company or organization, NOT to perform specific tasks.

The difference for the user is huge. As a designer, we need to hone in on each focus of the website or app and design around that workflow. Keeping that in mind, let’s move forward.

Navigation structure

Most company websites can actually get away with a basic navigation structure: Home – About Us – Services – News and Updates – Contact Us. Because of the nature of business, the visitors on the website are likely to be interested in one of these five areas. Web apps, by contrast, have a navigation structure that focuses on the tasks that the app performs. This may seem obvious, but it one of the primary differences in how a designer will create an interface.

Marketing versus servicing

There is no need to sell when a user is using a web app. They have already bought in and are using the app. By contrast, a company website is a marketing tool. While both interfaces will need to consider primary calls-to-action, the CTA must be much more compelling on a marketing website.  When someone is using a web app, and you already have the buy in, they will be looking for how to complete tasks, rather than the website visitor who is just looking for general information. You need to draw the website visitor in.

Let’s look at a quick example:

Pinterest is a popular web application that allows you to save and share website links.

Looking at the navigation structure of Pinterest, we don’t see anything about the company that built it, or how to contact them, mostly because the users don’t care! What they care about is browsing pins, and so the navigation is structured in such a way that it makes it easier to find the type of pins that you might be looking for. Next, think about where your focus is drawn when you look at the page. There is very little in the way of CTAs. The focus is primarily on the images: the pins, which is the main focus of the application.

Now let’s look at a company website that sells a popular product by contrast:


Apple’s Canadian website focuses on one thing, and one thing only…

Take a look at the navigation. We are now giving the visitor the option of exploring more information about the various products that the company offers. Apple may not be the best example of corporate website navigation structure because they assume that the visitor already knows what the company offers. The important aspect of this page is the exclusivity of the content to one primary CTA. Visitors don’t have a lot of options when visiting the page for the first time. For the record, there are more options below the page fold, but the visitor has to scroll in order to see them.

The Differences and the Similarities

I’ve talked about the differences between website design and web application design, but it’s important to focus on the similarities as well. While the purposes of each type of design call for different elements on the screen, the process of creating both designs should have some of the same steps.

Design with a purpose

Before starting ANY design project, it’s important to outline the goals of the design to keep yourself focused. With TribeHR, I have 4 main design principles that help keep me in line:

  1. The user should always be in control.
  2. Good design is invisible.
  3. One primary action per screen.
  4. Consistency matters, but don’t be afraid to be innovative.

When I’m stuck on a complex design problem, turning to these principles help keep the design on track and help me make important decisions.

When approaching website design, I have similar design principles:

  1. Content is King.
  2. The market is specific.
  3. Allow the user to explore.
  4. 80% of users are looking for 20% of the content (the Pareto principle)

Just like in app design, these principles help keep me focused and help make decisions when designing company websites. The rules are slightly different but the method is the same.

For more of my work, visit Oaktree Media. You can always get in touch with me if you have any questions!

Learning to design

I thought a good first post would be something that was easy for me to talk about – learning the art of web design. I often have people asking me where and how I got started in designing websites and software. I’m pretty much self taught, so my stock answer is always “play”. But what does that mean exactly?

Play in Photoshop

There are a ton of good tutorials out there that will teach you how to move around Photoshop, which is the best tool out there for designing websites. Most of the tutorials, however, will walk you through specific actions required to create a specific design or element of a design. If you’re trying to learn new techniques, these tutorials can be really advantageous. My recommendation for “learning the ropes”, however, is to copy. Pick 5 websites that you really like and try to recreate them pixel for pixel. Quite often you will find yourself stuck because there is a specific technique that is used in the design of the site that you don’t know how to replicate. That’s where good old Google and the aforementioned tutorials will help you along the way.

Amateur Web Designer Night

Play with code

HTML, CSS and JQuery are amazing tools for any web designer. Knowing what’s possible when a client asks you for specific features can make or break a project. Again, there are ton of tutorials out there that will help you learn. Try and find some functionality in a website that you like, such as CSS sprites, a javascript image slider, or true table-less design, and practice until you get them just perfect. A great way to learn is to deconstruct other people’s code line by line to see what everything does. That’s how I built my first website when I was 14.

Play with personal projects

Building up a portfolio can sometimes be a daunting task. Try picking a topic and building a website around it. Maybe a fan site for your favourite band, or a database of recipes of your favourite foods. Learning to design and build within a theme is great practice for learning about target market, UI design and social media tools. At Oaktree, Aaron and I decided to build a website that would feature local live music events. It’s been a great learning experience!

Dive right in

When I used to start a new project, I procrastinate because I don’t know where to start. I’ve learned over years of practice that the best approach is to dive right in. If you’re starting with a website design, look for inspiration through gallery sites. Pick a style that you like and try to recreate some of the element (not pixel for pixel, mind you – just the general concept). As you move forward with the design, you’ll find that it changes and evolves as you pick up on specific elements of the design that you fall in love with – an oversized header, or an awesome font in the navigation.

After you’ve found that inspiration, the sky is the limit. Create two or three designs for every project you’re working on. Then take a break and revisit them the next day. You’ll see what sticks and what doesn’t, and ideally the end result is a beautiful, sleek site that you’re proud to include in your portfolio!

For more of my work, visit Oaktree Media. You can always get in touch with me if you have any questions!