I was a competitive road cyclist for four years. My bikes were good, but my race results were much less impressive. Instead of medals and trophies, all I had to show for it were shaved legs and a farmer’s tan.

Regardless, on the road to becoming a competitive athlete, I followed a rigorous training plan with concrete goals. These goals were specific, measurable, attainable, realistic and timely. With this training plan, I was able to quantitatively and qualitatively assess my progress and adjust my routine to match.

In the years since, I’ve hung up my racing jersey and replaced it with a designer’s hat. While wearing this hat, I (and many others) have been told to “create a good user experience.” We’ve heard this in creative briefs, project kick-off meetings and critiques. It may have been a bullet point in a PowerPoint presentation or uttered by someone trying to sell a client or company on the value of their services. But there’s a fundamental problem with stating that your goal is to “create a good user experience.”

It’s not specific, directly measurable, actionable, relevant or trackable. Thus, it will create disagreement and disorganization, sending many projects into chaos. However, we can avoid this by using S.M.A.R.T. goal-setting criteria when defining user and business goals.

Bad Vs. Good Methodology

Before we get started, let’s look at how a poor methodology can derail an entire project.

There was once a project to redesign a significant section of a company’s website. This section introduced visitors to the brand’s history and technology, and analytics indicated that customers who visited this section had a much higher conversion rate. Stakeholders believed that improvements to the content and navigation could result in even higher conversions. This was seen as a golden opportunity to increase sales by improving the awareness and presentation of the brand’s story. Thus, a complete project to redesign this section of the website was born.

Here is a summary of the project from the stakeholders’ perspective:

High-level project goal
Increase conversions and sales.

High-level project strategy
Leverage the history and technology section of the website.

High-level project tactic
Improve the content and navigation of the section to increase user engagement, better communicate the benefits of the products, and drive users into the conversion funnel.

Unfortunately, rather than communicate this to the design team, the goal for this redesigned section of the website was presented as follows:

Create a good user experience.

Sigh. There’s that phrase again.

The Problem

The designers were given a nebulous tactic masquerading as a goal. This meant that they had minimal understanding of the true objective of the project, which put them in a poor position to understand the problem and to hone the strategy and tactics to solve it.

To make matters worse, the lack of well-defined high-level goals, strategies and tactics made it difficult for the designers to define the architecture of the experience, in turn making it nearly impossible to set user goals and business goals for every page that needed to be designed.

To make a long story short, the designers spent four months working through unsuccessful concept pitches and design revisions. The concept behind the designs constantly changed, and the content and features failed to support a cohesive user story. Meanwhile, designers and stakeholders had different expectations of what this section of the website was meant to accomplish, so solutions rarely satisfied both parties. Nobody knew the needs of the user, and the needs of the business were but a neglected thought in the shadow of “creating a good user experience.”

After these four months, there was zero progress. Not only was the project’s situation dire, but the lack of approved and delivered work was eroding the team’s morale. With no concrete user or business goals to satisfy, the team aimlessly pursued a “good user experience.” It was like being told to drive but not given a destination.

The Solution

I was subsequently pulled into this team as the project and design lead. My first priority was to bring awareness and understanding of the high-level project goals, and then lead the team through a comprehensive exercise to document the user goals. Although we didn’t have access to detailed user studies and customer information to create data-driven personas, we did our best with anecdotal experiences, competitive analyses, and website analytics to create user goals for each page. We then worked with the cross-functional teams to understand the business goals and KPIs.

Using these goals, I led the designers to write thorough content and feature requirements. The benefit to this approach was that all content and features were made to serve documented user or business goals. This encouraged product simplicity and reduced scope creep. These goals and requirements were then reviewed and refined with all stakeholders. Once expectations were universally understood and accepted, the team proceeded to create the architecture, interactions and designs.

This comprehensive methodology took less than three months. But the magic is not the methodology itself, but the discipline to identify concrete goals that satisfy five basic criteria.

UX S.M.A.R.T. Goal Criteria

As I mentioned earlier in my competitive cycling example, my improvement as an athlete was based on goals that each met the five criteria of the S.M.A.R.T. goal-setting5 technique:

Specific,

Measurable,

Attainable,

Realistic,

Time-based.

This technique can be applied to documenting the criteria for user goals and business goals:

