I've included a few sections like this one on Design Process that are less portfolio examples and more like design articles. These are intended to provide insights into how I think about design within a company and across teams. They also convey a wide range of experiences dealing with a variety of communication and collaboration issues that recur in different forms across all companies.
User experience is not owned by the UX team. Everyone in the company has a stake in the user experience from sales to marketing to admins. Every touchpoint someone has with a product or company, their expectations, what they hear from their friends...this is all part of the user experience. Design helps shape these touchpoints. They don't own them.
At Google, we had structured design reviews and template decks. There were typically three phases of approval: concept, design proposals, final design. Launch, post-launch, and post-mortems (when needed) happened separately from the reviews.
At PicsArt, I set up a similar series of structured review processes, built templates to help PMs and UX collaborate and prepare (Jira templates), and revised these over time get more principled design feedback and timely input from stakeholders (challenging over 12 timezones).
Ideally design is this beautiful, fluid process of formative research, insights, ideation, sketching, prototyping, rapid testing and refinement that resembles a double or triple diamond shape (from Google Sprint Guidebook):
At Google, we had structured design reviews and template decks. There were typically three phases of approval: concept, design proposals, final design. Launch, post-launch, and post-mortems (when needed) happened separately from the reviews.
At PicsArt, I set up a similar series of structured review processes, built templates to help PMs and UX collaborate and prepare (Jira templates), and revised these over time get more principled design feedback and timely input from stakeholders (challenging over 12 timezones).
Ideally design is this beautiful, fluid process of formative research, insights, ideation, sketching, prototyping, rapid testing and refinement that resembles a double or triple diamond shape (from Google Sprint Guidebook):
In reality UX design and research fits into something that looks more like this where, if you aren't fast enough, you are rushed to make mocks and maybe have time for usability testing after launch:
The question is how to scale up design teams to work effectively with a range of processes that might differ based on the team or business unit they land in.
These are the design process questions managers of large distributed teams like mine face. I've figured out how to do this surprisingly well with UI designers and interns ultimately turning them into UX designers who operate near the level of senior designers. It's not just about mentoring and creating a culture of design. It's also about working with product and engineering.
DESIGN PRINCIPLES
Design Principles are the high level agreements we have as a team about design. They are the foundation of the culture of the UX team. However, design principles are not rules. They are guidelines. There are always exceptions - sometimes contextual, sometimes performance related. I also recognize that different countries and cultures have different aesthetics. I spent several years working with teams in China and Japan and have direct experience adapting solutions to those markets.
Design principles need to be specific enough to apply directly to a company and it's products, but not so general that they are not actionable. I typically encourage teams to define principles (in blue below) and them provide some guidelines and examples of how those can guide designs. These are works-in-progress. We have tried high fidelity images vs. schematics for examples. Both have pros & cons.
Here are a few examples of design principles for the PicsArt team which operates in the creative, photo sharing and community space. There is some overlap between these points which is intentional. Repetition contributes to learning outcomes. You can find more Design Principles for PicsArt here.
These are the design process questions managers of large distributed teams like mine face. I've figured out how to do this surprisingly well with UI designers and interns ultimately turning them into UX designers who operate near the level of senior designers. It's not just about mentoring and creating a culture of design. It's also about working with product and engineering.
DESIGN PRINCIPLES
Design Principles are the high level agreements we have as a team about design. They are the foundation of the culture of the UX team. However, design principles are not rules. They are guidelines. There are always exceptions - sometimes contextual, sometimes performance related. I also recognize that different countries and cultures have different aesthetics. I spent several years working with teams in China and Japan and have direct experience adapting solutions to those markets.
Design principles need to be specific enough to apply directly to a company and it's products, but not so general that they are not actionable. I typically encourage teams to define principles (in blue below) and them provide some guidelines and examples of how those can guide designs. These are works-in-progress. We have tried high fidelity images vs. schematics for examples. Both have pros & cons.
Here are a few examples of design principles for the PicsArt team which operates in the creative, photo sharing and community space. There is some overlap between these points which is intentional. Repetition contributes to learning outcomes. You can find more Design Principles for PicsArt here.
Give users clear choices & feedback
Every view should have an easily identifiable and visually salient primary action
Make it easy to undo and reset changes everywhere
Provide feedback on actions so users know they succeeded
Make sure users know what the error is and how to correct it
Show where things can be found after acting on them
Iteratively reveal functionality
Point users to the primary controls that have the largest impact
Guide users at appropriate moments to access the full set of advanced functions
Create transitions and levels (Android) that highlight the important controls
Provide tooltips for the important or hard-to-discover functionality
USER-CENTERED DESIGN
Put the user first and all else will follow. This was the mantra at Google. It was also adopted by PicsArt. It didn't really matter that people had different interpretations of what this meant. The important thing was that it put people and their needs first.
It turns out most people don't know what a user needs is or how to find out what users really want. After some experimentation, this question seemed to start the process "Why would someone want to use this thing we are building, this service we are offering?" which we translated into the sentence completion: "As a user, I want to use this feature because..."
Having been a PM, I know the importance of clearly defining functionality, product goals, revenue, and growth projections. These items are required for engineering and other teams to execute and meet deadlines. They define impact and move KPIs. But starting by defining functionality without thinking about why someone would use your product, service, widget can lead to building a lot of things people don't want or need.
As a UX designer and team leader, I push both UX and PMs to ask a lot of Why questions when they kick off projects. This is harder than it sounds. It's a skill that can be learned. I have several steps I use to make sure this works. The first step is to help people understand what we mean by user needs, user journeys, mental models. With a little user testing in real life, people quickly see the difference between what people say and do and what they feel and believe. This is what Alan Cooper meant when he said that people need to get out of the building.
USER NEEDS
At PicsArt, I worked with the PM and engineering leadership to require that user needs be part of the product sign-off process and that everyone agree on them when the project starts. Designs (from anyone - even the CEO) are required to have pros and cons specified. These pros and cons relate to the agreed upon user needs. The result is that as a team we evaluate alternatives based on user needs not personal preferences. Sometimes the product/company goals aren't aligned with user needs which decreases the changes of success and requires more discussion.
DESIGN SPRINTS
My first step at a new company is to provide insights into design, have as much fun as possible, learn who people are, what they like, what they think is funny, get people to share and tell stories about themselves and what they know about the product or company. PARC researchers discovered that this was how knowledge got passed down from Xerox repair people and it still works better than any presentation system or collaborative online thing you type or paste things into.
At Google, I worked with a PM named Clayton Jones. Together we got approval for the first major initiative in China after Google moved it's servers to Hong Kong. It was a B2B initiative to get more global businesses onto Google and provide ways for them to reach other businesses (vs. consumers through Google ads). We described the project as "Alibiba without the thieves" because it involved certification by international groups in a variety of areas as a way to ensure quality and trust.
I ran a design sprint with the Google engineering team in Shanghai to envision how the supplier and buyer interactions might work:
Put the user first and all else will follow. This was the mantra at Google. It was also adopted by PicsArt. It didn't really matter that people had different interpretations of what this meant. The important thing was that it put people and their needs first.
It turns out most people don't know what a user needs is or how to find out what users really want. After some experimentation, this question seemed to start the process "Why would someone want to use this thing we are building, this service we are offering?" which we translated into the sentence completion: "As a user, I want to use this feature because..."
Having been a PM, I know the importance of clearly defining functionality, product goals, revenue, and growth projections. These items are required for engineering and other teams to execute and meet deadlines. They define impact and move KPIs. But starting by defining functionality without thinking about why someone would use your product, service, widget can lead to building a lot of things people don't want or need.
As a UX designer and team leader, I push both UX and PMs to ask a lot of Why questions when they kick off projects. This is harder than it sounds. It's a skill that can be learned. I have several steps I use to make sure this works. The first step is to help people understand what we mean by user needs, user journeys, mental models. With a little user testing in real life, people quickly see the difference between what people say and do and what they feel and believe. This is what Alan Cooper meant when he said that people need to get out of the building.
USER NEEDS
At PicsArt, I worked with the PM and engineering leadership to require that user needs be part of the product sign-off process and that everyone agree on them when the project starts. Designs (from anyone - even the CEO) are required to have pros and cons specified. These pros and cons relate to the agreed upon user needs. The result is that as a team we evaluate alternatives based on user needs not personal preferences. Sometimes the product/company goals aren't aligned with user needs which decreases the changes of success and requires more discussion.
DESIGN SPRINTS
My first step at a new company is to provide insights into design, have as much fun as possible, learn who people are, what they like, what they think is funny, get people to share and tell stories about themselves and what they know about the product or company. PARC researchers discovered that this was how knowledge got passed down from Xerox repair people and it still works better than any presentation system or collaborative online thing you type or paste things into.
At Google, I worked with a PM named Clayton Jones. Together we got approval for the first major initiative in China after Google moved it's servers to Hong Kong. It was a B2B initiative to get more global businesses onto Google and provide ways for them to reach other businesses (vs. consumers through Google ads). We described the project as "Alibiba without the thieves" because it involved certification by international groups in a variety of areas as a way to ensure quality and trust.
I ran a design sprint with the Google engineering team in Shanghai to envision how the supplier and buyer interactions might work:
Impact: We had different teams working on the supplier and buyer sides of the product. This experience connected the teams and shared a lot of valuable knowledge that helped them understand the rationale, mindset, and experience driving the requirements for the suppliers and buyers. It also help everyone get to know each other so that even junior engineers knew me and felt comfortable questioning my input and decisions which ultimately led to better product and engineering solutions, as well as a sense of ownership.
OFFICE-WIDE SPRINTS
On my first trip to PicsArt's office in Yerevan, Armenia (a 20 hour flight) I ran a design sprint with the entire office (200 people at the time). This was something completely different for the office and helped people get in touch with the experience and story around the product versus the interface and functionality.
On my first trip to PicsArt's office in Yerevan, Armenia (a 20 hour flight) I ran a design sprint with the entire office (200 people at the time). This was something completely different for the office and helped people get in touch with the experience and story around the product versus the interface and functionality.
insert videos of people's stories here
WORKSHOPS & TALKS
Both within and outside Google, I played a leadership role in promoting the connection between research, innovation, and design to launch a series of new products. I bring a unique ability to instill a culture of design thinking within teams and companies, setting up new processes and activities to energize and empower the entire organization.
Here is a short list of some accomplishments in this area:
Leader for day-long team-based design sprints and product sessions for:
WORKSHOPS & TALKS
Both within and outside Google, I played a leadership role in promoting the connection between research, innovation, and design to launch a series of new products. I bring a unique ability to instill a culture of design thinking within teams and companies, setting up new processes and activities to energize and empower the entire organization.
Here is a short list of some accomplishments in this area:
- First UX team member to lead design sprint workshops as part of the Creative Skills Institute (CSI)
- Led product-focused Creative Skills Institute (CSI) workshops in MTV, NYC, Tokyo, LA and Shanghai
- SXSW: highest rated and most over-subscribed workshop 2014
- C2-MTL (Creativity & Commerce) Montreal, 2014 (workshop and talk)
- YouTube Brand Studio LA invited talk for our top advertisers representing $1B in annual spend.
- Oracle-Google all-hands design leadership invited talk as part of a strategic sales partnership.
Leader for day-long team-based design sprints and product sessions for:
- Ads Innovation
- Re-Imagine Google Translate
- Re-Imagine Jobs Site workshop for PeopleDev
- Re-imagine The Future Google Retail Experience
- Multiple brown bags, UX Week workshops, gLearn classes on design
- Developed a new workshop and talk on Brand Experiences, Design Thinking and Innovation
FROM SKETCHES TO PROTOTYPES
Design sprints help introduce team members to the idea of starting with ideas and experiences and building up to a sequence of interactions and then wireframes.
Design sprints help introduce team members to the idea of starting with ideas and experiences and building up to a sequence of interactions and then wireframes.
Crazy 8s: Sketch a series of ideas in 8 minutes
|
Story Panels: A sequence of steps in an experience
|
Wireframe
|
Prototyping is an important skill and step in the process of design. From Pixate to Principal and InVision, it is so easy to build prototypes that once designers learn they typically excel and produce way too many. I am constantly reminding them to share just the alternatives that they think are best.
At PicsArt, we prototype animation effects, flows, and interactions:
At PicsArt, we prototype animation effects, flows, and interactions:
|
|
I encourage teams (PM, UX, eng) to spend time collaborating in front of whiteboards. Even if it is just UX at first, this part of the process is valuable for several reasons: 1) the product definition process frequently gets truncated in favor of moving directly to high fidelity mocks, 2) whiteboarding represents ideas visually and makes it easier to visualize flows, issues, and alternatives, 3)discussions pull in product and engineering team members to understand goals and constraints early in the process.
UX RESEARCH
I spent 8 years as a research scientist and received a Ph.D. from UC Berkeley in 2002. During this time I learned how to design, run, and analyze controlled experiments while building some of the first online communities, learning technology systems, and design environments. I lead the design for the technical architecture used to redesign the computer science curriculum to turn it into a project-based learning environment. I worked with Alice Agogino and Marcia Linn to figure out how to bring more women into the fields of engineering and computer science by highlighting the collaborative and project-based aspects of the work.
I was the design and research lead for some of the first NSF projects involving digital libraries and rich media where I set up partnerships with Macromedia and Hewlett-Packard. I designed and built technology using the very first tablet devices and streaming video services for peer interaction. This work involved extensive product design and testing with handheld technology for concept-based learning resulting in the publications of papers and presentations at conferences from AAAI to CHI and SXSW on topics ranging from search and design to science and technology. The majority of this work was focused on how people learn using technology and how they collaborate using online systems.
UX RESEARCH IN INDUSTRY
I lead the design and user research efforts at Postini (the #1 cloud based messaging and security platform) internationalizing their consumer product line leading up to the acquisition by Google in 2007.
At Google, I had the unique opportunity to lead both design and research for a variety of start-up style initiatives ranging from Google Compare (leadgen in the UK, Japan, US, and Germany) to Google Translate where I conducted user research studies in India and Brazil. Typically at larger companies like Google, you are either a designer, a researcher, or a manager.
At PicsArt, I set up the user research program, ran many of the early studies, and eventually hired a senior researcher from Google (Keren Soloman) to lead the program. Together we have ramped up usability testing, formative research, brand and marketing surveys and introduced the entire UX and PM teams to UX research as a way to 1) better understand new problems and projects, 2) improve candidates for AB tests, 3) increase quality of launches through usability test.
PUT THE FIRST & ALL ELSE WILL FOLLOW
At most companies, the leadership, product, and engineering teams think of UX research first as usability testing - something that happens just before or in most cases after the product gets launched. This situation requires the UX team to demonstrate the value of formative research as a way to speed up development by understanding user needs and the problem before beginning development.
Here is one example of what happens when user needs aren't understood:
Experiment: The new PM leadership at PicsArt hired an outside firm to build a direct-to-editor experience that eliminated the first step in the photo chooser problem all together by taking users to the editor immediately after sign-in. The data showed that the majority of users (80%) were going to the editor, so why not take them there for the first experience to reduce steps and thus reduce drop-off.
I spent 8 years as a research scientist and received a Ph.D. from UC Berkeley in 2002. During this time I learned how to design, run, and analyze controlled experiments while building some of the first online communities, learning technology systems, and design environments. I lead the design for the technical architecture used to redesign the computer science curriculum to turn it into a project-based learning environment. I worked with Alice Agogino and Marcia Linn to figure out how to bring more women into the fields of engineering and computer science by highlighting the collaborative and project-based aspects of the work.
I was the design and research lead for some of the first NSF projects involving digital libraries and rich media where I set up partnerships with Macromedia and Hewlett-Packard. I designed and built technology using the very first tablet devices and streaming video services for peer interaction. This work involved extensive product design and testing with handheld technology for concept-based learning resulting in the publications of papers and presentations at conferences from AAAI to CHI and SXSW on topics ranging from search and design to science and technology. The majority of this work was focused on how people learn using technology and how they collaborate using online systems.
UX RESEARCH IN INDUSTRY
I lead the design and user research efforts at Postini (the #1 cloud based messaging and security platform) internationalizing their consumer product line leading up to the acquisition by Google in 2007.
At Google, I had the unique opportunity to lead both design and research for a variety of start-up style initiatives ranging from Google Compare (leadgen in the UK, Japan, US, and Germany) to Google Translate where I conducted user research studies in India and Brazil. Typically at larger companies like Google, you are either a designer, a researcher, or a manager.
At PicsArt, I set up the user research program, ran many of the early studies, and eventually hired a senior researcher from Google (Keren Soloman) to lead the program. Together we have ramped up usability testing, formative research, brand and marketing surveys and introduced the entire UX and PM teams to UX research as a way to 1) better understand new problems and projects, 2) improve candidates for AB tests, 3) increase quality of launches through usability test.
PUT THE FIRST & ALL ELSE WILL FOLLOW
At most companies, the leadership, product, and engineering teams think of UX research first as usability testing - something that happens just before or in most cases after the product gets launched. This situation requires the UX team to demonstrate the value of formative research as a way to speed up development by understanding user needs and the problem before beginning development.
Here is one example of what happens when user needs aren't understood:
Experiment: The new PM leadership at PicsArt hired an outside firm to build a direct-to-editor experience that eliminated the first step in the photo chooser problem all together by taking users to the editor immediately after sign-in. The data showed that the majority of users (80%) were going to the editor, so why not take them there for the first experience to reduce steps and thus reduce drop-off.
Result: This experiment had the reverse effect: an even greater number of users exited out of the photo selection flow or exited when they got to the editor than previously when they landed on the Explore page
Analysis: This several month project had no impact since users exited the editor immediately not knowing what the app could do or how to do it.
UX Research: UX research had already established the primary user needs for the app which were: 1) What does the app do? 2) How did someone else create this amazing image, 3) How can I create something like that? Since those needs weren't addressed, the project had no impact on the primary KPIs.
I saw this same thing happen at Google when new PM leads would take over a project. It was typically driven by a desire to make a big impact quickly and it almost always happened without leveraging the existing design team or their knowledge. I learned to step aside and let people run tests quickly and fail. The result always highlighting the value of understanding users and their needs.
Analysis: This several month project had no impact since users exited the editor immediately not knowing what the app could do or how to do it.
UX Research: UX research had already established the primary user needs for the app which were: 1) What does the app do? 2) How did someone else create this amazing image, 3) How can I create something like that? Since those needs weren't addressed, the project had no impact on the primary KPIs.
I saw this same thing happen at Google when new PM leads would take over a project. It was typically driven by a desire to make a big impact quickly and it almost always happened without leveraging the existing design team or their knowledge. I learned to step aside and let people run tests quickly and fail. The result always highlighting the value of understanding users and their needs.
USER TESTING IN THE WILD
People really don't believe what users say until they see it. In person is better than videos. Every PM who comes to the SF office at PicsArt is taken out into the streets, food courts, and public spaces to observe people using their mobile phones and learn how to do field research. This is an eye opening experience and is the turning point when they return and say things like "OMG, people really don't want another social network" or "Wow, its really hard for new users to understand what the app does in the first 60 seconds."
The UX team does extensive product and QA testing. I've implemented form of product testing where we test out new features together as end users to simulate the experience for groups of friends. The most successful was the new Remix Chat initiative that lets friends collaboratively edit each others' photos, cutout sections, and remix them as part of a chat in PicsArt.
To simulate the experience, we took photos of ourselves, cut out our silhouettes, and headed out into the streets of San Francisco to take photos and add ourselves to each others' photos:
People really don't believe what users say until they see it. In person is better than videos. Every PM who comes to the SF office at PicsArt is taken out into the streets, food courts, and public spaces to observe people using their mobile phones and learn how to do field research. This is an eye opening experience and is the turning point when they return and say things like "OMG, people really don't want another social network" or "Wow, its really hard for new users to understand what the app does in the first 60 seconds."
The UX team does extensive product and QA testing. I've implemented form of product testing where we test out new features together as end users to simulate the experience for groups of friends. The most successful was the new Remix Chat initiative that lets friends collaboratively edit each others' photos, cutout sections, and remix them as part of a chat in PicsArt.
To simulate the experience, we took photos of ourselves, cut out our silhouettes, and headed out into the streets of San Francisco to take photos and add ourselves to each others' photos:
Optimize Silhouettes
|
Make Cutouts
|
Get Out Of The Building
|
The pain points become immediately apparent that weren't obvious in the mocks or prototypes: higher volume of images, things disappear off the screen, you can't find the shared items at critical touchpoints, images start trending and going viral within conversations, influencers emerge. This work result in major changes to the user experience prior to the public release.
INSIGHTS
The biggest insight was that while groups of friends editing each other's photos is not a familiar concept, this was incredibly fun and funny. What started as quick little edits typical of editing in the core app turned into crazy, silly, and experimental edits. When the other part of the team saw this, they added their own edits. We repeated this experience several times in different situations and it was the first time the entire team used PicsArt for the entire dinner vs. other apps. This spark meant there was some potential for this feature in the product.
Here are a few of the edits made during the field testing for the new Remix Chat functionality:
INSIGHTS
The biggest insight was that while groups of friends editing each other's photos is not a familiar concept, this was incredibly fun and funny. What started as quick little edits typical of editing in the core app turned into crazy, silly, and experimental edits. When the other part of the team saw this, they added their own edits. We repeated this experience several times in different situations and it was the first time the entire team used PicsArt for the entire dinner vs. other apps. This spark meant there was some potential for this feature in the product.
Here are a few of the edits made during the field testing for the new Remix Chat functionality:
|
|
|
Insights are the most valuable part of design sprints because insights are portable. That means they can frequently be applied not just to the area of the app or product being studied but more broadly. This is because insights typically reflect user needs. Apple calls their design sprints "insight sprints" to highlight their importance vs. getting designs or product solutions.
For example, we recently found that the highest interaction, intensity, and retention after editing photos came from seeing photos thematically similar to the one you just created. This insight has value across different business units from VIP, brands and challenges to localized content, AI algorithms for the feeds, and daily inspirations.
I've learned that if the senior management does not understand or value insights that you will have a difficult time showing them the value of design sprints. This frequently happens when organizations are data or feature driven (versus data informed). I frequently give PMs this classic red pill-blue pill choice (the blue pill makes you smaller):
For example, we recently found that the highest interaction, intensity, and retention after editing photos came from seeing photos thematically similar to the one you just created. This insight has value across different business units from VIP, brands and challenges to localized content, AI algorithms for the feeds, and daily inspirations.
I've learned that if the senior management does not understand or value insights that you will have a difficult time showing them the value of design sprints. This frequently happens when organizations are data or feature driven (versus data informed). I frequently give PMs this classic red pill-blue pill choice (the blue pill makes you smaller):
Then I remind them of the value of design sprints:
1. Better resource utilization
2. More alignment on vision and roadmap
3. Faster feedback cycles
4. More involved team members (eng, UX, PM)
5. Increased KPIs from tapping into user needs
Design sprints are best used at the start of projects where some exploration or understanding of the challenges facing the user is required or where market competition and entry requires innovation and differentiation. They do take up a substantial amount of time so the value needs to be commensurate.
ANALYTICS, RESEARCH DATA, & INTUITION
User research is data. It's critical to have high level discussions about this early on when setting up UX research. Stakeholders, PMs, and senior management need to understand that analytics can help you identify areas for improvement but it's user research that can answer why things are happening and how users think about the product, service, or experience.
The other question that comes up frequently is about the ability to make decisions based on talking with a small subset of users (5-12). A strong research lead will provide videos and data to back up findings and tap into the visual and emotional connection of seeing people struggling to understand or use the product or service (or be delighted). The best organizations will rely on a combination of analytics data, user research, and intuition or business sense. My perspective is that if you are paying for the best UX research talent, you need to trust them to give you valuable and actionable insights.
1. Better resource utilization
2. More alignment on vision and roadmap
3. Faster feedback cycles
4. More involved team members (eng, UX, PM)
5. Increased KPIs from tapping into user needs
Design sprints are best used at the start of projects where some exploration or understanding of the challenges facing the user is required or where market competition and entry requires innovation and differentiation. They do take up a substantial amount of time so the value needs to be commensurate.
ANALYTICS, RESEARCH DATA, & INTUITION
User research is data. It's critical to have high level discussions about this early on when setting up UX research. Stakeholders, PMs, and senior management need to understand that analytics can help you identify areas for improvement but it's user research that can answer why things are happening and how users think about the product, service, or experience.
The other question that comes up frequently is about the ability to make decisions based on talking with a small subset of users (5-12). A strong research lead will provide videos and data to back up findings and tap into the visual and emotional connection of seeing people struggling to understand or use the product or service (or be delighted). The best organizations will rely on a combination of analytics data, user research, and intuition or business sense. My perspective is that if you are paying for the best UX research talent, you need to trust them to give you valuable and actionable insights.
WORKING WITH PMS & CEOs WHO MAKE MOCKS
My first week on the job at PicsArt, the CEO came over to me and said "I just set up and ran some studies on usertesting.com and this is what I found..." No - not a dream. I learned after some time that this doesn't necessarily mean they understand UX research or the value of design. It does mean they understand the value of usability testing. And this is very different from user research.
The real challenge starts when PMs start creating designs as part of their project proposals. PMs want to launch the right product with the highest impact as quickly as possible. The problem is that creating mocks shortcuts the process of understanding the challenge users are facing and instead focuses on the visual details of the solution. This is actually worse than focusing on the functionality of the feature or product since in many cases it means they are thinking about the solution and not the challenges the user is facing. It's the opposite of putting the user first.
UX designers shouldn't go directly to high fidelity mocks either. I see this a lot in designers coming from agencies. When this happens, senior management needs to figure out how to help teams define projects and functionality in terms of goals, outcomes, user needs, even high level flows since these tap into the user's journey.
The product VP at PicsArt doesn't allow mocks in the product proposals. This hasn't completely solved the problem since PMs put in wireframes. The junior PMs still create mocks - they just give them directly to their designers. In an ideal world, these concepts would be part of the brainstorming process. In the worst case scenario, PMs begin treating the UX team as a service organization. This has wide-ranging detrimental impact and means the company is not getting the full value of their investment in UX. As the team lead, when I see this happening I know it's time for the UX team to showcase more effectively the value of design versus trying to get PMs to change what they are doing.
Overall, having PMs and CEOs who make mocks is a positive sign. The role of UX is to ask why they think this solution will work in an effort to define the problem, user needs, and pros and cons. This tactic shifts the discussion towards user-centered design.
My first week on the job at PicsArt, the CEO came over to me and said "I just set up and ran some studies on usertesting.com and this is what I found..." No - not a dream. I learned after some time that this doesn't necessarily mean they understand UX research or the value of design. It does mean they understand the value of usability testing. And this is very different from user research.
The real challenge starts when PMs start creating designs as part of their project proposals. PMs want to launch the right product with the highest impact as quickly as possible. The problem is that creating mocks shortcuts the process of understanding the challenge users are facing and instead focuses on the visual details of the solution. This is actually worse than focusing on the functionality of the feature or product since in many cases it means they are thinking about the solution and not the challenges the user is facing. It's the opposite of putting the user first.
UX designers shouldn't go directly to high fidelity mocks either. I see this a lot in designers coming from agencies. When this happens, senior management needs to figure out how to help teams define projects and functionality in terms of goals, outcomes, user needs, even high level flows since these tap into the user's journey.
The product VP at PicsArt doesn't allow mocks in the product proposals. This hasn't completely solved the problem since PMs put in wireframes. The junior PMs still create mocks - they just give them directly to their designers. In an ideal world, these concepts would be part of the brainstorming process. In the worst case scenario, PMs begin treating the UX team as a service organization. This has wide-ranging detrimental impact and means the company is not getting the full value of their investment in UX. As the team lead, when I see this happening I know it's time for the UX team to showcase more effectively the value of design versus trying to get PMs to change what they are doing.
Overall, having PMs and CEOs who make mocks is a positive sign. The role of UX is to ask why they think this solution will work in an effort to define the problem, user needs, and pros and cons. This tactic shifts the discussion towards user-centered design.
AB TESTS
Typically PMs define and run AB tests. The problem is that most PMs (and UX designers) do not have a background in experimental design, statistics, or analysis. As team leads (PM, UX, Research), this leaves us a couple of choices:
The highest value to effort ration has been from #2: Let people run whatever experiments they want and then work with them to analyze results. Start-ups and even larger companies need to be agile, test and learn quickly. Speed is a top priority.
Typically PMs define and run AB tests. The problem is that most PMs (and UX designers) do not have a background in experimental design, statistics, or analysis. As team leads (PM, UX, Research), this leaves us a couple of choices:
- Train PMs and UX in experimental design and analysis (very time consuming).
- Let them run experiments and then work with them to analyze results (impacts users and resources).
- Try to reduce decisions made that aren't supported by data (potentially dangerous).
The highest value to effort ration has been from #2: Let people run whatever experiments they want and then work with them to analyze results. Start-ups and even larger companies need to be agile, test and learn quickly. Speed is a top priority.