Design Thinking with Wipro’s Nate Clinton and Pivotal’s Tim McCoy

Episode 134 · 52:09 · SRT · archive.org · all Tanzu Talk

my name is Nate Clinton I'm executive director of design at North America design that's part of Wipro digital and Wipro globally and what we do is we do strategic design for clients around the world my role is really focused on North America and you know building teams here in our primary studios in San Francisco and Brooklyn New York as well as other places around the United States and Canada and you know working with them to understand their needs and really create design you know design solutions whether it's a digital design or service design or you know the launch of new ventures or really the future of their business all of those kinds of questions great and Tim why don't you introduce yourself I'm Tim McCoy I'm senior director of user experience at Pivotal I've been with Pivotal for about eight years now I started on the consulting side Pivotal Labs and for the last several years I've been in our R&D organization working with Pivotal Cloud Foundry Pivotal Green Plum and now my main focus is with Pivotal Gemfire and Pivotal Cloud Cash kind of our big question today is to is to talk a little bit about the state of modern design as it relates to software development I'd also love to get into a bit of the past and the evolution of design and and how that has evolved as software development has evolved around agile agile methodologies lean those kinds of things I imagine it's changed pretty dramatically over the years and you guys have a bit of a quite a bit of experience in this space so maybe we can start talking a little bit about how you guys kind of your past at Cooper tell us a little bit about that and then maybe we can get into some of the things you're doing now so I joined Cooper in 2004 maybe and worked there for a number of years really at a point in the

maturity of the design practice in software where it was a lot of waterfall work a lot of upfront front loaded research heavy then working to develop a design that you thought was going to be a really great solution outcome for your your customer for your users and then once you had that and you had it nice and documented up you then engage more directly with engineering organization to see that that thing built right and in my evolution in design I think goes along with how a lot of the industry is going around the 2010 timeframe when we saw that designers just weren't seeing outcomes they wanted from the work we were doing right like we designed great things only to see them a shadow of themselves of their former selves when they actually made it to someone's screen and so I got involved in the agile community and understanding how we could get the work that we were doing is user experience and interaction designers to mesh better and that has that's a two-way street mesh better with the actual craft of building and shipping software and that's what led me to pivotal great and Nate maybe you could similarly share kind of your journey to how you got here today yeah yeah it's interesting I I guess I could say I I sort of took the baton so to speak from Tim I joined Cooper in 2012 just after Tim had left and you know Tim was out kind of breaking ground in terms of how does design work with software development more more closely to achieve those outcomes and Cooper was facing I think you know in the years following Tim's departure you know facing the same kind of uh challenges in terms of what how do we get the world to uh you know to build the things that we want and you know by remaining independent as a small

consultancy Cooper you know had some limitations I think you know we didn't have a big uh engineering team that we could direct um in the same way that pivotal has kind of put those two ingredients together and um and it led to um I think just eventually I was saying look we have to find the right um sort of place to live where we can achieve real outcomes and so um you know in 2017 I guess it was uh so almost two years ago um you know we we made the decision to to to fold Cooper into a larger organization that had some of those some of those capabilities where we could you know actually achieve the impact at scale that we had all dreamed about for you know for decades um you know a lot of in-house teams have been built you know at the at the big tech companies I mean even the small ones that that that uh you know that have sort of maybe beat the consultancies to that to that reality and um so joining a bigger company I made a lot of sense so that's really the evolution actually is that these small independent design only shops it turns out that's not enough it can't be uh just design it has to be designed plus other things and so I think one one pathway was Tim's toward you know the pivotal model and um and and then Cooper kind of evolved maybe in the same fashion a little bit later so we kind of realized and learned that lesson uh in the same in the same way right and so that larger organization being Wipro um and so now you feel like you've got an opportunity to affect outcomes in a way that maybe it's an independent company a smaller consultancy you weren't able to do uh so that makes perfect sense so so I want to get into uh I mean I want to definitely want to dive into some of the the important um not just challenges but it's just important parts of the discipline of design but I'm going to show my night uh night I'm going to show the fact that I don't know a ton about this topic by asking the following question is for our audience could you kind of just help us understand the role of designers on you know balanced teams so we hear a

