I’ve been giving this issue some thought lately because it seems to crop up on a fairly regular basis and I’ve come to the conclusion that the reason for my aversion is really quite simple:  lack of a shared understanding between the people paying the bill at the end of the day (we’ll call them the client) and the people doing the work (we’ll call them the service provider) on what exactly innovation means and how it will be measured. I am working on a project right now that is going through this exact pain point. We keep hearing the “i” word and we have tried numerous times to draw out exactly what the client expects from us in terms of innovation but it is a little bit like pulling teeth. We even went so far as to create a document that laid out what the client’s expectation of innovation was and how our solutions were addressing their expectations. All fine and good but we’re still hearing the “i” word which may be a case of bad communication, but I think there more to it than simply not seeing eye to eye.

I think the most important this to consider when discussing innovation is the context and domain of the product/service deemed to become “innovative”. How does the innovation fit into the existing “ecosystem”? Is it something new or is it an already established product/service? Are there customer expectations around what your product/service should do? How far can you push things before making customers grumpy? This discussion will lead directly into the details surrounding the innovation. Great ideas and innovations cannot live a vacuum and need a channel/medium for delivery so really we can’t discuss the where without simultaneously discussing the what.

It is kind of like doing a risk analysis for ideas and agreeing on how far innovations should go and if there is any real value in the proposed innovations or is it simply innovation for the sake of innovation…

Once we’ve all agreed on what innovations are going to happen where, the next thing to be discussed should be success metrics. How will we know if our innovations are working? Ideas that involve tangible products or sales are easy but service offerings are trickier simply because they are typically surrounded by more qualitative measurements and don’t translate as well to fancy pie charts and line graphs touting the awe-inspiring growth of our innovation Regardless, we still need to decide what success looks like. And now that we all agree on what innovation means to the project and how we’re gong to measure success, we can move forward and build something great, solve the problem and, most importantly, INNOVATE!

In hindsight, we should have stopped everything the first time we heard the “i” word and made sure we all understood and agreed upon the definition, scope and metrics of innovation. Needless to say, I will be adding the “Innovation Full Stop” tactic to my list of tricks.

January was the last Calgary UX Book Club meeting as autonomous entity (we have since been merged into the Calgary UX Group) and we ended on a high note by chatting with author and IA guru Russ Unger. We had heard that Mr. Unger was a lively speaker and he did not disappoint! We talked through the process both authors endured to get their book published as well as the good and not so good moments of the book. Russ explained and defended his work well and gave sound reasons for making certain decisions. I left the meeting feeling good about reading the book and, more importantly, hearing Russ’ point of view.

The premise behind “A Project Guide…” is to introduce the reader to the basics of user experience (UX) and the various methodologies, deliverables and phases of UX project work, and based on this assertion, the book is well-written. The first four chapters layout typical UX project ecosystems and serve as a great high level overview of what needs to happen in the very early stages of a project. The rest of the book is then dedicated to the key methodologies typically used in UX design work. The book deliberately did not go into much detail, and because the language used was very conversational and easy, the choice to keep the book as a high-level introduction was a suitable match for the writing style.

The best part of “A Project Guide…” is the fact that you can hand this book to almost anyone involved in a UX design project and they will find some value in it. The book’s subtitle—For user experience designers in the field or in the making—gives a clear demarcation as to the experience level of the intended audience (anyone from newbie to intermediate level UX designer) but the audience for this book is larger and that is where its strength lies.

Seasoned Pro
Make no mistake, if you are a seasoned pro who has been cranking out wireframes, doing card sorts and gathering user requirements for years you may not see the value in reading this book, unless you need a refresher on certain methodologies every once in a while (not every project goes through the same cycle of deliverables and methodology and I am certain I will be picking up this book again). There are also some chapters that I found to be a pleasant surprise. The chapter on SEO was quite interesting and refreshing, simply because I had never seen it discussed in a UX book before and it generated a good conversation in our book club as well

Newbie
If you are brand new to the UX field, looking for a great “how-to” manual “A Project Guide…” is a great find. Although the overarching theme of the book is ‘overview’, the author’s use of categories (Surfing, Snorkelling, Deep Diving) for additional information allow the reader to find out more on certain topics based on how much time a reader wants to invest; each category has an associated time allotment assigned to it with Surfing being quick and Deep Diving being longer. This system in itself is a great example of the exceptional thought being given to the user/reader and is a nice touch.