Specific,

Measurable,

Actionable,

Relevant,

Trackable.

With these criteria in mind, what would be considered a S.M.A.R.T. goal?

S.M.A.R.T. User Goal Examples

Let’s use the product detail page for a fictional e-commerce website to illustrate. A product detail page is a page on which shoppers can learn more about a product for sale and add it to their shopping cart. It typically includes images of the product, the price, a description, and an “Add to Cart” button. Here is an example from a well-known fruit company:

7The product detail page for earbuds in the Apple Store8. Notice the images, price, description and “Add to Cart” button.

Based on a competitive analysis of many e-commerce product detail pages (and on personal experience from working with and studying how consumers make purchasing decisions), here are some user goals for the product detail page of a fictional e-commerce website.

Primary user goal (UG1):

I want to learn more about this product’s design, features and specifications to determine whether it fits my budget, needs and preferences.

Secondary user goal (UG2):

I want to purchase this product.

These goals meet the UX S.M.A.R.T. goal criteria because they are:

Specific
By stating exactly what the user needs to accomplish, these goals help us maintain scope and stay focused on designing content and functionality that is critical to our user’s success.

Measurable
For the primary goal, we can measure clicks to determine how users are engaging with the content. Alternatively, one-on-one interviews or customer surveys could provide qualitative insight into whether your content is relevant to the user’s interests. For the secondary goal, we can measure the percentage of visitors to the page who click “Add to Cart.”

Actionable
Because the goal is specific, we can readily identify content and functionality that satisfies the user’s goals. In this example, because users want to learn more about the product’s design, large product images should be included.

Relevant
These goals are appropriate for a product detail page, but not for a return policy or terms and conditions page. By keeping the goals highly relevant, the content and features that we introduce to satisfy those goals will be relevant, too.

Trackable
There’s no point being measurable if the data cannot be tracked over time. This is essential to determining the immediate, short-term and long-term success of our design and its future iterations.

In contrast, here’s a DUMB user goal:

I want a Web page that’s easy to use. (i.e. I want a good user experience.)

That’s not a witty acronym, and it doesn’t hide the fact that this user goal is not specific, measurable, actionable, relevant or trackable. It fails all five criteria because it fails the first: specificity. A good user experience has many facets, and without targeting a specific aspect of the page or product experience, there’s no action (strategy and tactic) to address it. If a goal is not actionable, then it has no reason to exist because there is no end towards which effort and action can be directed. Similarly, if the goals are not measurable, then there is no way to gauge the successes or failures of our actions, and subsequently no way to understand the product’s performance over time.

S.M.A.R.T. Business Goal Examples

UX S.M.A.R.T. goal criteria can also be applied to business goals. They are particularly relevant because businesses are run by numbers: number of clicks, number of customers, number of dollars, the list of measurable metrics continues. So, let’s take real-life business goals for the same product detail page of our e-commerce website as an example:

Primary business goal (BG1):

We want to increase the ratio of add-to-carts to page views for the product detail page to x%.

Secondary business goal (BG2):

We want to increase cross-sells to y% of total add-to-carts.

Just like the preceding user goal examples, these business goals meet the UX S.M.A.R.T. goal criteria because they are:

Specific
By stating exactly what metrics the design needs to affect, these goals help us maintain scope and stay focused on designing content and functionality that will put us in a position to hit our targets.

Measurable
For the primary goal of increasing conversions, we can measure the number of page views and how many resulted in an add-to-cart. For the secondary goal of increasing cross-sells, we can measure the number of clicks on cross-selling products.

Actionable
Because the goals are specific, we can create more targeted strategies to accomplish them. For the primary goal of increasing add-to-carts, this could mean making the content on the page more relevant to users’ goals, or something as simple as improving the success of the add-to-cart button. For the secondary goal of increasing cross-sells, this could entail changing the visibility of cross-selling items (assuming we have already done a good job of selecting which related products to promote).

Relevant
The relevance of this goal depends on the high-level objectives of the project. If the objective is to reduce the number of customer support calls each day, then this goal might not be relevant. But if the objective is to increase total sales revenue across all products, then it is very relevant.

Trackable
We can count the number of page views and add-to-carts over an extended period of time.