lot about well balanced team is made up of software developers um project product managers uh designers help us help us understand the role specifically that designers play uh in that process on that team yeah I'll start I'll talk a little bit about uh how we typically see teams work at pivotal is uh you know designers play a a pretty bridge role right between uh end users the product strategy and implementation so as designers we end up leading a lot of user research and doing a lot of uh synthesis and understanding of like all the inputs and really facilitating conversations with that balance team on you know what are the things we're hearing what does that mean uh as far as how we ought to interpret what we're hearing in terms of how to shape the product to react to that and then how do we uh when we're actually at the point of implementation right we also have that friction of okay well this thing that we thought was going to be the right way whether it's because we're getting feedback from uh early iterations of the application that things should change or because we run into some technical technical constraints where we need to see something change in the design itself uh and designers really play that play that bridge between those roles i think is a good way to think about it yeah i like the way you're talking about um design and facilitation because you know design is almost certainly about it's also about crafts for sure like creating things but so much of the designer's job in this context of you know product technology design is is facilitating the conversation but not just being a good you know person to stand up in front of a room and kind of get everyone excited

because i think there's a lot of design theater that happens in that in that realm um which maybe isn't so productive uh but in fact actually arming everybody with the right tools to make good decisions so one way i like to think about design is you know product managers uh definitely have this sense of of accountability and ownership and i think rightly so in terms of ultimately the business has to achieve something right and that's their their kind of uh their their purview and their mandate um but but as a design team as a designer inside of a team you know we want to help both developers and product managers have the right information the right tools to make to make good decisions and sometimes that means you know being relatively prescriptive and saying here's a here's a solution this is the right solution based on x y and z and sometimes that means you know we're hearing lots of things from the market you know maybe we're hearing it from product management maybe we're hearing it from development uh you know through user feedback and we we synthesize that and say here's what this means here's how we interpret that so just as tim was saying you know kind of part of it is interpreting and helping to translate um it's not just facilitating a meeting or facilitating ideation it's really about helping everybody have good decision making tools yeah you know if you think about in it's in an abstract level design is really about taking in a whole bunch of inputs understanding like reading a situation reading context and then distilling that down into something that is consumable right and and on one level designers do that with the user needs and the product but the thing that this this facilitation is really doing that at the level of of the team and organizationally playing that same role right of like there's all these inputs there's all these

factors going into things and and the designer's toolkit includes tools and techniques and approaches and frames of mind to help distill that and make sense of it and simplify it in a way that the the whole team can understand and get behind and move forward interesting so i mean in my ignorance i think design okay i think of you guys are making some of the decisions around what am i going to see on the screen when i'm using an application on my phone but it's a lot more than just design uh it's just it's a lot more than just what i see on my screen at least what goes into it it sounds like so it almost sounds like you have to play the role of well maybe therapist isn't the right word but i was gonna say group therapy um but but tell me it sounds like it could be a really chaotic process because you've got as you mentioned all the different inputs you're getting um you're talking to users you're talking to the business side you're talking to the developers i imagine developers say things like well that's a great idea but we can't technically make that work or whatever so talk about you know so what are some of those tools what are some of those techniques you use to get the conversation going uh to facilitate the conversation and then probably the hardest part taking everything you've learned and distilling that down into a design yeah i mean synthesis i like to talk about um this is this process of synthesizing taking lots of information and distilling it down into something consumable uh the way tim was describing that i think and the tools vary quite a bit across this discipline um it kind of depends on the on the situation but but for sure i think at its core it's about um you know uh restating things in a way that's sort of understandable so a lot of times you'll hear you know the voice of the user there's lots of uh phrase phrases used in the industry about hearing from the customer looks and it's really tempting to act on that in a kind of reactive or defensive way let's fix whatever it is someone someone claims is