Management
I think the most interesting (and difficult to reach) audience for “A Project Guide…” would be those who don’t necessarily know and/or understand the various methodologies and deliverables typically involved in a UX design project but have been tasked with improving some facet or instance of a customer/user interaction for their company. This audience wouldn’t need to read the entire book front to back, but having a high level understanding of what to expect from a UX team wouldn’t necessarily be a bad thing… (Project Managers, Directors, VPs I’m nudging and winking at you!) Imagine a project where all the key decision makers understood what the UX team/person was doing and why—can you say utopia! I guess the trick now is how to get non-UX people to read this book…

One of the most interesting discussions during our book club meeting with Russ Unger was a conversation we had around what we want our job title to be. One of our members answered, “CEO, Chief Experience Officer.” Russ quickly responded to this with, “No, I think you mean Chief Executive Officer.” He then went on to explain his vision of the CEO of the future who will be well versed in experience design and understand the value and necessity of understanding the motivations, goals, constraints and challenges of their customers. It may sound lofty, but I think once people start to really understand the value and competitive advantage of UX design we will see more and more companies start to embrace our practice, and I think Mr. Unger is correct in his vision that if this new way of thinking starts at the top, then the entire culture and mindset of a company can be affected. Rome was not built in a day and “A Project Guide…” is a great way to get the wheels in motion towards building a business around the people who matter the most, your customers.

My aggravation: another mobile device stencil. And the Whoville culprit? For me it’s the Nokia S60 smartphone stencil (conveniently supplied by the manufacturer).

Oh sure, I realize I’m skipping stones in a glass house here, with my share of iPhone, Android, et al. stencils in my Omnigraffle folder. However, I think it’s time I say enough. There has to be a better way.

So, I’m proposing a moratorium on custom smartphone stencils. Call me a luddite, a heretic, but as an interaction designer, do I really need half dozen icons to illustrate “phone” or “contacts”? Well, I’m saying no, generic, reusable icons are just fine.

While I can appreciate the need for some IxD professionals to showcase their visual design chops by making stunning, high-fidelity wireframes and prototypes, I’m of a different mindset. I prefer to use the same amount of time thinking critically about the problem. And if a more generic icon gets the same thinking across, in less time, bonus.

What if I had to build custom stencils for every website wireframe or application prototype? It would be insanity, as well as incredibly costly to the client.

So, I’m sorry Nokia S60. While your stencils are pretty, I am taking a stand and will not be clicking the ‘download now’ button.

There’s often a temptation in larger companies to staff up for positions when looking at a long-term engagement. Creating entire departments has the outward appearance of answering concerns about accountability and professionalism. After all, how committed does that contractor need to be to your end goals, and how likely is that person going to adopt your corporate culture? Maybe those simply are not the right questions.

Here’s a better question, for starters. Where is the voice of your user? If you’ve hired an internal user experience professional, given them the standard company onboarding and set them in front of your senior stakeholders, how objective can you expect that person to be? Chances are, your company IA will eventually stray toward your company’s business goals – possibly jeopardizing the user experience.

Remember, the contractor you bring in to conduct stakeholder interviews, build wireframes and prototypes or perform usability analysis and testing is your user champion. By being airlifted in from outside, that champion lives and breathes the life of your user, unaffected by company politics, internal corporate structure or goals for personal advancement in the organization. If that person seems like a maverick, it’s only because he so closely resembles your real world users.

Wait a second, you may be thinking, how do I keep that rogue IA on schedule and meeting my all-important deadlines? Now, that is a good question…time is money, right? But once again, the contractor model seems to win out. When your user experience architect is a full-time hire, he might have more of a vested interest in keeping that project chugging along indefinitely – since the light at the end of the tunnel might signal the end of the job. Contractors, on the other hand, know that there’s another project waiting in the wings with someone else. They’d prefer to get your job done and move on, hired guns that they are.

So, now the sensitive question. What’s it going to cost? You know those contract user guys are going to run you some serious dollars, while your HR department is also telling you there’s room to add a few more bodies to the company payroll. Even factoring in benefits, paid holiday time and other intangibles, the internal hire may be more attractive on the balance sheet. But look again. That contractor might be long gone and finished the job ahead of schedule while you’re still finding busy work for that full-timer. Plus, with the added benefit of a superior user experience (generally speaking, of course) you can have the satisfaction of knowing you’ve met your real goals.

