LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestras Condiciones de uso y nuestra Política de privacidad para más información.
LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestra Política de privacidad y nuestras Condiciones de uso para más información.
Hi my name is Dawn Ressel. I’m an Experience Design Leader at intuit. Intuit makes financial software for doing your taxes, accounting, and personal finance. You may have heard of some of our products: TurboTax, QuickBooks and Mint. Today I’m going to be talking about what I call Full Stack User Experiences: A Marriage of Design & Technology.
First I want to talk about design systems in general. The UX field started out with pattern libraries, which is documentation that you try to enforce. That’s not a design system; I actually consider this a precursor to a design system. Take our case at Intuit, we’ve got 4,000 engineers. With a pattern library, that would mean all 4,000 engineers have to interpret that documentation, and they can be interpreting it differently, and they’re building it separately.
I believe a design system has to be something that actually goes directly into the product; something that you don’t have to rely on people to enforce. I think it’s important for a sustainable design system to be codified because then it can evolve over time as it naturally will and should, and those changes can be represented in product in real time. And it should be centralized and able to be leveraged once and reused in many places. In short, a design system has a single source of truth, in code. One of the intents of a design system is cohesion, and the only way you can truly accomplish that is by having a single source of truth.
UI Component libraries are definitely a type of design system because you’re not relying on individual people to enforce it, and you can a single source of truth that goes directly into the product.
Today, I will talk about the natural evolution from component libraries to something newer that we call widgets. The way we define a Widgets is: It encapsulates a user task with associated user interface AND back end service functionality. It is functional on its own and can integrate in any application independent of the other elements and technologies in the application. These widgets are built once and reused in many places, various applications and different contexts where that same set of features makes sense. By building widgets, we at Intuit have been able to propagate best practices throughout the company in terms of interaction design and technology.
This is an industry example of a widget that you are probably very familiar with: the Google maps widget. It can be plugged into a variety of applications and provide map functionality in the context of booking a hotel, finding a restaurant, checking weather, buying real estate and more.
Today I’m going to talk about how we at Intuit have evolved from the source of truth being simply front-end code to full stack code via widgets. And I’ll share how we use widgets, the value they’ve created for our company, and what we’ve learned along the way.
Intuit is not the first to create widgets. In fact they have been around in the industry for a while, and here are some notable examples. However, I do think the way Intuit is thinking about Widgets as the next evolution of a design system is novel. That’s what I’m going to focus on today.
So now I want to take you on Intuit’s journey towards widgets and how we got here.
Our company mission has stayed the same over the past 30 years. To improve our customers’ financial lives so profoundly they can’t imagine going back to the old way. But how we’ve accomplished that mission has changed with the times. Historically Intuit had individual products which were siloed, some built in house, some were acquired. They had separate code bases, different product and design teams, and different cultures. And our roots were as a desktop software company that shipped CD ROMS.
Then the technology industry about 10 years ago started shifting towards the cloud. And this started to disrupt Intuit’s business. Intuit found itself competing with startups that were born in the cloud and can be more nimble. Intuit realized in order to stay competitive, we have to move to the cloud too.
What we realized in the process of moving to the cloud is that it created new opportunities for us that we weren’t able to take advantage of before because technology was limiting us. So we stopped thinking about our products as an individual set of offerings that ship on CD-ROMS. But instead the potential of our products to be connected in an ecosystem, and share data, and create additive customer experiences that are more powerful when you use more of our products. We realized that we have a competitive advantage. We have something the startups don’t have: we have lots of data that could become connected; and we have a collection of independent products that could work together to create more value for our customers and create new business opportunities.
One of the first steps for us to becoming an ecosystem company was the creation of a project called One Intuit Identity (OII). In order for our products to work together, we needed to know who our customers were (for example, that the same person logging into TurboTax and Mint was in fact the same person); and we needed to be able to share that person’s data across products.
The One Intuit Identity project is run out of the organization I’m in, which is the Central Technology group. Rather than living within a specific product team like TurboTax, our charter is to work across the company to solve problems that are common, problems that can be solved once really well and the rest of the company can take advantage of that.
With One Intuit Identity, we started with back end APIs only. However, many teams were building the same user interface and solving the same customer problems over and over again. These interfaces were of uneven quality, and the teams were not sharing learnings with each other, and the teams building it were not experts in this area of identity. We realized we needed to unify the experience with best practices and also create a familiar customer experience across products, and that in doing so we could also gain efficiency for the company.
We tested the concept of a single identity in an Intuit ecosystem with customers who could potentially benefit from it: such as a Mint customer who might be able to import financial information into TurboTax to make their tax preparation simpler. Would our customers find value in this? The back end services team for One Intuit Identity was not convinced, and they knew it would be difficult to accomplish. So we tested it.
By talking to users, we learned that they not only saw value in a single identity, but they immediately took the leap to product connectivity before we even proposed it. Simply by suggesting a single identity, they assumed our products would work together. Which validated our design hypothesis: customers saw value in a connected ecosystem. And the best way we knew how to accomplish this was through widgets.
We were then able to share what we learned from our customers with the back end services team and they re-architected the back end services to support a better user experience that allowed for more obvious Intuit product connectivity. For example, we could allow you to use your existing Intuit account when starting to use an additional Intuit product so it felt more like we to show we “knew” you as you’re moving across our products.
Now I’m going to share some success stories about our One Intuit Identity widgets. We were working with our Accounting products division and TurboTax to refine our account recovery widget; the experience a customer goes through when they forget their user ID or password. By having analytics in the widget, we were able to experiment with UI changes and understand the impact of those changes. Over the course of a year, working with these two product teams, we were able to improve the account recovery success rate by 10% from where we started.
The next team we approached to use our account recovery widgets was the QuickBooks team. They initially resisted getting it into the product because of differences in our design patterns vs. their standards. They were concerned that they had already established some patterns that their customers has already learned to use, and so by introducing these new widgets they were concerned they might see a drop in account recovery success.
We explained why our patterns were more appropriate in this particular scenario, but our design rationale alone did not get us full buy in. However, the team did agree to run an A/B test of the widget against their current design in order to make their decision.
What we learned was that overnight, the QuickBooks team received a 13% increase in account recovery success rate simply by adopting our widget. And then we rolled it fully into production and they were able to achieve a 52% reduction in support calls related to account recovery, as well as a $560k cost reduction in 1 year. This also improved the customer experience because they were now able to self serve rather than having to call us to recover their user ID and password.
So far, our widgets were doing really well. Then something happened…
In early 2015, the United States tax system was under attack. There was a nation-wide problem that impacted the IRS, the states, TurboTax, and any of our competitors. There had recently been several wide-scale and highly publicized hacker attacks on Target, Sony, and Home Depot to name a few. Now these malicious people were using the sensitive personal information they gained from those hackings to file fraudulent tax returns via TurboTax and other tax prep software.
The quote I’m showing is from Forbes, and there were many similar stories that surfaced in the media almost overnight. Intuit had to act fast to protect our customers and salvage our reputation. Fortunately, the One Intuit Identity team had already decided to build in additional functionality to secure our customers’ data if needed, features that we hadn’t yet exposed. And that was because this team had deep subject matter expertise in the areas of Identity and Security; this is what they think about all day, every day on behalf of all of Intuit. So this team was proactive in imagining what might happen in a scenario like this, even though we hadn’t yet rolled out the functionality.
Crisis: However, before tax season, the TurboTax team made the decision not to adopt these additional security features that we had built because they were worried about the impact to the customer experience and conversion. They didn’t want it to become a barrier to entry.
However, after the fraud attacks started happening it was very evident that these additional security features were needed. And because of the One Intuit Identity teams’ expertise and foresight in building those features, and the fact that TurboTax was already using our widgets, we were able to roll out additional security measures to TurboTax products within 1 week, dramatically reducing the amount of fraudulent tax returns that went through our products. And all of the Intuit products that were also using our widgets automatically inherited these additional features with no effort, protecting all of Intuit’s customers.
Resolution: As of now, 100% of Intuit products (~150) are using our One Intuit Identity widgets, and about 4,000 developers are benefitting from not having to do this work themselves. Our widget approach has now expanded to more projects (~10?), and even our business units, who initially were reluctant to adopt the widget approach are creating their own widgets for reuse across Intuit.
Here’s another example of how we’re using widgets across the Intuit ecosystem: our Financial Data Experience project. All of our products are related to financial management. And there’s overlap in some of the tasks that you need to do in our products. For instance, you may need to import documents, whether it’s a W2 or 1099 for your taxes, or a receipt for your accounting, you need to get data into our products. And you can either do that by connecting directly to your bank, uploading a document you’ve scanned, or taking a picture on your mobile phone. Those tasks are agnostic of the jobs you’re doing – meaning, the experience can and should be the same whether you’re working on your budget or your taxes. In fact, customers expect a familiar experience when they’re using our products.
Recently, a team developed an entirely new offering, called Intuit Link, from start to launch in six weeks. This was possible because they were able to leverage the Financial Data and One Intuit Identity widgets to assemble much of their customer experience.
In summary, here are some of the benefits we’ve seen at Intuit in using widgets…. Propagate best practices for user experience and technology Create a familiar experience for users Increase productivity and free up teams to work on new innovations Increase speed to market Learn at scale, across the company Reduce risk and increase compliance in critical areas like security Leverage subject matter experts to create and maintain for all
So now that you understand what a widget is, and how they’ve been used at Intuit, I’m going to talk more about the technical details and how to be successful in designing widgets.
REUSABILITY: The fundamental question is can it be reused? We’ve had examples where we said, you know what, the needs of an accountant in this task are too divergent from the needs of a taxpayer. Instead of creating a widget, let’s share learnings and best practices or align on the component level rather than the widget level.
DEMAND: 1.5 times more investment to build something in a way that’s reusable. For our organization, our goal is to get a minimum of 3 adoptions of everything we create so we are sure we’re spending the company’s time and resources wisely.
ROI: Example of managing bank connections – we have a better more reliable technology way to connect with some of our major banking partners, so we’re upgrading our back end technology, which will in turn improve the customer experience. If a team adopts our widget, they get that upgrade automatically. If they don’t use our widget, will have to integrate the new functionality on their own.
SPECIFICITY: If it needs to be broken up, then it can be multiple widgets. For example, we’ve made our document upload widget separate from our document import widget, because sometimes the import feature isn’t available for a document type.
Our widgets are more than just a user interface. We combine back end services and analytics behind the scenes to create powerful functionality that drives these best in class user experiences that we call widgets. So it’s really about the front end code and the back end code being encapsulated into a single package that can be reused across products and in different contexts.
This is an example from One Intuit Identity, our Account Recovery Widget, which includes dozens of flows, screens and calls to rich services and helps orchestrate complex flows across the product experience. This is functionality that has been designed and built once and used across Intuit products, with only a few minutes for any engineer to integrate it into their product.
One point I’d like to make is that our widgets are not a replacement for UI component libraries. In fact, they build on top of and consume components. For instance, at Intuit, our flagship products have different style guides, and therefore different component libraries. In order to make our widgets work across all of these products, and even for 3rd party developers using our functionality in their own products, widgets need to be able to reference these various styles. Those styles live in our component libraries and the widgets consume those styles.
To be successful, you need close partnerships with technologists up front. You need a cross-disciplinary team. Being able to tie your work to the business strategy and talk about why design systems are important in the context of business, not only in the context of design, because there is a case to be made about why it’s important to the business. So I think being able to articulate that is really important. It’s not enough to just get designers to buy into a design system. You have to get the business leaders, the technology leaders involved in order to make this truly successful.
Paint the picture of the experience you’re trying to create and how the technology enables that experience. Get them excited about the vision. Frame it around the user - solving this problem for the user rather than this is my design solution. Tie end user benefit to the back end work - what back end logic can we invent, leverage, or reuse so the customer doesn’t have to do this? Obvious example: we remember you Don’t start with the how - they get defensive and think you’re going into their territory - that’s why it’s important to start with the vision and the big picture and they can help figure out the solution Get engineers understand what the customers are experiencing. For example, we have a back end services team that works on categorizing transactions that are imported from the users bank account. We had them go through an exercise where they used QuickBooks as if they were a small business owner and needed to categorize their transactions. By going through this exercise, they understood how important it was that we put transactions into the correct categories by default and how much work it is to correct something when it’s wrong, which lead to increased focus on data quality by that team. Engineers are creative when you give them a challenge - tell them it’s probably too hard - then they like it - challenge them and give them the vision - e.g. if it doesn’t work as good as Google, it’s going to feel broken. How can we feel more like that? Listening to engineers to understand what they can offer - also listening for design ideas from the developers, involve them in that conversation to get to a shared solution where they can take ownership Have empathy for the back end developers - some of the things they’ve said is because of frustrations they’ve had in the past - let them vent - they’re could be helpful information in there but it also helps to create trust. Probe with them on what’s important to them - what are they motivated by? Some are motivated by a real customer problem, some are motivated by solving a complex problem, some are motivated by working with a new technology. Find out which is their motivation and match it. Build credibility by being Accurate, detailed and specific - checklist for emails. Has to be correct (even spelling), detailed (include all cases), specific (make sure everyone knows exactly how it’s supposed to work and why). Ex: animations we added reduced the percentage of people who resent text messages by 20%
One of the challenges I initially found with doing this type of work to create full-stack UI widgets is finding the right match between designer and project. It really does require a slightly different motivation. One of the things I uncovered through this journey is that the type of designer that’s needed for design systems can be different in skill and motivation than a traditional product designer who’s really just thinking about their one product or their one customer. The thing that I look for when I’m interviewing is an interest and an aptitude in being able to think broadly – true systems thinkers – people who can think across product boundaries and even customer boundaries – we call it “ecosystem thinking” at Intuit. And people who really like to get into the details of one specific domain and become a true expert in that because that is the type of thing we do with Widgets – we’re encapsulating this rich functionality in a specific domain area and so I’ve got to make sure that I find a designer who’s engaged in going deeper and deeper into this subject matter (e.g. Security) as opposed to getting bored. So you want that rare blend of being able to think end-to-end and also get really into the details. And I also look for people who can do socialization of their designs, communicate a solid design rationale, and be really good at collaboration and influencing across the organizational and role boundaries. When working on design systems, it’s super important to be influential as a designer.
I’d love to be able to say at Intuit we sit around and sing kumbaya and hold hands and create widgets all day long with no friction. But that’s not quite the reality. This is hard work. When you have different teams, with different products, and different users, getting alignment on design can be slow. And a lot of the questions these teams raise can be quite legitimate, such as, are the expectations for this task the same with an accountant as it would be for a tax payer? There’s usually no universal answer. We have to take it on a case by case basis, do research, iterate, and learn over time. But in general, here are some of the things we’ve found work well.
Start with a single team first, one who has a need and go deep with them, while looking broadly across at potential overlap/conflicts with other product areas Prove out and learn with that first team to refine the experience Embed within the teams that are adopting. In the best case scenario, they think of our designer as THEIR designer. Do research together. You never want it to be my research vs. your research. Make it OUR research. Research is the perfect opportunity to get alignment and build a spirit of learning and collaboration. Instrument everything – data helps to prove your case and helps you improve Iterate over time – with every new team that adopts the widget you learn something new that can improve the experience for everyone If there are doubts, A/B test your way into it to make sure it will work in a new context Explain the What’s in It for ME? If I adopt this widget, what benefits do I get? Do I get something by being a part of this larger ecosystem such as data or product connectivity? Freed up resources? Paint the long term vision. What our widget offers today may be just the beginning. Talk about what they will get in the future. Get executive backing/escalate if needed, but only as a last resort
Widgets (going full stack) is the next evolution of the design system Widgets have massive benefits when built for the right reasons Designing widgets is about thinking both broad and deep Research, instrumentation and collaboration are your friends
Full-Stack User Experiences: A Marriage of Design & Technology (Dawn Ressel at Enterprise UX 2016)
Dawn Ressel, Experience Design Leader, Intuit
Enterprise UX Conference
June 9, 2016
A Marriage of Design
Intuit Confidential and Proprietary 2
Codifies full stack code
Codifies front end code
Documentation of design
Evolution of design systems
Intuit Confidential and Proprietary 3
What is a widget?
Example: Google Maps
- Core to businesses
- Familiar experience
- Best practices baked in
productivity & decrease
time to market
Intuit Confidential and Proprietary 13
More widgets across the Intuit ecosystem
Financial Data Experience
Intuit Confidential and Proprietary 14
• Best practices
• Familiar experience
• Speed to market
• Learn at scale
• Reduce risk
• Subject matter experts
Designing full stack has many advantages
Benefits of widgets
KEY TAKEAWAY: Widgets are a great investment
and create a better customer experience.
Intuit Confidential and Proprietary 16
SHOULD WE BUILD A
When a widget makes sense
Before creating a widget, make sure it will be worth the investment
Intuit Confidential and Proprietary 17
Widgets are more than just a pretty face
Widgets leverage powerful services behind-the-scenes
Email collision detector
… and provide orchestration
Intuit Confidential and Proprietary 18
1 widget Minutes to adopt
One Intuit Identity
One widget orchestrates complex interactions
Intuit Confidential and Proprietary 19
Widgets and component libraries are shared
Widgets require lots of
Intuit Confidential and Proprietary 21
Tips for working with engineers
• Paint a vision to get them excited
• Explain how their work impacts users
• Get them to feel the customer pain
• Start with the problem, not the
• Give them a tough challenge
• Listen to them & have empathy
• Be specific and accurate
Designing widgets requires partnership with back end engineers & architects
Working successfully with engineers
KEY TAKEAWAY: Engineers can be
a great ally for you as a designer if
you build strong relationships.