wrong and it's it's uh so one of the kind of i guess fundamental tools of design is simply asking you know what's what's motivating this this feedback to begin with rather than reacting to the feedback on its face um so a classic example of this is um uh you know i i used to work for a product company back in the day um and we were building tools tools for institutional financial managers and uh we'd hear a lot of them asking us to uh to put a button on the screen that said download to excel and of course this was actually a pretty easy thing for us to do we could just put the button there and say download to excel and uh and it would be great and they would all be happy presumably um but our ceo was was was pretty clever and he said let's not ever do that let's not ever put the button on the screen that lets them download to excel instead let's use that as a way of asking them what are they going to do with that in excel and then we learn something more fundamental about what they what their goals are and what they're trying to achieve so if we can help i think one of the biggest the most important tools that we have as designers is to restate things to restate desires and motivations as as goals coming from users as as more fundamental goals than simply uh some kind of task like download to excel which is uh you know you know a perfectly legitimate sort of feature request let's call it um but it masks a whole bunch of interesting and useful knowledge that we can gain and so helping to ask those kinds of why questions i think is one uh really important tool for synthesis because it takes a lot of you know feedback that might be coming from a big group of a cloud of users out there and helps to find you know what are the insightful kind of driving factors underneath it all um so things like that where we and it doesn't have to be black magic or dark art or anything it's very a lot of it's very simple you know let's let's cluster ideas into related categories and let's let's try to sort of boil things up a little bit so that we can

start to think at a high level about um you know what really matters here and try to to move the pieces around and prioritize ultimately we have to decide you know not just not just how does something work but what should we build in the first place and that's you know that's that's kind of uh you know that's the more expensive question let's say um where if you get that one wrong um you know you've you've wasted a lot of time and effort so uh so i that's that's my perspective on kind of synthesis i always say it's the hard part you know going out and doing the research asking questions is is relatively easy you can you can train people to have a good conversation but making sense of it all is actually pretty difficult so helping the team do that well is really a really key part of our job i think yeah i i back that up a thousand percent um i think another synthesis tool uh that we go back to again and again is visualizations right and when i say that i don't necessarily mean something beautiful graphically right that most of the time i don't mean that at all what i mean is is actually getting down physically somewhere whether it's on a you know real whiteboard or virtual whiteboard or document of some sort whatever it is some um map some visualization of whatever the issue is we're talking about if it's a system it's like how things how how workflow actually flows through people for a past or how um a set of features relate to one another in in the in the overall flow of your application things like that right and what a tool that designers can often you will often use is to create this artifact this visualization of a system of a concept that um on its own is very clarifying when you're coming

up with it but its real power is in making everyone else who's got this loosely formed mental model themselves of what that system might be to all look at the same version of it and be able to say yes that's what i think it is too or oh i didn't realize you did that or no there's no way that's actually how it works because my model says this right and so it's getting everyone to have the same conversation around the same thing it's like a real synthesis superpower that's yeah that's great so the idea that you've you've got to get something on paper metaphorically before you in order you've got to ground it in some kind of reality uh otherwise you could just be having this really wide-ranging conversation with everybody having you know ideas and they all may all be great but um how do you center that conversation around something real so that makes a lot of sense yeah i mean a lot of design artifacts are exactly that they're all just sort of variations on the theme right it's whether it's a persona or a journey map or whatever it is blueprint or something these are all simply what you're describing which is taking all that data or information or ideas and encapsulating somehow and and not as a finished thing but as a as a tool to elicit reaction or to elicit conversation at least we're all talking about the same thing that's a really great way of putting it right and of course you know this i'm sure this this process happens when you're developing you know a brand new uh application or piece or piece of software but of course iteration is is a big part of software develop modern software development so how do you approach this on an ongoing basis how do you have these conversations in a way that that in other words you probably don't have the time to have these big grand conversations all the time you've kind of got you've got to iterate quickly over time how do you actually practically listen to into effect i guess is my question well i i think i i'd love to hear tim's take on this uh you know on sort of on the ground so to speak at pivotal but i think you know from from my perspective at least um