Now, I’m not suggesting you race out and only hire contract user professionals. That would be revealing my own vested interests too much. If your company has the resources to have both, then you really are getting the best of both worlds. The fraternity of user experience is deep, and professionals in the field work well together. So why not cover the complete spectrum that spans user objectives and business goals, with external influences nicely complementing internal knowledge.

In the end, it is all about creating the best possible user experience. Start by looking outside your door, before closing it and trying to figure it all out from within.

Prototyping techniques range from rough sketches on paper to hand-coded HTML. Tools like Axure and iRise allow non-programmers to develop interactive HTML prototypes that approximate enough functionality and fidelity to cover most testing requirements.

When planning a prototype, there are two basic questions to answer. First, what level of fidelity and functionality do I want? This will determine which tool or technique you use. Second, how am I going to test the prototype? This can range from showing it to a few stakeholders to setting up full usability lab testing with a group of typical users (which of course costs more).

But before you can answer these questions, there is a more important question – what exactly is the problem you need to solve, the question you need to answer? A clear sense of these priorities is vital to cost-effective prototyping, since you only want to develop enough prototype to solve these problems or answer these questions.

Two examples from recent UX Guys projects:

Online Store

As part of a redesign project for a telecommunications company, we developed an online store environment for ordering complex TV, internet and phone products. We built a series of high-fidelity prototypes in Axure to test two different interface concepts. The prototypes were first created as functional wireframes, then once we finalized the logic and flow, we added content and minimal skinning with graphic elements to create the illusion of a real web site for test users.

The first interface concept was a traditional catalogue in which products were grouped by a hierarchy (e.g. HD vs. non-HD TV service) then a good-better-best order for different products (e.g. numbers of phone features or TV channels in different packages). The second, alternative concept was an “assisted-selling tool” that made product recommendations based on how the user answered questions about their preferences and intended usage needs.
The prototypes we developed included readily available comparison tools and progressive-disclosure techniques such as roll-downs and pop-ups for more detailed information. We added a floating shopping cart showing which items have been selected (though due to Axure limitations we were not able to calculate a running total).

We tested our prototype with two groups of eight users on two different evenings. We gave the users a number of tasks, and divided them equally between interface options. We used feedback from the first session to make iterative changes before the second test, but only to correct minor usability problems that presented consistent roadblocks.
In developing the prototype, we used a new visual design and interaction model but preserved the current product names and organization. One of our goals was to find weaknesses in the way the company’s products were structured, positioned and marketed.

In testing, we had two very different objectives, or basic questions: to see how the prototype interface performed in terms of allowing users to complete tasks, and to see how users responded to the organization of the company’s products. Did the conceptual model – breaking TV into service then channel package, for example – actually work? In other words, could we build an interface that allowed users to complete a complex task successfully, but could we also find ways to reduce the complexity of the task by simplifying the underlying structure?

Based on the testing sessions, we learned that both interface concepts were relatively successful at allowing users to complete all tasks, but that users do in fact struggle with the complexity and ambiguous naming of the client’s products. Users were divided in their preference for the traditional catalogue and the assisted-selling tool, so we proposed including the tool as an optional “help” path for users who needed more hand-holding.

Thanks to the prototypes, we have a well-developed IA for an online store environment that we know will work effectively, thereby reducing risks once we start development. But perhaps more importantly, we found compelling evidence of user confusion that we can take to business stakeholders, in an effort to convince them to reduce product complexity.

Internal Software Application

We were engaged on a small project to solve interface-design and usability problems for an web-based internal software application used by the purchasing department of a global auto manufacturer. The client presented us with rough wireframes showing their first ideas for a solution.
We sketched out a number of possible solution concepts, then drew wireframes of the most promising idea. Without going into great detail describing a complex application, the core problem was to present a list of up to 100 different auto parts, then for each part multiple tabs containing dozens of data fields, while allowing values from certain fields to be copied from one part to one or more other parts (e.g. the right- and left-side versions of a suspension component would both come from the same supplier and have the same price terms and shipping costs, so the user should be able to copy those fields from one to the other rather than enter them twice). Our basic question was simply this: was our interface concept “intuitive” and usable? There was no formal testing beyond presentation to the client.

