Here’s a collection of user interface news, as aggregated by AllTop. I take no responsibility for the content, but it’s usually very good.
I can’t remember having a goal. An actual goal.
There are things I’ve wanted to do, but if I didn’t do them I’d be fine with that too. There are targets that would have been nice to hit, but if I didn’t hit them I wouldn’t look back and say I missed them.
I don’t aim for things that way.
I do things, I try things, I build things, I want to make progress, I want to make things better for me, my company, my family, my neighborhood, etc. But I’ve never set a goal. It’s just not how I approach things.
A goal is something that goes away when you’ve hit it. Once you’ve reached it, it’s gone. You could always set another one, but I just don’t function in steps like that.
When you shift from 1st to 2nd, 1st is behind you. Then from 2nd to 3rd, 2nd is behind you. I approach things continuously, not in stops. I just want to keep going — whatever happens along the way is just what happens.
I consider Basecamp, my current business, as one continual line back from when I sold the first thing I ever remember making — a logo for (which happened to be for Andrei Heramischuk— who knew!). I was 16 or something like that at the time. I didn’t have a goal to make two logos, or to be able to charge 00 for a logo. I just made logos. And then I made software. And then I made web sites. And now I make software again. No goals in the process that I remember.
I just worked at whatever I was working on and ended up wherever I am. I continue to approach work and life that same way today.
If I’ve used the word goal, I didn’t mean it that way. It was just the word I picked, a synonym for something else.
I really like what Jim Coudal said about goals:
“The reason that most of us are unhappy most of the time is that we set our goals not for the person we’re going to be when we reach them, but we set our goals for the person we are when we set them.
That pretty much sums it up for me.
I waste a lot of time sweating small details of code. Stuff that has absolutely zero impact on anything quantifiable. It took me a long time to stop feeling bad about this.
I’m not talking about turning awful code into great code, but polishing code that’s already plenty shiny over and over. Fretting over the length of a line, fussing over the proper indention, questioning the right number of returns. Superficial stuff. Pedantic stuff.
The payback isn’t that the piece of code will run faster, be easier to maintain, or even read clearer to other programmers. It’s purely a selfish act. It’s indulgent. And I’ve come to find it totally worth it.
For me, the limiting factor in writing code is rarely the number of hours in a day. I can’t program for shit after eight hours anyway. No, the trick is to feel motivated to do ever-longer stretches of work without letting interruptions tuck at my sleeve. To ride the high of the zone.
Sometimes the work itself is just so damn appealing that finding the zone is quick and easy. Those are the easy days. But other times it takes more effort, and I’ve found that effort goes down a lot easier when it’s not just the value of the output that has to drag the donkey to the trough. Spiking the motivation with sugary treats that tickle my idiosyncrasies along the way has proven a worthwhile mental hack time and time again.
It’s easy to feel guilty about such creative wankery, but foolish too. Accepting that you, as a human, are a deeply irrational beast of habit and motivation is liberating. It sets you free to find whatever hacks you need to deal with procrastination and distractions.
It’s not silly if it works.
You wouldn’t believe the number of hours I’ve poured into the Basecamp 3 codebase fretting over inconsequential details. But I hope you will believe that greasing my motivation with such fluff also resulted in a great piece of software. If you run a small business and want to regain control of it, now is a great time to signup.
This week, we present an article written by Melissa Perri on the topic of product strategy, and what you can do as a product manager to increase adoption. Here’s an excerpt from the article: Most companies fall into the trap of thinking about Product Strategy as a plan to build certain features and capabilities. We […]
Q: Why do early stage founders, particularly bootstrappers, need to hear your story? What are the things that have made you proudest as an entrepreneur?
I think Basecamp has become a role model to some because we offer a counter narrative. In a technology world obsessed with funding rounds and exits, we not only thrive on the opposite waves, but we dare to flaunt it! There a plenty of companies like Basecamp out there, but many of them just bow their heads and speak too softly. Partly because they are rocking what they’re doing and don’t need anyone else’s attention, but I think, also partly because shouting against the wind is exhausting for most.
Oddly enough, I take a perverse enjoyment to shouting in the wind. To speak against the predominant story lines. So that gives people of like mind a public flag to point to. And I’m proud of that. I’m proud of being used as an example for people who wish to bootstrap, become profitable, stay small, or any of the other motivations for being in business that have little commercial and industrial backing.
Q: In your Medium post Reconsider, you criticized startup cultures in which founders “have to fucking own the universe.” You also mentioned that a better approach would be to leave a dent instead. What dent are you trying to leave, and how have you been able to stick with it for 12 years?
I’m very proud and content with the dents I’ve already left in the universe through the work on Basecamp and Ruby on Rails. We’ve helped so many people make progress together through both systems. It warms me when I talk to customers of Basecamp who’ve been with us for 5 or even 10 years and they explain how they consider the software an integral part of how they’re able to do what they do. Helping others help themselves is gratifying work.
Ruby on Rails took Ruby into to the limelight and helped set a different course for a whole industry. Popularizing an outlook on programming as, in part, the pursuit of happiness for programmers themselves. Not just about getting performant software done with the most features for the lowest cost. It’s a craftsman’s journey with an unusual high degree of care for the tools and their impact on the not just the productivity but psyche of the practitioners.
I think that’s really the key to longevity in business. Escaping the need to declare finish lines, goal posts, and other sources of external validation or success. I’ve chosen to define success as doing what I do every day with a smile. The act of programming, and getting better at it. The refinement and occasional redefinition of what we already have. There’s such tranquility possible when you stop being on the run from one thing to the next and accept your settlement as the place to be.
Q: Along those lines, can you share examples of good decisions you’ve made? What stories would you share with founders who are scared to make big judgment calls?
I think the best decisions we made at Basecamp were the million small ones that were easy to change. Steering the boat by a thousand tiny inputs rather than big, sweeping, grand gestures. Having a habit of making efficient progress by those small, reversible decisions. Resisting the lure of Betting It All on a few big moves.
That being said, we have made a couple of big moves that I’ve come to enjoy because they made sense at the time. Funnily enough, two that stand out are in direct opposition, but both made sense because of when they were made.
The first decision was to diversify from just Basecamp to other products back in the mid-2000s. We launched Campfire, a chat program from before chat was cool. Highrise, a CRM that’s still going strong, and stronger still since we spun it off. And finally Backpack, a personal information management tool. So we ran a suite of four products for many years that gave us options in case any of them, especially Basecamp should peter out. Positioning our odds for the greatest chance of survival and thrive.
The second decision was to become Basecamp. The realization that our diversification strategy was no longer necessary, Basecamp had long since reached escape velocity, but actually hurting the other goals of the company. Which included staying small and making the best things we possibly could. Basecamp’s continued and compounding growth simply meant that either we gave it our full attention or we would have to become a much different (and larger) company to properly service and do justice to all the other products as well.
Q: As you’ve built Basecamp and grown your team, you’ve been very vocal about resisting the temptation of unicorn culture. Was this an understanding that you had off-the-bat as an entrepreneur? How have your perspectives changed?
It wasn’t without temptation or struggle to stay like this, though. Especially in the early years, before our bombastic views on venture capital, the IPO rat-race, and other ills of funding were known. We had, I think, close to 50 different VCs get in contact. A couple of large companies doing the acquisition sniff as well.
Ironically, part of what did give us the confidence to turn down that whole world was a — by startup standards — small sale of equity to Jeff Bezos. Our company had been profitable all along, and we weren’t interested in adding rocket fuel to propel growth faster than it already was (which was plenty fast, thank you very much!). But Bezos bought a small, no-control stake from Jason and I personally, which gave our personal bank accounts just enough ballast that the big numbers touted by VCs and acquisition hunters lost their lure.
I really wish that model would see greater providence. That founders who are on to something find ways to diversify their accounts just enough to dare go the distance. Because once you let in the VCs or the private equity folks, there are only three options: Implosion, acquisition, or IPO. That’s a sadly narrow band and I believe the world is poorer for it.
Far better would it be if we could have more companies operate independently of the 5–7 year investment timelines of the funds. Bezos has now owned that small slice of Basecamp for almost a decade, and he’s been paid back in full and then some through profits. So it worked out for him. And it’s working out great for Jason and I, as well as the employees and customers of Basecamp who are still here some 12 years later.
Q: What about the entrepreneurs (perhaps folks in NYC or Silicon Valley) who can’t escape unicorn culture, no matter where they turn?
It’s very hard to ignore of the drums of the unicorn if you’re standing right next to them. Physical separation can be a healthy membrane to put things in perspective. So if you’re a founder and think you might not want to play Who Wants A Shitty Chance of Making VCs Even Richer, then I suggest you get the hell out of San Francisco and surrounding areas. Tune out that echo chamber both physically and mentally. Stop spending so much time reading startup lore and literature.
Instead, go back to the fundamentals. Study the basics of business and focus on your own work. You don’t have to become a hermit to do this, but some isolation can do you very good. I think that 37signals starting in Chicago and me working from Copenhagen gave us all a very different perspective than the prevalent money train of the Bay Area. One that I’m not sure would have stuck if we too had been trapped there.
There are lots of other materials to read to give you the strength to carry on. Jason and I wrote a number of books on these topics — Getting Real, REWORK, REMOTE, and I recently published a presentation called RECONSIDER. Those all give a very different perspective, but just as importantly, they give kinship to people who already thought like that but feared they were all alone in doing so. You’re not alone. There are many just like you, but most of them just don’t have or desire the megaphones of San Francisco.
Q: Now that you have the power of hindsight, what would you have changed?
I don’t believe in hindsight. If I knew what I know now, I might very well never have started Basecamp. I probably wouldn’t have gotten involved with Ruby on Rails. If someone had said, hey, this is going to take a decade or more from the best years of your life, what about it? Then I could totally have seen turning it all down! Ignorance is sometimes bliss and a beginner’s naivety is sometimes just the catalyst you need for change.
When you know too much, you know all the reasons why it’s not going to work. All those reasons will zap your zest and confine you to the comfortable. Besides, part of the fun of doing this for the first time is the novelty at every stage. I think that’s why many serial entrepreneurs don’t have nearly as much fun the second and the third time at the rodeo. They already went through this. Scrapping with just a couple of people is what you do when you have to, but once you know it all and have it all, it’s unlikely to start like that again. You’ll feel compelled to preempt problems that you might, possibly have in the future based on your experience. Which just adds weight and volume to the endeavor that it doesn’t need at that stage.
That’s part of why I’ve committed myself to sticking with it. To go the distance with Basecamp. That this is my life’s work and it could very well be the work for the rest of my life. I don’t need to go back to square one and try again, because I think in many important ways, I’d do a worse job at it than my ignorant 20-something self.
Q: Any other words of advice that you’d like to share with fellow first-time founders (and bootstrappers, especially)?
My best advice to someone trying to start a new business has been codified in the books and presentations I’ve given, but I will say a few things on motivations of growth. Most small businesses or people just starting out are saddled with lots of self-doubt and inadequacy issues. Oh, I’m just a small company. I’m just a few people. We just do work in this little niche. Stop that. Don’t apologize for being small. Small is wonderful, small is beautiful.
We made Basecamp with four people. I wrote the initial version of Ruby on Rails alone. Jason and I have been blogging on Signal v. Noise for more than a decade with lots of impact, without having some big backer.
Embrace the beginning. Love the beginning. You wouldn’t believe the number of big companies and people working there who’d love to trade their power for your nimbleness. Have confidence in what you do and why you do it. Then, even if things stay small forever, you can still feel great about it. I would be just as happy if Basecamp had not grown beyond what 10 people could have comfortably managed.
In addition to being a small business, Basecamp is all about helping other small businesses regain control as the first steps of success happens. Maybe you hired a few more people, maybe you took on a new really important client. Whatever it is, your old system isn’t cutting it any more. That’s when it’s time for Basecamp.
Conducting user research is now something that most successful brands do to improve their user experience and ultimately their bottom line. However, there is still a lot more potential to increase revenue and profitability as many brands still don’t do Read more ›
Read more ›
I saw this tweet recently:https://medium.com/media/bcd3951693a00ce82fafdec519f17e76/href
Great thought. And while this particular Tweet speaks to hiring, I think the sentiment applies to a whole bunch of things in your business — including your business itself.
What mode is your business in? Are you honing in on something? Have you already found a good product/market fit? And now you’re optimizing? Tightening? Going from good to great? From close to almost there to just right? Working on moving conversion from 12 to 13%? Working to get life time value from 00 to 00? Average ticket response time down from 38 minutes to 30 or even 20?
Optimization mode is like tuning an old radio with analog knobs. The station is 93.1, and you’re turning the dial around 93.0 and 93.2 to get the signal just right. Tiny movements back and forth until you eliminate the static and hear it loud it clear. Precision matters. When you hit it perfectly you know it.
Or are you in discovery mode? Setting out for all new territory? Trying a radical new idea? Going for something crazy just to see what happens? New business model? Launching a second product? Building up a team you’ve never had to do things you’ve never considered before? Branching into a new market? A new country?
Businesses can swing between honing and exploring, optimizing locally and trying brand new things generally. But it’s probably a good idea to know where you’re at right now. You’ll think differently about what you’re doing when the intent is clear.
The same applies to product development. Are you spending the next 4 weeks working to improve an existing feature or experience? Or are you working the next 4 weeks on something brand new — something your product never did before? A better version of an existing idea, or a brand new idea? The skills and approach and diligence you apply will be different.
In many ways this is about the scale of precision, of accuracy. If you’re in optimization mode, accuracy to the single digit — or even two decimals — matters. If you’re in exploration mode, you’re often starting from zero so anything is interesting. You just want to know if you’re roughly on to something. Headed in a potentially fruitful direction? Or going nowhere fast? When you’re in exploration mode, It doesn’t matter if you’re slightly off course as long as you’re headed somewhere entirely new.
Just know. You can be both at once, but each team should know which mode they’re in. Two teams working on optimization, one on exploration. I don’t think it’s realistic for the same people to be both at once.
We’re doing both at the same time with Basecamp 3. Every 6–8 weeks we start on a new set of work. Some of the work is about honing in, tightening something up that’s already there. And some of the work is exploratory — building something. brand new that we’ve never had in the product before. Check out what we’re up to.
Being a user-centered designer means that you deliberately seek out the stories, data, and rationale behind your users’ motivations. You endeavor to keep user concerns at the forefront of every design decision, and regularly conduct research and collect data.
But collecting facts about users isn’t the same as knowing your users. Research and data need to be regularly aggregated, analyzed, and synthesized into a format that is both understandable and accessible at critical moments. You need to turn user facts into user wisdom, and one of the most common methods for doing this is to develop user personas.
Type “how to build user personas” into your favorite search engine and you will get thousands of results outlining different templates and examples of personas. Across the tech industry, personas “put a human face on aggregated data,” and help design and product teams focus on the details that really matter. Studies have shown that companies can see 4x the return on investment in personas, which explains why some firms spend upwards of 0,000 on these design tools.
However, while it is common for design teams to spend considerable amounts of time and money developing personas, it is almost as common to see those personas abandoned and unused after a while. Everett McKay, Principal at UX Design Edge, has pointed out that user personas can fail for a number of reasons, such as:
- They do not reflect real target users.
- They are not developed with product goals in mind.
- They are not embedded into team processes.
I agree with everything McKay suggests, but I would add that personas fail largely because of one common misconception: the false idea that once you build a persona, you’re done. As designers, we know that the first version of a product is never perfect, but with multiple rounds of design and research it can be made better. Personas are no different.
To recover personas that have become lifeless, here’s how you can iterate on them with periodic research and use them to achieve tangible goals. The following steps will help ensure you see value from the investment you made developing them in the first place. Let’s put your personas (back) to work and incorporate them into your design and development process.
How a persona dies
Let’s imagine you work at a company called Amazing Childcare that creates tools to help parents find childcare options for their children. Let’s also say you have the following data and statistics for AmazingChildcare.com:
- 82% of customers are between the ages of 30 and 35, and 73% of those are female.
- The most common concerns around finding childcare (as reported in user interviews) are cost and quality of care received.
- AmazingChildcare.com has a homepage bounce rate of 40%.
- Customer satisfaction survey shows an average satisfaction rating of 6.5 (out of 10).
While this data is interesting, it is hard to process and assimilate into your design practice. You still need to go through the arduous work of understanding why the majority of users are who they are, what problems they are trying to solve, and how you can better meet their needs. So, you decide to create a persona.
The persona you create is Susan, a 34-year old working mother of a two-year-old. She is interested in finding a qualified nanny that has passed a background check. Susan, like all freshly made personas, is a much more thought-provoking platform for crafting design solutions than a spreadsheet of numbers. She is someone we can imagine, remember, and empathize with.
This is the point in the story when Susan dies.
At first, the design team enjoys thinking about and designing for Susan. Having her “in the room” is thought provoking and interesting, but over time, Susan is talked about less and less. She starts to feel irrelevant to the products you’re building. You realize that Susan has “died,” leaving a lifeless, zombie Susan sitting in her place. You consider all the research and work your team put into creating Susan and wonder “what went wrong?”
The problem is that your personas remained static and unmoving while the company, Amazing Childcare, grew and changed.
Review, research, repeat
As your product and marketing strategies change over time, so do your target users. In our example, Amazing Childcare may have started with a large user base of parents looking for full-time childcare options for their toddlers, but over time, the demographic changed. Now, it’s most frequently used by parents of school-age children looking for one-time, “date night” babysitters. When this happens, your original personas—like Susan—are no longer useful for thinking through design problems. Unless you periodically validate your personas, you’ll be responding to old assumptions (based on your outdated personas) rather than who your customers really are. In other words, your real-world users changed, but Susan didn’t.
To remedy this, you should regularly conduct persona research, using a variety of methods to evaluate whether your personas still reflect:
- The most common demographic, budget, and purchase scenarios of your users
- The main behavior patterns of your users
- The motivations and goals of your users.
You can conduct your persona research on a schedule, such as once a quarter, or you can opportunistically work it into the usability research you already do. Either way, you need to make a commitment to keeping your personas relevant.
If we go back to our example at Amazing Childcare, your personas would change based on the new research. Susan may still be a valid persona for your company, but your research would show that she no longer represents its core users, and should therefore no longer be your primary persona. Based on the updated research, you could develop a new persona named Beverly. Beverly is a 42-year-old mother of a 10-year-old boy and 7-year-old girl. Unlike Susan, Beverly is interested in finding an inexpensive babysitter for occasional date nights with her husband. You would use Beverly to think about the needs of the core user base, but only use Susan when you’re designing tools that directly cater to the demographic she represents.
It is natural and necessary for personas to evolve and change; personas like Susan can drift out of the limelight of “primary persona” and make room for new friends like Beverly. Your ecosystem of personas should be as dynamic as your ecosystem of users, and regular persona research will ensure that they evolve in sync.
Personas can help you do more than think about and design for target users. They can (and should) be used to help you reach real, tangible goals. Goals that reflect ways of increasing business, creating better user experiences, or both, will help you update your personas and develop your product. Even if you are not sure what is possible to achieve with personas, you should make an attempt at setting goals. Goals (even unachievable ones) provide a means for tracking the return on investment of your efforts.
To get started, try using this format from Tamara Adlin and John Pruitt.
|Goal or issue||How things are today||How we want things to be tomorrow||Ways to measure change|
|Description||A problem you would like your personas to solve.||A description of the current state of affairs.||A description of the “first step” in achieving your goal.||A description of analytics, research, or other methods you can use to measure progress.|
For each goal, you will need to identify how you’ll measure progress toward that objective. You may need to create surveys and interview scripts for some, while for others, you may need analytics tools.
Here is an example of a persona goal we could set at Amazing Childcare.
|Goal or issue||How things are today||How we want things to be tomorrow||Ways to measure change|
|Use our primary persona to drive feature development.||We have just started our business and believe users like “Susan” (our primary persona) will want certain features (like nanny search and background checks) to be truly satisfied. However, the Susan persona needs to be validated and tested.||We want to thoroughly research and validate our Susan persona and better understand how Amazing Childcare can meet our primary users’ needs.||We can validate the Susan persona and measure customer satisfaction through a series of surveys and interviews. We will know we’ve succeeded when the next feature release increases customer satisfaction with Amazing Childcare.|
Once you have created a set of goals for your personas, you can evaluate them as part of your regular research plan. If you find that you’re falling behind on any of your goals, you can research and recalibrate your personas based on the metrics you care about.
For instance, if we evaluated the Susan persona in the ways we’ve outlined above, the data we would uncover indicates that Susan doesn’t actually represent the majority of our users. We would then reevaluate our personas and ultimately develop our new primary persona, Beverly.
Putting personas (back) to work
While research and goal setting are good practices, in and of themselves, the real benefit of personas can be seen when you put them to use. Here are some suggestions for how to incorporate personas into your design practice:
- Start putting the face of your target persona at the top of every sketch, wireframe, and prototype. Encourage others to do the same.
- Put a comment in every product story or ticket that states the target persona for that feature.
- Shake up regular design meetings by asking a few people to roleplay as your personas. Throughout the rest of the meeting, have them look at every new design through the lens of their assigned persona.
- Conduct a workshop. Activities such as Persona Empathy Mapping reinvigorate and add detail to personas.
One of my favorite ways to utilize personas is to write scenarios in which they are the main character, then use them to explain research results. For example, let’s say we’re evaluating a new interface for the sign-up and login process on our website. Instead of presenting raw numbers (e.g., “10% of new users couldn’t find the sign-up interface”), we can present the data in a scenario, providing a way to understand a design problem that goes beyond statistics. Here is an example:
In the example above, we’re using Beverly to describe feature requirements, usage statistics, and study results. The benefits of using personas to explain these components is that you are simultaneously making messy and complex details easier to understand, and forcing yourself to deeply consider who you’re really designing for. According to Alan Cooper, you should “[d]esign each interface for a single, primary persona.” Focusing on a persona like Beverly forces us to define the parameters of what our design should accomplish and helps us ultimately evaluate its success.
Keeping personas alive
Developing personas and keeping them alive can be difficult. Without regular care and feeding, they can waste away and your investment in them will be lost. In The User Is Always Right, Steve Mulder described it best:
To ensure your personas are accepted, remembered, and used, you need to be the persona advocate on your team. As the persona advocate, you need to:
- Regularly conduct persona research.
- Set goals.
- Make sure there is always a place for your personas at the design table.
With creativity and persistence, you can cultivate a suite of well-researched, battle-tested user personas.
While being a persona’s advocate may seem like a lot of work, it’s worth doing. Personas are more than just a document, they are an experience. Taking the time to draft a set of user personas, use them, evaluate them, research them, and refresh them, forces you to consider who your users are, what their goals are, and how your product fits into their lives.
If you’re ready to become the persona advocate on your team, here are some additional resources to help you along:
- The Essential Persona Lifecycle: Your Guide to Building and Using Personas by Tamara Adlin and John Pruitt
- The User Is Always Right: A Practical Guide to Creating and Using Personas for the Web by Steve Mulder
- Persona Building—CaliberMind Lesson by Meg Dickey-Kurdziolek
- Introduction to User Personas by Silvana Churruca (the UX Lady)
- A Closer Look At Personas: What They Are and How They Work by Shlomo Goltz
- Core Ideas About Personas and The User Experience by Jeff Sauro
Understanding usability standards is only half the battle; we also need to apply those standards to our designs. In this second part of a two-part series, Danny and Patricia Franzreb walk through their user-centered approach to designing with usability standards in mind.
Leah Buley was a Principal Analyst at Forrester, where she conducted, analyzed, and published research on the role of design in business; the relationships among user experience, customer experience, and service design; and best practices for customer understanding and empathy. Until just a few months ago, Leah Buley was a Principal Analyst at Forrester, where she conducted, analyzed, and published research on the role of design in business; the relationships among user experience, customer experience, and service design; and best practices for customer understanding and empathy. She is now working as an independent design consultant and advisor through Leah Buley Co. When Leah presented the case study “The Marriage of Corporate Strategy and UX Strategy” at the first UX STRAT in 2013, she was a Design Strategist in Intuit’s Design Innovation Group. Earlier in her career, she was a Lead Experience Designer at Adaptive Path. Leah is the author of the Rosenfeld Media book The User Experience Team of One: A Research and Design Survival Guide and frequently speaks and blogs on UX topics. I recently interviewed Leah, shown in Figure 1, about her vision of where the combination of experience design and business strategy is headed in the coming years, which will be the topic of her upcoming keynote presentation at UX STRAT USA, as well as her recent research and work at Forrester. She’ll also be conducting a workshop on “How to Speak Strategy” at UX STRAT, which will take place on September 14–16, 2016. READMORE
UX skills—both strategic and technical—are no longer ancillary, nice-to-have, episodic considerations. User Experience has finally arrived! You may have heard this before—okay, perhaps many times before. I’ve said this a few times myself: “This is going to be the year for UX!” But, after my more than 15 years in this field, I’m personally convinced at last because I’m no longer predicting change. I’m seeing this change all around me. I think 2016 really is the year I’ll remember for the scales tipping toward User Experience as a strategy—when the business game changed in substantive ways. As a consultant who works with many clients on their experience strategy and design, I’m seeing strong evidence that UX skills—both strategic and technical—are no longer ancillary, nice-to-have, episodic considerations. READMORE