uh you know it's a mistake to think that uh these kinds of visualizations are all are all grand right and i think a lot of people maybe think about maybe one misconception about design is that that it always has to be so grand right it always has to be back to first principles and we have to like you know build everything from scratch you know all the way um but as you're pointing out i think it's important to to remember that you know things are iterative and software exists and we have to make it better sometimes we can't just throw it all away every time so you know one of the things we use a lot for this kind of iterative uh conversation is um just simple stories and narratives so you know if you if you know if if you can tell a story about somebody you know you can use a persona or you can use some other kind of tool like that but but if you can if you can tell a convincing story about somebody uh succeeding or using a system in some particular way and then tell another story about them using it in a different way you can iterate without having to worry too much about screens and buttons and have a good conversation about what what's the experience we want them to have we want them to have this really great experience that does acts differently and we're going to talk about it as a story and doing that is a very cheap way of um of keeping the conversation grounded on you know actual things so you get away from conversations like well they might want to do this so they might want to do that that's a lot of they might want to is a is a i think a red flag as the start of a sentence right uh we want to tell actual stories and narratives and then we can throw them away because they're cheap right we can change the words um without having to redraw lots of screens so i think one important synthesis tool um for iterative product design and product development is is narrative it's not necessarily even using screen designs it's actually just sort of uh storytelling um and that can take lots of forms of course you could you know you could sketch things or you could you could you could just

simply use a written sort of step-by-step kind of narrative or uh you know even kind of a storyboard or something like that yeah absolutely um i think we also we take it in a a little different lens or actually maybe it's coming back to something you said around it not being jeff you said about but it not being grand and just being like a normal everyday thing to do things like this um you know i see it pivotal all the time and not just designers at all by any means you know an engineering pair going up to a whiteboard and sketching a data schema or sketching the uh the flow through uh you know a set of classes in their in their code um or a product manager talking about um the particular like feature set and where what's going to flow and what release and why things go together right just like giving giving uh giving form to things that are in your head right and i think and i think that as designers at pivotal we play a big role in kind of championing that concept and that process um and and yeah it's by no means just the designer thing um but i think that there's a lot there's a lot to that just that aspect of getting things out or and having it uh there to the to have a common conversation around um and then in terms of the you know i think there is there are times you're right you can't always have the time uh or is nor nor is it always the right time to go big and create this grand uh framework for everything right and when you pick up you know when you're out there actually shipping software every day you know there's times when you will pick up something that uh

has never had that done for it initially right so you're like well let's try to do some of this to make sense of what we think is here right and so that's one way you do it or or we'll do things like we have a couple of uh very high level models of interaction and relationship that we use inside people r&d to help ground the way that we approach uh the user experience for our various interfaces and products and products and you know that goes there's an effort that was probably a year ago that got us the the foundation we use today and over the course of the next over the last year and the next year probably um we learned things from being actively developing and working with customers that oh that that thing that we assumed in our model is a little bit different or oh and this new thing that didn't wasn't really a factor when we started this model now is coming to play and so you know the model kind of ages and gets lots of virtual stickies put on it as you as it evolves and then at some point it comes time to say hey let's reef let's you know let's essentially refactor our uh our baseline view of the world and let's undertake another larger effort to kind of reset uh or recalibrate you know what our baseline is and so yeah you're always dealing with with kind of levels of decay and those things uh but what's nice and this i think comes back to the idea of stories if you're telling stories around those things um that you can manage that decay because your stories can can um evolve away from some of the early things you've done and that's okay because you know you told that story nine months ago and you you shift that and you learn for it now you're telling a new story right i like that yeah i like that concept of stories that i think that makes makes a lot of sense intuitively uh and people