The client requested a clickable HTML front-end prototype that would show interactive elements on the page, but with no access to data. A developer quickly took the wireframes and built out the pages, but in the process the developer and the UX architect together added a number of dynamic elements that provided the user with clear indications of what steps should be taken next in the process, and clear feedback showing when an operation was successful. (When the user checked a data field to mark it for copying, the paste button appeared above the list of parts, along with check boxes next to each part and a select-all button. When the user clicked on the paste button, selected parts were highlighted in green for a few seconds to indicate a successful copying of data fields.) Hiding controls until they were needed improved usability by reducing interface complexity and making next steps clear.

The lesson from this project is that while dynamic behaviours can be documented in wireframes, it’s hard to think dynamically when you’re drawing statically, and the HTML prototype was critical to developing screen-level interactions that provided a far better solution for the user.

One of my personal goals for the trip was to work with a local agency or client. My priorities: gain some new experience, make contact with potential partners and clients in Europe, improve my German, and simply get out of the apartment.

Finding work proved to be relatively simple. I used LinkedIn  and Xing (a European competitor) to connect with the local IA/UX community. Within two days of arrival, despite jet lag and appalling humidity, I met upwards of fifty colleagues at the quarterly “IA cocktail hour”. I learned that there was no shortage of interesting UX work in Berlin, much of it for mobile platforms, and a surprising amount in English.

While working remotely on a Calgary-based project over the summer, I pursued a number of leads until the call came from MetaDesign, an established agency with a strong print and brand identity background.

My first project at MetaDesign was a complex online catalog for an Italian manufacturer of architectural lighting products. We developed a filter solution powerful enough to cope with thousands of different products and dozens of possible facets. I divided my energies equally between designing and documenting the search and results interface, and attacking problems with the underlying data structures and labels. English was the language of client communication, though day-to-day work took place in German.

Our final two assignments were smaller interface-design problems for internal applications at Volkswagen. Working on “branding-free” projects was a refreshing change from public-facing sites, while the complexity of the applications, workflow and user tasks presented interesting challenges. Taking the high-speed train to meetings in Wolfsburg – at 250 km/h – was an added bonus.

When I look back on the experience, my overall impression of working for a German agency is that it’s really not much different from working for a North American agency, except that the office coffee is much, much better. (I still miss the enormous old espresso machine in our kitchen.) Work methodologies are similar, the work environment and agency culture are similar, the deliverables are similar.  Clients are still demanding, projects still go off the rails sometimes, people still work late sometimes. Vocabulary may differ slightly (for example, comps or flats are “layouts”) but the underlying concepts and roles are the same.

While the UX profession doesn’t differ much on either side of the ocean, European office culture does differ in slight and subtle ways. Relations with clients are more formal, at least linguistically. On your birthday, you are expected to supply your own cake and share it with your co-workers.
Language is of course a major issue when working abroad. I am lucky in that my German, though far from perfect, is good enough to work on German projects with German clients. Ultimately I found this much easier than working in English with an Italian client – being a native speaker is almost a disadvantage in that one constantly overcomplicates their speech and writing. Potential expats beware: it may be a cliché, but at the same time true that “bad English” is the global business language. And while there are many opportunities for English-only work in Berlin (Nokia in particular) some understanding of the local language and culture will makes life much easier.
Overall, I enjoyed my “working sabbatical” tremendously. Quite apart from the friendships and contacts I made, and the workout my German received, the projects  I took on presented a refreshingly different set of challenges from public-facing web sites. I had the chance to sharpen another set of skills.

Hopefully we’ll have more chances to work together with MetaDesign in the years to come.

As a wireframe-type guy, I can only speak to my own personal emotional response to the process and final outcome of building wireframes, so that is where I will start.

Ross, tell us how you really feel…

I’ve been building websites for over ten years and I’ve done everything from concept models, to visual design layouts, to writing client-side code line by line. The biggest thing I’ve learned is not to get too attached to ideas or concepts because there is a good chance they will be changed, edited or rejected at some point. Throughout my career I’ve had clients who have loved my design work and other projects where it’s been flat out rejected; it’s the nature of the business and my skin has grown thick over the years. But even now, I find myself much more anxious about reviewing visual design concepts when compared to reviewing wireframes and the reason is really quite simple: emotional investment.

