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!