i see that as a great way to for people to kind of rock a new idea when you're counting it in the language of a story versus uh more technical terms so i you know a lot of our listeners are developers i'd love to hear about you know what are some of the biggest how about this what are some of the biggest misconceptions developers have about designers and working with designers um and what are some of the challenges you've faced working with developers and how do you how do you navigate some of those i think developers are they're very creative people and they're very uh you know curious and they're very um they have a deep uh desire to know that the work they're doing means something right and so they you know i i think they often um i think i think we're we're very much cousins designers and developers in a lot of ways because i think a lot of businesses consider um engineering services and design services as kind of a pair of hands or a kind of a service that is provided to a larger um kind of vision and yet we're populated by all these people who really care a lot about what the solution is and how it works and is it the best solution possible and you know um i i almost never hear developers say that's not possible that's not you know technically feasible is i know we talk about that a lot but they have a really expansive um vision of kind of what's possible in the world because software is really very you know it's almost limitless in some ways um and i like that about working with developers i think um maybe where the the challenge comes around um designers really needing to uh to to be attuned to kind of how developers see the world right they uh they want to make sure they're not wasting effort right um and designers don't quite think about wasted effort in the same way i think so there's there's a lesson that designers need to learn about how to um to help developers see that what they're doing is efficient and also what they're doing

is meaningful right because i think developers want to see uh the impact they're having they want to know why we made a decision so a really important thing that designers can do as they work with developers is to to help developers understand the the motivation or the the thinking behind design decisions let's say so that they can kind of feel on board and a part of the process because often they have a lot of great thinking and a lot of uh i think fresh perspective that designers maybe hadn't taken into account yet so um being good listeners there too and having that kind of partnership you know be a collaborative one as opposed to a a telling versus receiving one if that makes sense um i don't know how i don't know if i'm describing anything that i wholeheartedly agree i think that um something that you said there around the idea that uh in a lot of ways it is the designer's responsibility to understand how to work in a developer's world more so than it is like here's what developers need to know about designers so that we can be happy together right so you're putting the burden on you on you absolutely yeah absolutely i think i do agree probably 90 percent on on the designers of the world to understand the realities of development in order to um play well in in that environment where you're actually shipping software um some of the things that uh you know that can help from a developer's perspective is uh is to assume good intentions i guess right this is such a broad grand thing to say about about your colleagues right but um and of course it places a burden on everyone to have good intentions because you don't want people assuming you have good um but yeah to that to that point of like you know when there's friction because a designer wants something a certain

way and that is clashing with some development reality or whatever um that it's not because the designer's stubborn and just wants something cool and pretty it's because the designer sees that there's a a user value and therefore a business value to doing it that way and uh that then it's on the designer to like you said mate to bring to bring some of that down right because i think you're you're very true that uh there's there are few developers that i've ever met who just want to code and don't care that if what they do matters right and they want to be able to make sure they're doing the right thing too and that they're they're making that if having an effect with the work they do absolutely so your your objectives are aligned uh yeah if you're both going into it with good faith uh it sounds like you know you can be effective um but you mentioned something that kind of caught my ear that that uh if i'm hopefully i'll repeat it correctly that developers kind of think about the way they use their time and efficiency a little different than than designers what did you what did you mean by that well i guess i i think we have different i i think the two disciplines have different concepts of time um software is so often i think it's evolved in this way where where software development it is it gets boiled a lot down to chunks of time or units of of effort um and that that's true of you know agile methodologies and other and other you know non-agile things where lots of software planning happens where we try to plan things out in units and and so i think developers have sort of trained themselves to think in terms of effort and and and uh being as efficient as possible um in terms of it could be time or it could be you know keystrokes or whatever it is um they they actually they think a lot about that i i believe at least in my experience um working with development teams and whereas designers um uh

i mean i you know they're they're sort of there there's this different concept of time i think designers really need time uh to to to kind of immerse and you know and like get it all sort of loaded in and feel like we're sort of swimming in in in information and i think uh or marinating i guess is the right word because it really is kind of time time needed to to get it all in internalized and it's a different kind of uh um incremental process it's not it's not it's not quite so bite-sized or it's not so it's not so easy to divide it up into tiny chunks it's the consistency of output right developers are striving to be a little lumpy and see of output and design just doesn't work that way yeah absolutely it's maybe one of the fundamental reasons why agile has been so it's been so difficult actually to sort of merge design and agile over the over the past decade or it's been you know a challenge right because because the two kind of mental models at the time are a little bit different um well that's interesting we've tried to invent ways of making it mesh a little better yeah well that's that's a good segue into you know take us into the to the extent you can the evolution of design so you know you mentioned being a bit of a challenge to kind of mesh agile with design methodologies that you're i guess were more traditional um talk about kind of where where you were as a as a discipline 10 years ago and and how that's changed with with agile i mean we've touched about the iter process and a lot of the um a lot of the practices you use but but maybe kind of walk us through a little bit the evolution uh and how it's evolved over time yeah i i can talk about it from uh from mostly pivotal's point of view but just my experience in the agile community from 2009 or 8 or so uh till now you know in in early days design was really not a part of of a lot of agile