By contrast, here’s a dumb business goal for the product detail page:

I want to make more money.

This is a poor business goal because it’s not specific and might not be relevant to this page at all. There are many ways to make more money, and without specificity in the strategy to accomplish this, creating a successful plan of action will be much more difficult. Remember, if a goal is not actionable, then it has no reason to exist because there’s no end towards which effort and action can be directed.

UX S.M.A.R.T. Goals Applied

So, now we understand the criteria behind well-defined S.M.A.R.T. goals and have applied them to the user and business goals for the product detail page of a fictional e-commerce website. How can we use this to our advantage as we move forward with the architecture and design of the page?

Associated Content and Feature Requirements

Because the goals we’ve defined are specific and actionable, we are able to propose content and features that directly satisfy them. Let’s revisit the four high-level goals of our product detail page and attach appropriate requirements to them.

Primary user goal (UG1):

I want to learn more about this product’s design, features and specifications to determine whether it fits my budget, needs and preferences.

Content and features required to satisfy this goal:

Relevant images that represent the product as a whole;

Relevant images (such as enlarged views and alternate angles) that show the product in detail;

General description that provides a brief overview of the product’s purpose and benefits;

We want to increase the ratio of add-to-carts to page views for the product detail page to x%.

Content and features required to satisfy this goal:

Reference user goal 1,

Reference user goal 2.

Secondary business goal (BG2):

We want to increase cross-sells to y% of total add-to-carts.

Content and features required to satisfy this goal:

Related products that the user might also be interested in (for example, if the user is looking at the detail page for a small digital camera, recommend a small case to put it in).

Because everything must serve a documented goal, scope creep during the project’s lifecycle is reduced. This is not to suggest that content and features beyond these goals cannot be included. Components such as global navigation or a site-wide search box might be required even though they are not the purpose of the page. Determining what belongs on a page is admittedly not as black and white as these example might lead one to believe.

That said, setting content and feature requirements based on S.M.A.R.T. goals does help to determine the visual hierarchy of information on the page. This is extremely helpful during the wireframing stage.

9A wireframe for the product detail page of a fictional e-commerce website. The user goals (UG1 and UG2) and business goals (BG1 and BG2) correspond to those outlined above. Download the complete wireframe10 for this example.

As we can see in the above annotated wireframe, the content and features that satisfy primary user and business goals (labelled UG1 and BG1) are more prominent in scale and placement than those that satisfy the secondary goals (UG2 and BG2).

Now, having applied S.M.A.R.T. goals across the planning and architectural phases of a project, we can see the benefits of this UX strategy, as follows:

Goals are specific, measurable, actionable, relevant and trackable.

Because the goals are specific and actionable, we can attach appropriate content and feature requirements to each one. Because the goals are relevant, these requirements are relevant, too.

The hierarchy of the content and features is determined by the hierarchy of the goals that they are attached to. This informs the architecture of the wireframes.

With these benefits in mind, we can begin to understand how this positively affects other stages in the project’s lifecycle:

Wireframes with well-informed structures and content are solid foundations on which to design higher-fidelity mock-ups.

Because the goals are measurable and trackable, we can determine the success of the design during testing, learn from it, and make improvements in subsequent iterations.

Ultimately, these all contribute to our ability to understand the problem and craft an appropriate strategy and tactic to solve it. Our discipline in gaining focus in the earliest stages of a project will determine our ability to maintain focus when designing the functional aspects of the product at the end.

Conclusion

A great user experience is the result of setting concrete goals that meet both user goals and business goals. Unfortunately, I have seen many teams kick off a project with nothing more than a goal of, “Let’s create a great UX!” While a noble thing to strive for, it’s not specific, actionable or measurable. It contributes nothing to the planning or design phases, and it is the UX equivalent of a motivational high-five.

“Artwork that is only about wanting to be famous will never make you famous. Fame is a byproduct of doing something else. You don’t go to a restaurant and order a meal because you want to have a shit.”

Likewise, a good user experience is the byproduct of many brand, product, design and development decisions. As designers, we must collaborate with our clients and ensure that we thoroughly understand the needs of their business and target audience. Only then can we be empowered to create appropriate strategies and tactics to achieve them.

So, don’t try to “create a good user experience.” Create a S.M.A.R.T. one.