For me, drawing boxes, arrows and lines in varying shades of gray does not create the same kind of internal emotional response when compared to designing the visual look for a project. When I’m wireframing, I have my analytical hat on. I’m thinking about the page’s functionality, the primary objective of the page, making sure blocks of content are located in a logical place for the user, etc.; it’s hard to muster emotions when you’ve got the analytical hat on. When I do visual design work the emotional hat replaces the analytical hat. I am much more focused on colours, shapes, depth and creating an overarching visual theme. I am still aware of the logic behind the wireframes but because more detail is being given to the visual design, and those details are intended to trigger emotional responses in users, I find myself getting much more connected and attached to my work.

How many times have I felt crushed, dejected and forlorn if a client comes back with some harsh criticism of a wireframe? Almost never. That is the one of the strengths of wireframes which is often overlooked; it’s hard to get upset if someone tells you your box is the wrong shade of gray. Wireframes keep me emotionally distanced from my work. This is not to say that I don’t take pride in what I do, because I do, but emotional distance has, time and time again, provided me with a clear head and sharp focus for solving problems without bogging down on how I am internalizing criticism or feedback. More often than not, my ego remains intact and the client ends up getting a great solution.

I was working on project recently which had many, many iterations and the wireframes for one particular section had turned into a bit of a moving target. One evening, I realized that I was not getting nearly as frustrated or overwhelmed as I could be given the circumstance. After some self-reflection, I came to the conclusion that I was not emotionally attached to what I was doing. But this was not a negative feeling, it was actually liberating and somewhat empowering. I simply thought about the feedback I had received and started to form a few different options for solutions. No hurt-feelings, no ego, just focusing on the solution; I love wireframes!

For part 2, I will try to get into the head of a client and see how they are reacting to and internalizing the process of wireframing.

It’s a little three-letter acronym that has represented dreams of corporate success and online riches and padded the wallets of digital snake-oil salesmen and spammers ever since Google became a verb.

It certainly earns its both bad and good reputations in the worlds of digital strategy and consulting.

First, the bad: practitioners remain out there who swoop in with a wink and grin promising to own the first page of Google with a dizzying strategy of thousands of inbound links and horrible sounding pages of repetitive copy. Yeah, not cool.

This post is about practical SEO: the tactical things to think about when designing for users, not search bots. There used to be a difference between the two, but thankfully, those two audiences are merging.

Practical SEO is not about mystifying users while somehow tricking search engines in order to get a click-through.

The practice isn’t magical at all really, and there are a few steps, that, with a little leg-work, should improve how users get to your site. And you really don’t need “SEO Specialist” on your business card to successfully pull these things off.

1. Do Your Keyword Research

Anyone can crack open Google AdSense for free and with a little time invested, find out what words users are searching for in relation to their business/organization/blog/etc. Sometimes the results are obvious, sometimes they’re not.

As an example, I was designing the user experience for a destination site that was to include a listing of job postings in Calgary. The preliminary label for the page was “Working in Calgary”, that in my preliminary opinion, should have fared pretty well for SEO.

Yeah, not so much. People looking for work actually search for “Calgary Jobs” or any other such combination of “Jobs” and “Calgary” substantially more than “Working in Calgary”, “Calgary Employment” or the like.

A quick sanity check on AdSense resulted in changing the name of the page in the site map, site designs, copy and meta content. This wasn’t done to trick search engines in any way, it was done to reach those users actually looking for jobs in Calgary, the whole purpose of the website in the first place.

Even if you’re not doing any full-blown SEO research or keyword implementation, take the time to run your site labels through tools like AdSense or Wordtracker. You might be surprised at what you find.

2. Research and Craft Quality Meta Content

Copywriters rightfully focus on the website’s experience, including the information it provides and the emotion it conveys.

All too often though, meta content (most importantly titles and descriptions) goes ignored. A quick explanation for the uninitiated…

This is a meta title (and where and how it appears on the Google search results page):

It’s one of the most important things a search engine looks at for keywords. It’s crucial that you have a unique one for each page on your site, and that it accurately describes the page’s content and includes appropriate targeted keywords (ideally researched on AdSense or Wordtracker).