process and and pivotal's situation in particular as a extreme programming based agile shop um exp kind of just assumes that good inputs have happened somewhere upstream and that they have that said this has resulted in a prioritized backlog of things to build and um originally that the the the good inputs typically came from product management in some way or shape or form right um and sometimes those inputs were pretty ill-defined just like here's a feature we need or a problem that you know we have to not have um and other times they were pretty well specified and and clarified so that there was real uh you know good well-formed stories to deliver on and when design came into that equation the first place that they ended up getting put was okay well let's get them let's see where they fit in this delivery backlog right and designers ended up being pulled along with the development flow right like this development story is ready like what's the design like i don't know that this is where this country this time crunch comes in right like well we had a story that needed to get built and like prior to a user experience person being on the team they maybe the developer would have just coded it up with and just like thrown buttons on the screen i don't mean that just literally but like they would have done the best that they could to to put the interface out that got the job done right and some you know some developers some teams um were very successful that way had the design sense or whatever else to to create good products that way and a lot a lot did and you end up with a lot of pretty clunky software right and the first place designers ended up was in the like in between this the directive having come from product management of like this is what

we need to do and the developers saying okay great we're going to build that and like there we are in the middle getting crunched and so uh at pivotal what we really tried to do what we really have done and focused on doing is moving the designer upstream right to a place uh closer to where and you know i in no way want to call this waterfall but closer to the traditional model where well first you figure out what you're going to build and then you go build it right now in an agile world that's that's done in tiny little chunks as opposed to the entire software product right so what we typically do at pivotal is we have two different work streams that one that feeds the other and that actually the feedback from output of that feeds back into the original so dual track agile is the industry term where essentially uh product management and design will work primarily out of a uh work stream it may be a formal backlog and pivotal tracker it might be something less formal like a kanban board in trello it might be something less formal than that like a list and a sauna of things that they know they need to be working on right um and the goal there is the discovery work and the and the definition of what we should what the problems are we need to solve and then what should we be building right and the end result of that is that developer user stories get created in the in the development tracker right so the delivery the discovery track says this is what we should be building and the delivery track is this is how we're going to build it right and now pm design and engineering are all involved in that delivery track as well because like i said you don't have a fully spec'd you know waterfall based here is what you're building it's this is the need we've identified this is the way we're going to

approach solving for it um and so that then designers then get to uh and and that discovery backlog is less um it's less regimented i guess right it's it's looser it doesn't have that same you don't typically have that same um estimation process of getting a velocity down and understanding right like you're forcing function as your is your delivery track like this is how fast the team can build software and though so that factors in to how what time you spend above it right and you can buffer some of that time ahead and beyond so really keeping them uh tiered like that has has helped us to make design a healthier part of the process it's not perfect but it's certainly come a long way from early yeah that's interesting i think you know at lipro digital and design it we've we don't call it the same thing but it's a similar concept where we kind of put we try to put the quote-unquote production design or the sort of close to the metal design on some rails right so that there's some kind of framework or some sort of foundation that they have to to go with and some sort of you know modules or standards or some sort of tools that they can use to to solve those those problems so there's some kind of definitional work that happens call it sprint zero or whatever you want to call it and then it then then design obviously gets involved in that delivery also so yeah it is it is a very similar similar model and i think you know there there's as far as the evolution goes i mean we're you know i think we're just starting to get to this mature place with with design and agile happening together um more harmoniously and you see a lot of like let's do it where let's do a staggered thing where design you know happens one sprint in advance or something along those lines and i think that even kind of misses the point a little bit too but and so that's why these more sophisticated kind of uh dual