Additional Resources

“Locke’s Goal-Setting Theory14,” MindTools
A brief overview of Dr. Edwin Locke’s research on goal-setting and motivation, explaining how goals provide a major source of motivation and improve employee performance.

Dickson is a user experience designer with a background in ethnographic research. He now practices interaction design and visual design for a wide variety of brands and enjoys working with organizations to refine their UX methodologies. You can follow his shenanigans on his blog or on Twitter.

Rick

Francisco Inchauste

@Rick Thanks for the feedback. Could you clarify that? The purpose is to set up something specific to measure, rather than hope everyone’s definition of “a good user experience” (and how the final product lives up to that) is the same for any given project. This seems more proactive than being an afterthought.

Oliver

Most of us do/should know all this by now. But I often underestimate the number of people not aware of some basic principles or working methodologies.
Thus leading me to thinking that the people this post is addressed to would maybe not actually be looking at it here. Or elsewhere.

Don’t get this wrong though, loved the article !

0

5

Patrick Samphire

I have no problem with SMART goals … as long as they know their place. I’ve worked in lots of businesses over the years, and I’ve seen SMART goals cause far more harm than good. This is simply because SMART isn’t the be-all and end-all. Organizations that focus on SMART tend to forget that not everything that is important is measurable (nor, often, specific or time-based or trackable), and only considering things that are ends up with the organization chasing statistics and goals rather than actually succeeding.

So, yeah, use them, but don’t think that if you have them and meet them you’ve necessarily done a good job.

0

6

Steven Jones

I agree, as much as goals are a good thing for a company, the mere attainment of goals is not something that defines success. Goals are tools; they are a pathway to success. In order for goals to be effective, they need to have that idea of success in mind during their creation. Goals are good, but maybe a section about the purpose (not just the creation and exectution) of goals should be added to this article.

I really love the article. It is well-planned and executed as far as presentation, and it gives something more than the typical S.M.A.R.T. goals presentation.

0

7

Dickson Fong

Thanks, Patrick and Steven, for your comments! I agree that goals are not the be-all end-all. The existence of goals does not guarantee the success of a project. Like you mentioned, sometimes the success of a project cannot directly be measured. Things such as brand perception or the success of brand guidelines are often less tangible, and we should be mindful of this problem when setting goals and success criteria.

Thank you both for highlighting this! Perhaps this can be a discussion for another article in the future.

0

8

Brett Jankord

Excellent article Dickson! I’ve been in many a meetings where I’m presented with, “Our goal is to make the best “insert area of expertise” website ever!” Yet there is never any clear direction on what are the exact goals the company is trying to achieve with this new website. You might be surprised how hard it is to get basic goals out of clients other than, I want it to look good/cool/awesome/modern/clean/blah blah blah. I could never just go to a home builder and only tell them to build me the best house in town. They would want to know more specifics like what type of house, how many bedrooms/bathrooms, how many floors, what colors for paint, and so on. It’s bizarre to me that clients can come to us with little or no plan for what they want out of their website, other than they want it to be the best/coolest.
Thanks to your S.M.A.R.T. goals I’ll be able to hopefully get some more information out of clients.

0

9

Kevin Brown

It isn’t just about measurable goals, it’s a methodology for linking the client, the project, and most importantly the user together. To use Brett’s analogy, I would content that most people “having the house built,” won’t be living in it. It will be the tenants or “users.” To measure any project’s success without considering whether or not the user will be happy is a mistake. So when you’re meeting with builder to decide the floor plan and color scheme, it’s not a bad time to consider how the tenant will be using the space. The measurability allows you to see if you hit the mark AFTER the house is built. SMART is another tool to utilize in these situations.

Not disagreeing with you Brett, just adding that addendum.

0

10

David Kujda

What i really appreciate about this article is the clarity and simplicity of thought as it relates to real world experiences.

As UX designers and leaders, it’s refreshing to learn from examples that deal with the very real organizational challenges and cross functional work dynamics. There are some good lessons here, not only in the examples, but also in the easy communication style of the article. We need to get away from buzz words, jargon and fluffy industry speak as a way of approaching the needs and goals of the people using our products. UX designers/leaders are the ones that need to shepherd such practices and teach organizations the way. So, I suggest the following formula as an over-arching principle…

