Author Archives: Kelly

Humility and the art of revision

Leave a reply

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 UnfinishedProduct.com.

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

Leave a reply
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

Leave a reply

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

Leave a reply

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.com

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

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

Leave a reply

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!