track models i think will end up being um being the right way forward yeah yeah there's something that that uh you sort of touched on there around this idea of modules and and frameworks right like so um the biggest thing happening in the design world right now is design systems and front-end frameworks yeah um and that's exactly just to to allow for that kind of thing right where you don't have to have designers as uh gates in the process for everything that has to go into the product right you figure out what is the toolkit that that implementers can use to do things like when you need a new table with three buttons on it and uh uh you know that results in this widgety workflow like great there's there are there are concepts for that um it's really interesting in that it brings me back to uh my time at cooper when uh a major part of the work that we did in the uh in the third phase the final third of our engagements was develop this system that was very robust and flexible and could grow to accommodate uh changes over time to your application right um and but of course we we you know back in 2006 um we did that in some you know whatever it was adobe frame maker or some kind of awful thing and and it was a document that we delivered to our customer to our clients to the development teams that they could then use as the tool kit to build it and now you know we went through this dark time i think in agile and design where we stopped doing the former of coming up with a good holistic system but we hadn't yet developed the latter which is develop as we go a living robust system right and that's where we're headed right now

is organizations having that kind of uh that toolkit that framework that set of modules where designers can work at the level of you know here's the workflow here's the here's the problem here's the feature here's the the way we're going to approach this and then the details of implementation of that you know the pixel perfectness uh isn't something that is bespoke anymore you can actually just say well use that component of course right yeah yeah design systems are interesting it is definitely a new frontier it's um it's also a bit i don't know it's a bit of a bit of like the wild west new frontier as well as there's some dark things happening out there and some dangers uh that we're just beginning to learn about um you know like where if a design system is there then anything that uses the design system is the correct solution uh kind of thinking or or or being sort of beholden to the system as if it's you know as as if it's um a design system in itself is somehow it somehow delivers business value um over and above you know the the benefits you're describing like efficiency and so on so there's there's like over reliance on design systems and and uh and thinking that if you have a design system then all is well and you know no no need for more designers so that that sort of those pitfalls aside i do think it's a it's a an improvement in the industry and something that again we'll learn it's it's still it needs maturing and you know people are still learning how to do it um and a lot of our colleagues are at that frontier and and you know kind of experimenting with new models and i'll be curious to see you know how design systems end up as you know part of design systems are interesting they're not just a an artifact you know some code samples right and some design modules it's actually an organizational problem to implement a good design system right you have

to get people to adopt it you have to get people to feel like it's worth updating and you know maintaining and so it it it actually brings in all these other interesting kind of organizational challenges that um you know that we haven't that we hadn't thought about before um and uh so yeah it's it's definitely an evolving uh an evolving part of the discipline yeah it definitely sounds like an industry or discipline kind of in flux and as a as a designer you have to it sounds like you really have to be able to adapt quickly and and be thoughtful about the tools and techniques you're using and not just kind of accept okay this is this is the standard way because there is no standard way you're still kind of developing it um which again kind of leads my my next question we only have a little bit of time left but i am curious about you talked a little bit about your backgrounds earlier but let's go back even further like what what got you interested in in design and what is the back what does the background of a designer look like what what's the how do you get into this field is it you're more of a creative type are you more of a technical type how do you end up in design it's i think the answer is new now it used to be different right for tim and i probably it's different than the new generation um just just coming into the field now because you know when we were starting this wasn't even a profession really it was it was uh or it was in my case it was a nascent one so um you know i think new designers are are coming into this with a little bit better set of tools that you know frankly you know some of which were developed at cooper back in the day and uh and across the industry of course um um but yeah our our backgrounds are probably different than you'll see in a new in a new designer out there today um tim what what is your early background i don't even know i'm i'm yeah i mean like like like most folks of my uh vintage of of in-user experience design um liberal arts major right um i i actually started uh in the industry by teaching myself html and getting a job as a front-end developer

