Just wanted to take a few minutes to reflect on 2016 and think about what's upcoming in 2017...
I think we (tech in general, I suppose) have finally gotten to the point where people are realizing that there is value to be had in design. More people than ever before are actually seriously considering, "When is the right time in the lifecycle of my product for me to bring in a designer?" Of course I would think that the answer is "from the beginning," but there are also times in which the technology itself has to be proven out before design can even begin. And then there's also the time when the team is just so heads down delivering functionality to their desperate users that design falls by the wayside.
The role I'm in at Netflix was originally supposed to be focused on assisting a single team. During the interview process, based on feedback and discussion, this role was expanded to include a handful of teams creating internal tools under my manager's purview. Over time, engineers and PMs creating all sorts of internal-facing tools came to me for design consulting, spending a short amount of time providing context about what their users were trying to do with their tool, how it was supposed to work, and what they wanted it to do. (I never thought about this before until a couple of coworkers pointed it out -- apparently I can understand how systems work quite quickly, which is what enables me to do this ad-hoc consulting.)
Looking back, I've provided design feedback and critique to quite a few people in the company. And of course, once you do a good job, they'll want you to do more. I'm at the point now where I'm not only designing for those teams I was originally tasked with, but also looking at taking on more responsibilities with more teams that need a lot more design help than I could give in a simple 1-hour consultation.
It's a lot of responsibility, frankly. I'm faced with the reality that I won't be able to devote quite as much time to the teams that I had focused on previously at a strategic and business level. I've been told that I need to give other people the chance to step up, for me to step back so that I refocus my energy elsewhere. I'm struggling with figuring out how to pull back while not producing unsatisfactory design work. It's going to be an exercise in communication for sure, but I find myself reinvigorated by the prospect of tackling new tools that solve new problems that I haven't been exposed to before.
It's funny. As a designer on internal tools, I don't get the benefit of "showing off" to people all the cool new pretty designs I made that do all these cool things and have neat interactions. Instead, I've got workhorse tools that get the job done as simply as possible. Is it sexy? Hell no. But is it useful? Oh yeah. That's indisputable. It's not glamorous, but it's fulfilling. I almost feel like I'm cheating sometimes, though. I get to have a captive user base who I can talk to and get feedback from whenever I want. Sure, they're sometimes demanding, but they're also reasonable and forthcoming and eager to make the product better.
Anyway. Enough musing for an evening.
Wednesday, January 4, 2017
Tuesday, March 1, 2016
Designer+PM skills
So, I've discovered and can predict that posting to this blog isn't going to be a regular occurrence. Oops. Life happens.
I've realized recently through assisting with the hiring of a designer here at Netflix that being a designer with product management skills is actually kind of rare. I honestly probably should've known this already, but I've also realized recently that some things that I thought were completely obvious (like how to structure logical IAs) are not so obvious to other people because they simply don't think that way. So maybe everything I'm going to write here seems glaringly obvious to some folks, but maybe it's not to others.
Being a designer with a PM bent is the only existence I have known, and I can't imagine how one could effectively function without the business side of things. I've received feedback that my ability to communicate, manage communication and timelines effectively, and question business decisions is vital to making me as effective as I am.
Communication
Communication seems like an obvious skill. Most designers are (or should be) well-versed in being able to talk about why they chose to make a design decision and what impact it has on the experience.
The less obvious portions of communication are challenging business assumptions and negotiating experiences with engineers. I'll save the first part for later in this post, but as for the latter, I can't imagine being a designer and ignoring technical feasibility. That's like plugging your ears and saying, "La la la la la" loudly.
I see design as being a bridge between business requirements, user experience, and technical feasibility, so for me it's usually:
Managing Communication and Timelines
So I think this one is more on the PM side of things, but is still very important to being a designer. My current role requires a lot of buy-in and agreement from multiple stakeholders to deliver an experience that achieves our desired business goals, is technically feasible within the timeline allotted, and is an intuitive and simple experience for users. Here are some things that I do:
I've realized recently through assisting with the hiring of a designer here at Netflix that being a designer with product management skills is actually kind of rare. I honestly probably should've known this already, but I've also realized recently that some things that I thought were completely obvious (like how to structure logical IAs) are not so obvious to other people because they simply don't think that way. So maybe everything I'm going to write here seems glaringly obvious to some folks, but maybe it's not to others.
Being a designer with a PM bent is the only existence I have known, and I can't imagine how one could effectively function without the business side of things. I've received feedback that my ability to communicate, manage communication and timelines effectively, and question business decisions is vital to making me as effective as I am.
Communication
Communication seems like an obvious skill. Most designers are (or should be) well-versed in being able to talk about why they chose to make a design decision and what impact it has on the experience.
The less obvious portions of communication are challenging business assumptions and negotiating experiences with engineers. I'll save the first part for later in this post, but as for the latter, I can't imagine being a designer and ignoring technical feasibility. That's like plugging your ears and saying, "La la la la la" loudly.
I see design as being a bridge between business requirements, user experience, and technical feasibility, so for me it's usually:
- What's the business goals we're trying to achieve? And making sure my design is hitting those goals.
- What's the optimal way for the design to achieve those business goals without considering feasibility first? And then making a bunch of different options for ease of communication.
- What can be built within the desired timeframe? This requires talking to a engineer who knows his/her stuff. Explain the business goals, explain the design goals you made, show him/her the options, and let him/her assess what's feasibility. Sometimes engineers have really awesome ideas that make your design better. Sometimes they can tell you right off the bat that this thing you're proposing would take months to build, so maybe let's work toward a solution that we can actually deliver in a shorter timeframe.
Of course sometimes you need to put your foot down for an optimal user experience, but most times, a "good enough" user experience is enough to pass muster. You can put it out there and see how users are actually interacting with your design before iterating on it to improve it. And of course, if it's not technically feasible, then the most awesome user experience in the world isn't going to matter because no one is using it. Done is better than perfect, and don't forget to learn and implement and re-evaluate after you launch the first time. (Express, Test, Cycle.)
Managing Communication and Timelines
So I think this one is more on the PM side of things, but is still very important to being a designer. My current role requires a lot of buy-in and agreement from multiple stakeholders to deliver an experience that achieves our desired business goals, is technically feasible within the timeline allotted, and is an intuitive and simple experience for users. Here are some things that I do:
- At the beginning of every spec, I document the business goals that we're trying to achieve with this project, and also (sometimes) key design, ops, or product decisions that were made in conjunction with the design to define the scope of the project.
- I hold design reviews to go through my first pass to mockups so that people can see the design, provide feedback, suggest changes -- and then I follow up afterward, usually the same day, in an email documenting all the changes that were suggested, what I did (or will do) with them, and action items for myself as well as other folks that are needed in order to get us to a final design.
- I have a distribution list to which I send out emails about upcoming design features that everyone should know about.
- I hold a meeting every release cycle to make sure people who are in charge of communicating changes to the users know what's coming and what are the important points to highlight.
- I maintain a Google document with all historical specs I've made so people can reference things we did in the past. I update this regularly with release dates, scheduled design review dates, etc. so people know when things happen.
- I don't usually put dates of releases in emails because that's usually not in my control. The only dates I do provide are "due-by" dates when I need people to reply to me or to do something for me. Otherwise, I let engineering provide the dates.
Question Business Decisions
This is super obvious to me, but I'm going to write about it anyway. I never understood people who just took marching orders without thinking; to be effective, I have to know why we're doing something. What's the issue today (or how do things work today that we think could be better)? What do we want to achieve and why? What kind of impact would this change have on our business? How do we measure that this is working? I don't know how anyone creates an effective design without this information. Heck, I don't know how anyone does anything effectively without this kind of context.
And if you hear something that makes you raise an eyebrow, ask about it. This was part of my personality before Netflix, but it's definitely a behavior that is embraced here. If you don't ask, who will? Sometimes people have already logically thought through all the things that you have questions about, and it's good to hear what their reasoning. Sometimes you're the one with the good points that makes everyone stop and question if we're doing the right thing. Sometimes nobody has any idea whether this is the right thing or not -- that's a great opportunity for some research or A/B testing. In any case, don't just sit there, participate. Know the reasons why.
One last thing...
Separate from being a designer with a PM bent, you should probably also have a working knowledge of some technical things, too. Even if you don't understand the finer details of how things work, you should at least be curious about how things are working behind the scenes. This helps you communicate with engineers in the correct terminology, prevent you from making rookie "I don't know how the system works" mistakes (aka shortcut your design process in some cases), and suggest helpful alternatives. Sometimes engineers think in straight lines, and as a designer who thinks about all sorts of different approaches, you could end up suggesting a fantastic solution (or the seed of one) because you understand a bit of the system. I've even been asked to consult on things that doesn't even have a UI because I understand the big picture of a system.
If you're a designer not doing these things, it doesn't mean you're a bad designer. These are just things that I've found to be useful and effective in my career.
Monday, June 1, 2015
Still skeptical of Google's user experience
I wanted to be a huge fan of How Google Finally Got Design. I really did.
It started out so promising, talking about the experience a user has with notifications on their mobile devices, the comparisons between iOS and Android and the software trying to figure out what's more important to you and making your life easier.
And then, it made a hard right turn into talking about visual design as the huge thing that fixed Google. "Great design" became interchangeable with "having a cohesive design language" -- mostly visual, maybe a bit interactive. Okay sure, design cohesion is difficult to achieve at a behemoth such as Google. I remember Intuit flip-flopping between a centralized design team and "embedded" design teams every couple of years, trying to strike the right balance between cohesion and business understanding. But that's exactly what this article is missing: business understanding as an integral part of user experience design.
I had a conversation with a former co-worker, also a user experience designer by profession, about this very same topic over dinner a few nights ago. I was relaying to her some recent difficulties of explaining to a coworker what it was that I did. My story went somewhat like this:
My former coworker laughed -- she knew exactly the struggle I was conveying, and followed it up with her own story about bringing UX design to the new startup she'd just joined, and how they don't factor in time for design in the development cycle.
Then she turned it around and asked, "How did we get here?"
Design has evolved. Rewind a few decades and the most prominent designers, the earth-shakers, are all about aesthetics. But where the profession of user experience design has arrived at today is more than just beauty and pixel perfection. It's about the user, why they need something, what they need to do, and how to help them accomplish those "jobs" as simply and intuitively as possible.
That's not just about visual design anymore. A cohesive visual language absolutely helps us get there: it sets standards and user expectations about hierarchy and how things probably will behave upon interaction. But it's not the entire picture. UX design today is about so much more than graphics, kerning, colors, and fonts.
My value as a designer is not just taking requirements from somebody and delivering a pretty package at the end of the day. I have to know the context, know the user, understanding what they're trying to do, and how, and why, before I can even begin on recommending a way to get them there. And that recommendation has to incorporate the business and technical aspects: what value does this provide the business, is it worth the cost, does it drive users to do what we want them; can we build it this way? If not, then how? What's the timeline? How do we break down a vision into digestible, developable, iterate-able, cohesive value-added projects?
All of this, my bread and butter, is completely glossed over in the article. It seems to imply that Google's struggle is with getting their culture to adopt Material Design. It seems to suggest that achieving great design can be boiled down to getting developers on board with a new visual and interactive style sheet. But let's be honest -- you can still have a beautiful product that still doesn't quite do what you need it to do. And that's where you need the entire user experience design package.
If Google really wants to deliver great design, they need to get UX designers involved in their products from the beginning of a project. That designer needs to have an equal seat at the table that's (typically) currently a dyad of business and tech. They should bring user empathy to the entire team from the outset so that everyone understands why they're trying to do whatever it is they're trying to do. And of course, the development process needs to leave enough time for multiple iterations, refined over time and usage, feedback and metrics, to really hone a great user experience.
It started out so promising, talking about the experience a user has with notifications on their mobile devices, the comparisons between iOS and Android and the software trying to figure out what's more important to you and making your life easier.
And then, it made a hard right turn into talking about visual design as the huge thing that fixed Google. "Great design" became interchangeable with "having a cohesive design language" -- mostly visual, maybe a bit interactive. Okay sure, design cohesion is difficult to achieve at a behemoth such as Google. I remember Intuit flip-flopping between a centralized design team and "embedded" design teams every couple of years, trying to strike the right balance between cohesion and business understanding. But that's exactly what this article is missing: business understanding as an integral part of user experience design.
I had a conversation with a former co-worker, also a user experience designer by profession, about this very same topic over dinner a few nights ago. I was relaying to her some recent difficulties of explaining to a coworker what it was that I did. My story went somewhat like this:
Coworker: "So what exactly is it that you do?"
Me: "I'm a user experience designer. So, I start by figuring out what it is that users what to do [with this tool], distill it down into requirements, and then design the interfaces so you can do those things."
Coworker: "Oh, you gather requirements. So you're like a product manager."
Me: "...not exactly. I also write hi-fi specs, like this." (I pulled up an example). "So, I specify what it should look like, and what it should do. And what colors and fonts work well here."
Coworker: "You do colors and fonts? Can you help my team pick what colors and fonts to use?"
Me: "I'm a user experience designer. So, I start by figuring out what it is that users what to do [with this tool], distill it down into requirements, and then design the interfaces so you can do those things."
Coworker: "Oh, you gather requirements. So you're like a product manager."
Me: "...not exactly. I also write hi-fi specs, like this." (I pulled up an example). "So, I specify what it should look like, and what it should do. And what colors and fonts work well here."
Coworker: "You do colors and fonts? Can you help my team pick what colors and fonts to use?"
My former coworker laughed -- she knew exactly the struggle I was conveying, and followed it up with her own story about bringing UX design to the new startup she'd just joined, and how they don't factor in time for design in the development cycle.
Then she turned it around and asked, "How did we get here?"
Design has evolved. Rewind a few decades and the most prominent designers, the earth-shakers, are all about aesthetics. But where the profession of user experience design has arrived at today is more than just beauty and pixel perfection. It's about the user, why they need something, what they need to do, and how to help them accomplish those "jobs" as simply and intuitively as possible.
That's not just about visual design anymore. A cohesive visual language absolutely helps us get there: it sets standards and user expectations about hierarchy and how things probably will behave upon interaction. But it's not the entire picture. UX design today is about so much more than graphics, kerning, colors, and fonts.
My value as a designer is not just taking requirements from somebody and delivering a pretty package at the end of the day. I have to know the context, know the user, understanding what they're trying to do, and how, and why, before I can even begin on recommending a way to get them there. And that recommendation has to incorporate the business and technical aspects: what value does this provide the business, is it worth the cost, does it drive users to do what we want them; can we build it this way? If not, then how? What's the timeline? How do we break down a vision into digestible, developable, iterate-able, cohesive value-added projects?
All of this, my bread and butter, is completely glossed over in the article. It seems to imply that Google's struggle is with getting their culture to adopt Material Design. It seems to suggest that achieving great design can be boiled down to getting developers on board with a new visual and interactive style sheet. But let's be honest -- you can still have a beautiful product that still doesn't quite do what you need it to do. And that's where you need the entire user experience design package.
If Google really wants to deliver great design, they need to get UX designers involved in their products from the beginning of a project. That designer needs to have an equal seat at the table that's (typically) currently a dyad of business and tech. They should bring user empathy to the entire team from the outset so that everyone understands why they're trying to do whatever it is they're trying to do. And of course, the development process needs to leave enough time for multiple iterations, refined over time and usage, feedback and metrics, to really hone a great user experience.
Friday, September 27, 2013
Ha! So I guess I lied in my last post about posting more regularly. Sigh. That's what happens with life catches up with you, I suppose.
I've left Ariba and am now at Netflix. I'm pretty excited to be here. I think Ariba has its pluses and its minuses, and it was a good learning experience for me to discover what I really cared about.
During the time I was thinking about a change, I had many a discussion with other UX professionals about that the "next" option might be, from contract work to design firms to full-time employment -- some things which I've never really considered until now. It is interesting to see how the employment culture has changed, however; previously, I think being a "lifer" was the thing to do. Nowadays, the prevalence of contract work has increased, and we (especially in the software industry) are jumping from company to company more quickly now.
So here's what (little) I've learned about the different possible modes of employment for a UX designer (yes, there are probably more...):
Full-Time Employment
Pros: Stable paycheck, stable stream of work, could possibly switch within company (depending on size) if you don't like what you're working on, potentially great benefits/culture/people
Cons: Harder to leave if you discover you don't like it (culture, projects, people, compensation, etc.)
Individual Contractor/Freelancer
Pros: Flexible schedule, work only on what you like, likely pays a lot more than full-time employement
Cons: The onus is on you to find your own employment (so you gotta get good at selling your own skills), you gotta find/take care of your own healthcare, sometimes there are renewal limits when contracting at the same company for a period of time
Design Firm
Pros: Variety of projects, you can more often choose only to work on the projects you're interested in
Cons: Sometimes the projects don't come and then you don't get paid, potentially long hours when a project is in crunch time
I think some questions that were important to ask myself when assessing whether to stay or start looking again includes:
If you haven't seen Netflix's culture deck when it made its rounds a few years ago, this is pretty good to look through. It's definitely not a corporate mentality you stumble across very often.
I've left Ariba and am now at Netflix. I'm pretty excited to be here. I think Ariba has its pluses and its minuses, and it was a good learning experience for me to discover what I really cared about.
During the time I was thinking about a change, I had many a discussion with other UX professionals about that the "next" option might be, from contract work to design firms to full-time employment -- some things which I've never really considered until now. It is interesting to see how the employment culture has changed, however; previously, I think being a "lifer" was the thing to do. Nowadays, the prevalence of contract work has increased, and we (especially in the software industry) are jumping from company to company more quickly now.
So here's what (little) I've learned about the different possible modes of employment for a UX designer (yes, there are probably more...):
Full-Time Employment
Pros: Stable paycheck, stable stream of work, could possibly switch within company (depending on size) if you don't like what you're working on, potentially great benefits/culture/people
Cons: Harder to leave if you discover you don't like it (culture, projects, people, compensation, etc.)
Individual Contractor/Freelancer
Pros: Flexible schedule, work only on what you like, likely pays a lot more than full-time employement
Cons: The onus is on you to find your own employment (so you gotta get good at selling your own skills), you gotta find/take care of your own healthcare, sometimes there are renewal limits when contracting at the same company for a period of time
Design Firm
Pros: Variety of projects, you can more often choose only to work on the projects you're interested in
Cons: Sometimes the projects don't come and then you don't get paid, potentially long hours when a project is in crunch time
I think some questions that were important to ask myself when assessing whether to stay or start looking again includes:
- Am I happy to go to work every day?
- Do I enjoy working with the other people here?
- Am I learning new things here (from people or tech)?
- Are there opportunities to work on exciting things here, or with exciting people?
- Is this job sustainable?
- Does my manager respect me and help me advance my career?
If you haven't seen Netflix's culture deck when it made its rounds a few years ago, this is pretty good to look through. It's definitely not a corporate mentality you stumble across very often.
Culture from Reed Hastings
Tuesday, March 26, 2013
Challenges for Design & Innovation in Engineering-driven Businesses
So I haven't been writing, pretty much ever since I started my new job -- probably for lack of decompressed brain space to use to think about this stuff, form an opinion on things that happened at work, and read and share good articles. Well, back to it more regularly now, I hope.
Moving from my quirky little division within Intuit to Ariba was a big shock for me. And, the more I've spoken to others about it, the more they tell me that what I have now is normal. "Homestead," they say, "was unique." Apparently not many other companies (outside of startups) are filled with people who value the same things you do. Apparently it's rare to make that many friends at work that you keep seeing outside of work as we do. Apparently, the lack of politics and the presence of people who are self-starting and willing to do whatever it takes because they care aren't so common anymore.
It's a little disappointing and, frankly, frightening to think that the best days you've had at work are behind you. It makes me think that I ought to look at startups next.
Ariba is apparently pretty much what most large companies in the Valley are like right now (save a notable few): historically engineering-driven behemoths, sad relics of the past that didn't realize that the world around them was slowly changing, until recently they were suddenly confronted with the fact that their old systems, processes, and products are aging dinosaurs, and that their end users (not the customers) want more than they can really handle, given what they have.
Does this sound familiar to anyone?
One of the reasons I came to Ariba was to turn this dinosaur around, to attempt to push it toward a leaner, user-centric, embracing-design-thinking type of culture. I don't know if it's working yet because I don't feel like I see any changes, but then again, I don't have a true baseline; by the time I arrived, people had already realized that change was needed.
Despite that, the major challenges I see here include:
1. Fear
I see many types of fear here: fear of change, fear of the unknown, fear of upper management, fear of sticking your neck out for what you think is right out of fear of losing your job. Some of these fears are normal, human behaviors that probably are present wherever you go. Some of these fears are, I'm afraid (pun intended), directly caused by the culture here and are unhealthy. The point when people are afraid to do things in different ways because they're afraid of what upper management says about them is the point you can say sayonara, sucker to innovation and the "little guy" following his or her own moral and ethical compass.
2. Artificial Measures of Success
What is true success for a company? The textbook answers are things like revenue, increased growth year-over-year, soaring stock prices, that you delivered what you promised customers. What do you use to measure this? Monthly recurring revenue. How many years your customers use your software to do their work. How often you hit your promised deadlines. Deliver the product, deliver results.
Yes, those are all still important, but with the rise of design thinking, the metrics that you measure success against become end user satisfaction (perhaps even delight), usage, comprehension, ease. What do you use to measure this? Net Promoter score? Tracking information from your products? User interviews? Surveys? The problem is that end user delight is difficult to measure. It's not prescribed in textbooks. You have to triangulate the information through many different measure, some of which aren't quite as clean-cut as we'd like them to be.
So, business tends to fall back to the concrete measures -- revenue, growth, etc. -- that aren't related closely enough to the factors that actually drive them -- like user satisfaction, word-of-mouth. And when this is what we measure ourselves on, we start driving toward artificial successes: increase monthly recurring revenues by raising the prices on our products, increase our "on time" ratings by delivering features in which it's possible to complete the target tasks.
3. Rewarding Behavior that serves Artificial Ideas of Success
The problem is compounded when behavior that feeds these artificial measures of success is rewarded. People care about self-actualization; we like praise; we like reward. So of course we'll bias heavily to those behaviors that get us reward and recognition. We'll allocate our time to doing work that gets us paid. Unfortunately, sometimes that is not asking questions, building the first solution we come up with, delivering a feature on time even if people have legitimate concerns about it -- hey, it was on time!
4. No Space to Breathe, Never Mind Innovate
I don't know if 10% time really works or not, but when people's timelines are so tight that there is no time to decompress, that works even less. Simply stepping back to assess one's situation requires space, and creativity and innovation needs even more. No one is going to be motivated to improve their current processes when they are up to their eyebrows in it. No one wants to stop the current train of deliver, deliver, deliver to make space for considering and digging deep into a user's needs.
But enough with the negatives. Let me leave you with the following delightful presentation:
I also highly recommend watching the YouTube video linked from slide 3: http://www.youtube.com/watch?v=e-ySKaZJ_dU
Moving from my quirky little division within Intuit to Ariba was a big shock for me. And, the more I've spoken to others about it, the more they tell me that what I have now is normal. "Homestead," they say, "was unique." Apparently not many other companies (outside of startups) are filled with people who value the same things you do. Apparently it's rare to make that many friends at work that you keep seeing outside of work as we do. Apparently, the lack of politics and the presence of people who are self-starting and willing to do whatever it takes because they care aren't so common anymore.
It's a little disappointing and, frankly, frightening to think that the best days you've had at work are behind you. It makes me think that I ought to look at startups next.
Ariba is apparently pretty much what most large companies in the Valley are like right now (save a notable few): historically engineering-driven behemoths, sad relics of the past that didn't realize that the world around them was slowly changing, until recently they were suddenly confronted with the fact that their old systems, processes, and products are aging dinosaurs, and that their end users (not the customers) want more than they can really handle, given what they have.
Does this sound familiar to anyone?
One of the reasons I came to Ariba was to turn this dinosaur around, to attempt to push it toward a leaner, user-centric, embracing-design-thinking type of culture. I don't know if it's working yet because I don't feel like I see any changes, but then again, I don't have a true baseline; by the time I arrived, people had already realized that change was needed.
Despite that, the major challenges I see here include:
1. Fear
I see many types of fear here: fear of change, fear of the unknown, fear of upper management, fear of sticking your neck out for what you think is right out of fear of losing your job. Some of these fears are normal, human behaviors that probably are present wherever you go. Some of these fears are, I'm afraid (pun intended), directly caused by the culture here and are unhealthy. The point when people are afraid to do things in different ways because they're afraid of what upper management says about them is the point you can say sayonara, sucker to innovation and the "little guy" following his or her own moral and ethical compass.
2. Artificial Measures of Success
What is true success for a company? The textbook answers are things like revenue, increased growth year-over-year, soaring stock prices, that you delivered what you promised customers. What do you use to measure this? Monthly recurring revenue. How many years your customers use your software to do their work. How often you hit your promised deadlines. Deliver the product, deliver results.
Yes, those are all still important, but with the rise of design thinking, the metrics that you measure success against become end user satisfaction (perhaps even delight), usage, comprehension, ease. What do you use to measure this? Net Promoter score? Tracking information from your products? User interviews? Surveys? The problem is that end user delight is difficult to measure. It's not prescribed in textbooks. You have to triangulate the information through many different measure, some of which aren't quite as clean-cut as we'd like them to be.
So, business tends to fall back to the concrete measures -- revenue, growth, etc. -- that aren't related closely enough to the factors that actually drive them -- like user satisfaction, word-of-mouth. And when this is what we measure ourselves on, we start driving toward artificial successes: increase monthly recurring revenues by raising the prices on our products, increase our "on time" ratings by delivering features in which it's possible to complete the target tasks.
3. Rewarding Behavior that serves Artificial Ideas of Success
The problem is compounded when behavior that feeds these artificial measures of success is rewarded. People care about self-actualization; we like praise; we like reward. So of course we'll bias heavily to those behaviors that get us reward and recognition. We'll allocate our time to doing work that gets us paid. Unfortunately, sometimes that is not asking questions, building the first solution we come up with, delivering a feature on time even if people have legitimate concerns about it -- hey, it was on time!
4. No Space to Breathe, Never Mind Innovate
I don't know if 10% time really works or not, but when people's timelines are so tight that there is no time to decompress, that works even less. Simply stepping back to assess one's situation requires space, and creativity and innovation needs even more. No one is going to be motivated to improve their current processes when they are up to their eyebrows in it. No one wants to stop the current train of deliver, deliver, deliver to make space for considering and digging deep into a user's needs.
But enough with the negatives. Let me leave you with the following delightful presentation:
I also highly recommend watching the YouTube video linked from slide 3: http://www.youtube.com/watch?v=e-ySKaZJ_dU
Friday, December 14, 2012
A collection of Design articles
I'm using this blog to also document/store links to UX-related things, so here's a dump of a bunch of them. This collection is a little more geared to good reading about Design & Great Products, in no particular order...
Startups, this is how design works
- Pretty fundamental description of what design is and isn't.
- Includes Dieter Rams' Ten Principles of "Good Design" (more about these ten principles here and here, with accompanying visuals)
- Explains different types of design (UX vs UI, visual, etc.)
- Design founders
- How to find designers
What your company will look like when Millennials call the shots
Ten core principles that successful business will adhere to:
- Enable open collaboration across the organization. Remove silos and enable diverse cross-functional teams
- Ask for more from every employee. Continually present new challenges and allow for rapid growth for those who perform
- Value ideas over experience. Seek out and recognize good ideas wherever they exist in your eco-system, whether from the CEO, mail room clerk, supplier or even customer
- Engineer humanity. Utilize technology to make products more customized, communications more personal and consumers lives more enhanced
- Don’t skimp on quality. Consumers will quickly avoid those products that fail to meet their expectations and have megaphones to ensure their thoughts are heard
- Integrate responsibility into the core of the business. Don’t give back- be a company with a mission beyond just profits
- Be genuine. Don’t hide behind celebrity personas- focus on connecting to individual consumers and communities in ways that are authentic, relevant and meaningful
- Think 2-Way. Partner with consumers across all areas of the business- live and breathe transparency and open communication
- Foster advocacy. Build products and create marketing that invites consumers to share and leverages word-of-mouth, the most influential source of information
- Change. If your business is not continually searching, evolving and finding new ways to do things, you won’t keep up
Don't Let the Minimum Win Over the Viable
Helpful best practices:
- "MVP" doesn't mean "smallest imaginable" -- it means knowing the core features and not adding anything beyond that.
- Prototype (and test) multiple MVPs simultaneously, so that the team doesn't get anchored in one.
- Embrace a smart business model design & hypothesis. It doesn't have to be perfect -- it should evolve as your MVP does -- but you should have some idea of the economics from the start
- Stay true to your vision and the passion behind it
- The market will change -- be aware of how you might adapt as it does
How LEGO turned its brand
- Biggest point: You need constraints -- real problems, guiding principles -- for design to actually productively help
How To Ask--And Listen--Like You Mean It
http://www.fastcompany.com/3001537/how-ask-and-listen-you-mean-it?
Fostering a Culture of Dissent
http://www.nytimes.com/2011/07/17/business/david-sacks-of-yammer-on-fostering-dissent-corner-office.html?pagewanted=all
Emotionally Intelligent Interactions
http://uxdesign.smashingmagazine.com/2012/03/28/give-your-website-soul-with-emotionally-intelligent-interactions/
Ending the opinion wars: fast, collaborative design direction
http://usabilitytesting.wordpress.com/2012/08/18/ending-the-opinion-wars-fast-collaborative-design-direction/
Working Backwards
http://www.allthingsdistributed.com/2006/11/working_backwards.html
A way to get to shared vision by starting with the "end product" (the LEGO piece also has a bit of this).
A New Mobile UX Design Material
http://uxdesign.smashingmagazine.com/2012/10/30/motion-animation-new-mobile-ux-design-material/
Applying principles from animation to mobile. Most of it is pretty straightforward, but good to think about anyway.
http://www.fastcompany.com/3001537/how-ask-and-listen-you-mean-it?
- Tips on inquiry and reflective listening
- Includes pitfalls to genuine listening (it's hard!!)
Fostering a Culture of Dissent
http://www.nytimes.com/2011/07/17/business/david-sacks-of-yammer-on-fostering-dissent-corner-office.html?pagewanted=all
- On leadership: delegate, but be involved in the small things that make the biggest impact. Give employees a voice (in everything!), the power to influence, the knowledge that dissent is truly valued, and clear responsibilities and objectives.
- On hiring: Involve a lot of people, so that new hire will have the support of them when they start. Would hire for good problem solving over experience.
- Goal-setting: MORPH = Mission (what's your mission at the company, in one sentence?); Objective (top 3-5 goals for the quarter); Results (metrics to measure those objectives); People (what changes need to happen to achieve this?); How (as in, How did you do?)
Emotionally Intelligent Interactions
http://uxdesign.smashingmagazine.com/2012/03/28/give-your-website-soul-with-emotionally-intelligent-interactions/
- It's basically paying attention to details that give personality to your site/brand. It's great especially to turn a potential negative experience into something positive (like siteerror404's, timeouts, and such) or livening up dead points in the experience.
Ending the opinion wars: fast, collaborative design direction
http://usabilitytesting.wordpress.com/2012/08/18/ending-the-opinion-wars-fast-collaborative-design-direction/
- Make sure you get past people's natural inclinations to jump to conclusions, and actually take the time to explore the why's, to look at the strength of the data to support design decisions (and saying no), and mostly allowing the whole team full participation in the journey.
http://www.allthingsdistributed.com/2006/11/working_backwards.html
A way to get to shared vision by starting with the "end product" (the LEGO piece also has a bit of this).
A New Mobile UX Design Material
http://uxdesign.smashingmagazine.com/2012/10/30/motion-animation-new-mobile-ux-design-material/
Applying principles from animation to mobile. Most of it is pretty straightforward, but good to think about anyway.
Friday, December 7, 2012
Adopting Design Thinking
I was scouring old information and decks today and found some slides/decks that, although fairly basic and targeted at the design thinking initiate, were still pretty relevant to the practice of trying to get non-believers to understand why design thinking matters, and what kind of difference it can make.
Traditional vs. Design Thinking
The first was this slide from an Innovation & Delight slide deck that sums up the differences in simple terms:
Why Design Thinking Matters
Finally, another deck, this one from Jan Schmiedgen, focused on introducing design thinking to the business-minded (he calls them "convergent thinkers" -- haha):
A great summary, I thought, of arguments for design thinking. (I bet there were several illustrative stories told to accompany this presentation.) Toward the end, starting on slide 74, he gets into highlighting the differences between traditional business thinking and design thinking. I particularly liked the quote on page 89; it really highlights the gap we have today and where we could be.
Traditional vs. Design Thinking
The first was this slide from an Innovation & Delight slide deck that sums up the differences in simple terms:
Of course, it's one matter to understand the concepts here, and another one entirely to actually be able to act upon these every day. Or, better yet, inspire others to start behaving like a design thinker.
How Design Thinking is Different from UX Design
The second is this deck from Sylvain Cottong on the differences between UX design, service design, and design thinking:
Overall this isn't anything that is new to a UX or design thinking practitioner, but looking at it from the lens of someone whose organization is not converted or equipped just yet to convert to using design thinking as a matter of course, it had some clear details about what is and what isn't different facets of design, and why one should care.
It was published in 2009, so there are certainly some things in there that I wouldn't agree with (particularly some of the definitions of design thinking on page 53), and some things that have definitely withstood the past 3 years (slide 58).
Particularly worth a skim for anyone thinking about doing UX (the first section on UX is pretty comprehensive), and understanding how design thinking is gradually moving forward business.
Why Design Thinking Matters
Finally, another deck, this one from Jan Schmiedgen, focused on introducing design thinking to the business-minded (he calls them "convergent thinkers" -- haha):
A great summary, I thought, of arguments for design thinking. (I bet there were several illustrative stories told to accompany this presentation.) Toward the end, starting on slide 74, he gets into highlighting the differences between traditional business thinking and design thinking. I particularly liked the quote on page 89; it really highlights the gap we have today and where we could be.
Subscribe to:
Posts (Atom)