The optimal format is “Primary Keywords – Secondary Keywords | Web Site Name”.

This is your meta description:

You have 144 characters with spaces to describe the content of your page. Keywords are important here, but equally important is letting users know what they’ll find by clicking your link.

Essentially, these two components make up a free targeted ad for your website (AND every single individual page on you website). Make them count by actually enticing users to visit those pages and letting them know what they’ll find there.

3. We’re Social Animals – So Be Social

It used to be that the content on your page was enough to get you rankings: structure it and write it a certain way and you’d end up performing well in search engines. Now, the Googles of the world look at who’s linking to your site even more than what is on your site.

So is content no longer king? It absolutely is, because in order to get people to link to it, it needs to be as good, engaging and informative as always. Even more so: everyone’s a content creator so competition is high.

Essentially, Twitter, Facebook, Flickr, MySpace and countless others matter in the world of search.

This doesn’t mean you should go out and take the smarmy spam approach. Those Google folks are pretty clever, and they’ll catch on to spamming SEO specialists who try to illegitimately manipulate the rankings with pages upon pages of links.

It does mean creating engaging and informative content that is of value to users, and then telling them about it via Twitter, on a Facebook page, in a Flickr group, or in any other number of places that online conversations are taking place. A social media strategy is also an SEO strategy.

Those are the three biggest tactics that you can take to get started on your own initial SEO program. Like a lot of what we do online, it’s mainly a question of practicing common sense once we wade through the buzzwords and mystical nonsense.

To be successful, make sure SEO has its rightful place in your project plan, and assign someone (or some people) to do the keyword research, create the meta content, ensure those keywords make it into site labels, strategize and seed social media, and keep regular tabs on how it all comes together.

The short answer is that most of the challenges of working remotely are fairly self-evident, although in the web industry and particularly our niche, they can be relatively easily mitigated. Our fairly narrow focus on User Experience within the digital realm means that while we do integrate with practitioners of other disciplines and larger web teams (either our clients or partners), our singular focus does not require the same levels of extensive collaboration across disciplines as in a full-development shop.

In addition, as most people are aware, the very nature of web work means that teams do not need to be working face-to-face. In fact, since the most common model for client / web team (or agency) relationships is a remote, there are few external challenges that aren’t already well understood in the web industry overall. For the UX Guys, working with local clients and being able to meet and collaborate face-to-face is one approach, but for those relationships sustained from further afield – we follow the same practices as most agencies. This means that by in large, most of the major challenges of working in a virtual environment are internal.

So, what are these challenges and how do we deal with them? Pretty much every internal operation can be more challenging when you don’t sit next to your colleagues in the same building. Developing a sense of team, building and maintaining your individual company culture, ensuring quality work, performance management and even day-to-day communication can be a challenge depending on the personalities and communication styles of your team.

But the big enchilada of challenges is that buzzword of creative industries and agencies alike: collaboration. Ensuring your team members are not each working in a silo is all the more difficult when there are kilometers separating them.

While we know that our model is still a work in progress, we have been fortunate to see some success over the past few years. So here’s what we think we’re doing to ensure that each of these challenges do not interfere with creating a successful team, are not taxing on our clients, nor ultimately, affecting the quality of our work:

It takes a blend of some crucial ingredients – the right team, a sense of discipline and dedication, the right tools, just a little bit of that dreaded word… process… and mostly, a true desire to make it work.

1. The Right Team: Ensuring you have the right members on your team is the first step. For us, that means we look for individuals who have a balance of seniority or experience in their practice; the desire to work in a more flexible environment; the initiative and discipline to do it; and the motivation to strive to combat some of the challenges of working in a remote team.

2. Discipline and Dedication: This is not just from each of the team members, but also from the organization as a whole. From working towards creating a collaboration space that the team can take advantage of, to investing in the best technology and hardware available, both the company and each individual has to be disciplined and dedicated to the model.

Other tools include a set of examples and templates for the types of deliverables we tend to create in our work. While these are meant to be flexible for each project, and are continually improved upon – this set of templates is a valuable asset to our team – ensuring that each of our deliverables are consistent and meet our quality standards.