1. Calculate the average age of the employees working in your organization.
2. Divide the average by 3 and imagine this is the age of the people you work with.
3. Now that we’ve established the real age of the folks in your organization, keeping it simple will be almost unavoidable and ironically admirable.

Steve Jobs is probably the greatest user experience leader in the world and its interesting to note that the value in just about any product presentation he’s ever made can be fully understood by ten year olds, despite being at the center of a very high tech industry.

0

11

Selvam

Marcel

Dickson, what made the original design team in your story not capable of determining the rather obvious goals by themselves? Even with a dumb goal you could draw your own conclusions: a website selling products would probably like to sell more products, a company website would want to inform customers and potential new employees. I wonder if a UX designer shouldn’t be capable of getting the relevant information from their employers, team leaders or even their customers by simply asking them the right questions. We are a social bunch, after all.

That said, it was a good read. Well written, keep them coming please! A bit more in depth sharing of experiences would be much appreciated!

Dickson Fong

Marcel, I think the original design team actually was capable. They were able to speak to some of these high-level goals in conversation when I first got looped into the project.

The difficulty they had was formalizing these goals into an artifact that can be used as a communication tool when pitching their design concepts to people elsewhere in the organization. Business owners for e-comm, marketing, and brand might each have completely different expectations for what this section of the website is supposed to accomplish. Although these individuals may never agree, it is important to establish dialogue and set the correct expectations.

So, to answer your question, the problem wasn’t that the design team wasn’t able to get relevant information. It was their inability to consolidate that information, set expectations, and build designs off them — with zero surprises to the cross-functional teams involved.

Buzzlair Voufincci

Annie Ignacio

“Business owners for e-comm, marketing, and brand might each have completely different expectations, website selling products would probably like to sell more products, a company website would want to inform customers and potential new employees. AMAZING… is another tool to utilize in these situations.

0

17

Justin Mifsud

Great article Dickson. It’s always interesting to read something that can be applied in a practical manner during our course of work. Loved the way you translated a generic client requisition into tangible elements. Unfortunately it’s a very common problem that a team starts designing and developing without a finishing line to aim for. Have witnessed that a lot! Well done for discussing this subject.

0

18

Kadee

Hi Dickson – nice article. To me, it seems like the idea of setting a goal and working through it so that the team understands it as a whole, is almost intuitive to any business professional. Do you think, at all, that some of the “poor” goal setting you’ve seen comes from people who are simply there to work rather than someone who truly cares about their job, their career and the type of work they produce? In my experience, how the worker feels about the project is usually aligned with the result. I’m I alone on this thought? Or are their truly creatives out there who have enthusiasm and just don’t understand/can’t connect the end result?
Kadee
@produxs

0

19

Dickson Fong

Hi Kadee. As you suggest, it would seem intuitive that people work together to ensure that goals are understood. Unfortunately, in my experience, that’s not always the case.

However, I disagree that poor goal setting is always correlated to a lack of interest in one’s work. While people who “don’t care” are typically less likely to collaborate, I have seen many enthusiastic creatives unknowingly let projects get derailed because of a lack of product management experience. This was certainly true with the example described in this article.

As creatives, I think it’s easy to get caught up in the romantic aspects of our work. In doing so, I’ve seen many designers (myself included) become distracted from the core user goals and business goals, and subsequently go down a path that solves nothing at all. I believe that if designers collaborate with stakeholders in the earliest stages of a project to define these goals, it would help set expectations for the final product. This is not to suggest that goals and requirements defined in the early stages cannot be changed. I strongly believe that all individuals should be flexible and agile. However, by going through the process of setting S.M.A.R.T. goals, my experience has shown that teams become better communicators and collaborators, making the project go much more smoothly.

0

20

Jim

Very nice article. In reality, what your laying out is a basic architectural method for people that may or may nor be CS or engineering majors, thus having been exposed to things like requirements definitions, use cases, swimlanes, etc. You article zeros in on functional requirements, and your criteria is a good test as to whether a “goal” is actually a requirement or not. I work mostly in the non-functional side of IT as an infrastructure architect, but the principals are the same. I usually use two quick tests in requirements definition and gathering…if implemented, is the requirement testable and measurable. If not, it’s not a requirement, or needs further work to derive the actual requirement.