and as i got into the business of building websites i was immediately curious about like well why are we building it this way like who's going to use it what's it for that's really what they need right and i was gravitated towards the the few people in my agency at the time uh whose job it was to understand that right and and so um i ended up coming into the into the discipline just through uh internship and and guidance sort of colleagues mostly right um and you still see that right uh you definitely what's what's what's very true is that you know these days there are a number of really good programs in uh collegiate and you know post graduate level courses or or you know um programs for user experience design for an intersection of design and business is a really fascinating one right um i know of a few programs in that vein and you still see people come from adjacent disciplines within tech right developers who think enough about you know why they're doing what they're doing that they realize that becomes more interesting to them than actually implementing what they're doing so they move that way um product managers who gravitate more towards the user side than the business and market analysis side you know things and they realize oh i actually care about that aspect of it more um people from uh testing or education places like that where where you're really focused on on understanding someone's needs and then doing something to meet them right i mean that's that's really what this job does yeah i yeah i have a similar i guess well i went to a small liberal arts school in

minnesota and it's funny you mentioned liberal arts because um and i guess more broadly social sciences and humanities and so on um we definitely hire for that at design it that's a really great you know people from the education world or from you know uh who studied literature or you know or really kind of human centered you know uh uh fields of thought really um can be trained i guess to use to reach you know to refocus that lens on technology in a way that is really kind of rich and and adds a lot to the teams that we build um i have a colleague andrew coptiel who likes to say that design is the liberal arts of tech and it's true it's you know it's like there's a kind of um a storytelling part a piece of it that's really important um to to people who do design um and and yeah we definitely try to find pockets of of untapped potential in those other in those other areas psychology is a really uh fruitful um area for for designers and and and all the other you know sort of uh human-centered disciplines like that well as a as a fellow liberal arts major i'm i'm glad to hear that that uh that industry is open to open to us um fantastic so we're just about out of time uh i did want to just touch on uh of course the partnership between pivotal and and wipro digital uh it's a fairly young partnership just kind of getting started uh although we did uh pivotal was lucky enough to just win the digital transformation partner of the year award from from wipro uh was i was down in florida for your uh leadership event and was pleasantly surprised to uh to win the award that was um but as we as we kind of start to grow the partnership what's your um how do you see the impact of of our two organizations working together on our joint customers i know from my from my perspective pivotal's goal is really to uh influence and change the way that

world builds software right and that's not something that we can do on our own with our 1500 people or however big we are right so um i know this goes comes all the way from rob me right like the idea of of just opening our toolkit and opening our approach and saying like we think that this is a great way to work uh we want other people to be able to take part in this as well so i think having a partner like wipro digital to be able to um help to just bring more people that approach is a big one for me yeah and i think you know wipro is if if nothing else it is just an organization that has an insatiable desire to learn and grow and and to expand in its in its own kind of uh knowledge and you know uh in its own sort of internal passions and wipro digital was set up only a few i think a handful of years ago to try to focus that on you know digital transformation and technology specifically and so pivotal i think is really just going to be a i think it's going to bring a whole bunch of new learning and sophistication and other sorts of tools like we're going to learn so much from pivotal and i think that's that's really one of the big benefits um about working together is that we get to sort of we can contribute scale and and uh there's some really deep expertise inside of wipro and wipro digital and that by working together we're going to improve you know both companies it'll be a mutual benefit so i'm really excited to see that i mean part of what was exciting to join wipro in the first place from cooper was again that kind of going from a very small to a very large organization we have a chance to yeah have a bigger impact on our clients um at a much bigger

scale and so you know that the projects that we're involved in already are are you know vastly vastly larger and and more impactful and more interesting in in my view uh so hopefully with pivotal that can continue to grow absolutely i'm excited to see where this goes uh and i would love to have you guys come back on let's say six months a year let's let's see how it's uh progressed and maybe we can talk about some customers and uh some of the great outcomes being so guys thank you so much this has been really educational for me uh coming into this not knowing a ton about design i really appreciate it i think our listeners are going to really appreciate it too uh so thanks again for joining thank you thanks for having us thanks jess

Tanzu Talk · 🍕 Get more pizza.