3. Process: Ah, yes, this is a dreaded word for most professionals who are not fervent disciples of Agile or Six Sigma or some other “revolutionary” project management approach. While process itself may seem to be the antithesis of the UX Guys’ relatively informal and flexible work environment, in fact, it is a necessary part of the foundation without which informality could possibly descend into chaos. And so, we have slowly but surely developed and implemented general project workflows, internal operational processes (for billing, payroll etc.), and more specific HR policies, along with frameworks for evaluating our work, our clients and ourselves.

4. The Right Tools: A commonly held belief, and one we adhere to is that the tools of your trade can make or break it. At UX Guys, we have invested in web-based collaboration tools, and file repositories. Our teams are outfitted with the hardware they require to make working remotely as easy as possible – an iPhone, a decent headset and a laptop are the basics everyone needs. We try to stay up on new technologies and tools and, as a company are eager to try out new ways of ensuring communication and collaboration are as easy as possible. We have also recently leased some space which will be used for collaboration and mentoring, although there is not enough room for us all to work, nor is the expectation that we be there regularly.

We also hold mandatory weekly team meetings (in person for those in our city) and monthly show-and-tells where we can share and collaborate on recent or on-going work. Interestingly, many of these “processes” not only help to increase the efficiency and quality of our work, but also contribute to building and maintaining the strong culture of our company.

Despite the challenges, there are benefits to a virtual work environment – are there ever. The biggest advantages are clearly on the side of the individual employee – working the way we do affords us incredible amounts of flexibility. Not only that, but we tend to be more productive and focused as we attend less (potentially irrelevant) meetings and have less distractions – whether in the form of copious office emails or chatty colleagues. We also enjoy a great variety of challenging work, and freedom (most of the time) to complete it when and how we prefer. And, of course, the lack of commute, and even the need to get dressed some days, are bonuses most everyone can appreciate.

That said, some of our team choose, or are asked, to work from various locally based client offices for at least a portion of the workweek. For those that do, the social aspects and the ability to collaborate with a larger team offer a welcome break from what can sometimes be a somewhat lonely existence.

Regardless, ask anyone on our team, and chances are they’d heartily agree that all of the benefits far outweigh any struggles that come along with working more or less independently.

For our clients, the benefits are also numerous – they get a nimble group of high-quality talent with a singular focus – their project; they can rest assured they’re getting input from a team of professionals who do not have the distractions and, (let’s face it) overhead that can be implicit in working with a larger corporation.

There is a lot of effort that goes into making our team more than just a loose set of freelancers but a tight group of professionals with a common goal, language, methodology, culture and set of deliverables; so, as we continue to improve upon this virtual work model adapting our tools, workflows and processes – we look forward to sharing our progress with you through this blog. In the meantime, we’ll be sitting in our sweats and slippers, thanking our lucky stars we missed the -30 degree Celsius morning commute.

In November of last year, the Calgary UX Book Club read “Wired to Care” and were fortunate enough to have a video conference during our monthly meeting with co-author, Peter Mortensen. The video conference was fantastic and gave Mr. Mortensen a chance to share his insights and anecdotes around the process of writing the book and “Wired to Care” has been lingering in my subconscious ever since…

Make no mistake, “Wired to Care” is a business book but it offers a new approach to improving business and that is what makes the book so engaging. The entire premise of the book is based around changing the cultural fabric of business and Patnaik and Mortensen give a convincing argument for empathy as the conduit for change. Companies that wish to prosper and endure should be creating a culture where empathy for customers becomes a primary driver for every employee¾from the CEO to the summer intern. Each chapter is dedicated to a concept which ties back to the book’s overarching theme of creating a culture of empathy with wonderful narratives and anecdotal stories employed to illustrate every single concept. It’s an easy read because it is so authentic; stories of real people solving problems and creating solutions is about as engaging as it gets for me.

So how does the notion of empathy fit into user experience design? Well, it is actually one of the most important concepts when approaching a design problem and this is why “Wired to Care” continues to bubble up to the surface when I am thinking about design problems. If a company can’t understand what is happening when a customer interacts with their product or service—the challenges, the constraints, the “ah-ha” moments—then it is going to be a very tall order to gather requirements and create solutions that actually solve any sort of problem relating a customer and/or user. User experience design should not be done in a vacuum without the insight of the people who have the most to gain, the customer! If nothing else, “Wired to Care” has solidified the importance and value of user research in the user experience design process.