Very good article, and I suspect somewhere along the line you’ve working somewhere that had a formal architectural method. You’ve done a nice job of making it understandable to people who haven’t working in such a method.

Asma Salman

Rudy Chou

Completely agree with the thought process of using a framework like S.M.A.R.T. to help you develop that kick ass user experience.

Building websites started off as hobby for most and original web pages were plain text linked to other pages with more text.

It is much more interactive today and can accomplish many goals. Unfortunately, people do not truly understand the thought and design process involved in creating websites. Its much more involved than just say build a site with a template builder or using Dreamweaver to visually build a website.

True user experience for the web involves aligning itself to the business goals and the goals of the business dedicated to the website as well. The website is a tool, a face, a medium and platform and can be the business in its entirety as well.

Only when you are specific with what you are trying to accomplish with a website can you begin designing for it.

0

23

Sarah Weeger

There’s an AWESOME book out there that goes in hand with what you’re saying (which I completely agree with!!): “Convert!: Designing Web Sites to Increase Traffic and Conversion” by Ben Hunt. He breaks down your S.M.A.R.T. goals with what he calls the Awareness Ladder…. basically a more in-depth and proven way of building websites for conversion.

I recommend it to every web designer, developer, and practically anyone who is ever trying to sell something – if they care about increasing conversion rates. Check it out:

Christopher

Rod Nicolson

In your example of the Apple page the primary user goal is the goal the user had when arriving on the page and the secondary goal was what the user had on leaving the page or taking action on it. Was that your intent? Is that how you envisage that all primary / secondary user goals should be formulated? If not can you elaborate on the relationship between the primary and secondary goals?

Thanks,

Rod

0

26

Brenda

I have got absolutely no issue with SMART goals, as long as they recognize their position. I’ve worked in several companies throughout the years, and I’ve seen SMART goals lead to much more difficulties.

Therefore, yes, utilize them, but don’t reckon that when you’ve got them and meet up with them you’ve automatically done an excellent job.

0

27

Tara

Indeed right Dickson sometimes the success of a project cannot directly be measured. I agree with the S.M.A.R.T. business goal examples you mentioned above. By setting up such goal, I’m sure the business will be more productive and successful, right?

0

28

Rachel Buck

“A great user experience is the result of setting concrete goals that meet both user goals and business goals.”
Only just found your post – I totally agree with what you’ve said but what I would add is that user experience strategy is a long-term plan. If you’re applying it to one project surely that’s just a design plan. UX strategy is part of a holistic business strategy and requires understanding, support and action right across a business – which of course is the challenge for UX professionals. This is how we define UX Strategy

0

29

Melanie Lindahl

I am curious if your user goals are based on user feedback, or if you have another preferred method? (I know the user goals in this article were just examples, so I am referring to you as a professional.) How do you determine your user goals for a project?

I’ve been looking for a UX strategy as an upcoming UX designer. This article easily explains how to get started and why certain things are important (and what things to avoid). Thank you for writing this, Dickson.

0

30

mars

Given the user and business goals is this the only layout which meets the goals or have any other layout been considered and discarded. Simply said is this the best fit layout solution.
Or
Is the sole principle of visual hierarchy determined the layout
And
can we test how effective this layout meets user goals Or can we measure the effectiveness of this layout.

0

31

Arondale Withers

I like this article. I like the idea of having “functional spec” IA deliverable wireframes for developers with heavy annotations one UX & functionality… but I also like the idea of having a secondary document that that removes the functional specs and has annotations that tie in more with business goals and user goals for socializing wires to C-level executives.

Subscribe to our email newsletter for useful tips and valuable resources, sent out every second Tuesday.

It's finally here. Smashing Book #5, our new book on real-life responsive design. With front-end techniques and patterns from actual projects, it's a playbook to master all the tricky facets and hurdles of responsive design. Get the book.Free shipping.

Fixing RWD issues can be quite easy — once you understand exactly why they come up. The Mobile Web Handbook will help you understand technical issues on mobile and how to deal with them effectively.

Hungry for more content? Over 60 eBooks are waiting to be discovered in our lovely Smashing Library. And guess what? You can watch Smashing Conference talks there, too.