Disrupt or be disrupted. Traditional approaches to building great software are quickly falling by the wayside. With myriad of smaller, more nimble competitors rapidly entering the marketplace, how will your business innovate, survive and thrive? This series offers readers tactical approaches to building software that your customers love. Break down existing silos and create an environment for cross-collaborative teams: placing technology, business and user experience design at the core.
This InfoQ article is part of the series “Design And Technology: Joining Forces For A Truly Competitive Advantage Content On InfoQ”. You can subscribe to receive notifications via RSS.
Does design shape technology or does technology shape design? How do these two disciplines work together, and move away from the traditional siloed approach? In this virtual panel Sam Gibson and Ben Melbourne discuss the importance of overcoming adversity between technologists and designers by offering tactical approaches to solving these common issues.
InfoQ: Does design shape technology or does technology shape design?
Ben: The two are intrinsically interlinked. Both provide inspiration for the other. There is an element of truth that sometimes limitations of technology can prevent designers from thinking big, but technology often comes up with inspiration and new ideas and approaches that design has never thought about. The theory is about incremental innovation versus disruptive innovation. It suggests that incremental innovation is climbing to the top of the existing hill that you're standing on. It's limited by the size of that hill. That's often what a lot of UX designers focus on. They run usability testing, trying to tweak and improve a particular product and service. But they lose sight of the fact that there might be other bigger mountains out there to climb.
The two play a key role in actually challenging and shifting their perspectives of data discipline.
Sam: When I think of design versus development or design versus technology, I always think of how science fiction has driven technology to be invented where it's kind of -- really it's a little bit beyond design but the idea is this visioning which is part of design. But the visioning is what drives the technology being invented. Years ago no one would have thought of tablets, or being able to call anyone anywhere on the globe. But that gets driven forward through that visioning exercise. Ben, you're completely correct. Constraints define how you do design. That's true both in art and in visual design and digital design.
I think without multi-touch screen would anyone have designed iPhone or the modern smartphone interface? Probably not. Before that technology existed there wasn’t this canvas on which you can draw that or the metaphorical canvas in which you can draw that. I don’t think the two can be separated or I don’t think it's one or the other at all.
Ben: I would like to point out, they're still not flying around on hover boards but that's a side point.
Sam: Yes. And we still don’t have teleporters either.
InfoQ: we're all seeing digital disruption across most industries, and certainly the industries that aren’t disrupted yet will be soon. How are successful companies surviving this digital disruption?
Sam: The real answer is that they become software businesses, that their business becomes software. It's funny, actually if you talk to the CEO of GE, they've started this big initiative where basically they're changing over a ton of their hardware business to be software like trying to do this transition to a 90% software business in the next 10 years precisely because as manufacturing becomes more commoditized and software becomes more and more valuable because it's harder to replicate quality software. It's harder to do deep research and development on technology. Because of that, you end up with a much stronger business position than you would otherwise.
You can see it anywhere. Natural resource firms are doing investing into supercomputing. Walmart is investing in big data. High frequency trading is disrupting finance. You've got Skype that's the fastest growing telecom; PayPal that's disrupting international payments. All of these are all making software as their core competency and using it to break down traditional barriers. Unless incumbents do that, they're going to die. Marc Andreessen, the venture capitalist, talks about software eating the world and that's precisely what that is.
Ben: There's also an aspect where the software industry itself has been maturing and evolving its approach. In traditional practices in companies, technology has been a handbrake. It stopped businesses from moving as quickly as they can by slow release cycles that could take years to get a product out there and to market it if at all, whereas that constraint is starting to shift now with new practices like continuous development and continuous integration. Technology is no longer the deciding point about when something should go live. It's business that's deciding when they want to go live with a particular product.
InfoQ So you're talking about a growing partnership between the business and technology. Ben, one for you, what role does design play here?
Ben: I often talk about design as a facilitator rather than just a designer. Designers and design thinking skills allow us to be able to create a vision and facilitate that conversation between the technology and the business in exploring what's possible. You're coming back to that idea of whether design or technology fuels each other and the constraints around it. In reality, it's the collaboration between the technology, design, and business. When you have that close collaboration, you get really exciting and interesting results.
Designers had a key role to play in facilitating that conversation and using the research design skills to understand customer needs, and to be able to articulate a vision of what that would look like or what products can we provide to support that need. But it's not something they can do by themselves. They need to take the business and technology along for the ride.
Sam: I think Ben is entirely correct. Design is the channel through which business needs are met and technology is the driver, the engine behind that. Without design producing actual business results, I don’t think it matters. None of it is relevant and so you have that design capability especially not today where consumers are much more discriminating.
InfoQ: Historically there has been a divide between design and technology. I think we've answered the question that the divide should not remain. But what can companies do to encourage closer collaboration?
Sam: So the divide has traditionally been around designers asking impossibly difficult things of engineers. The real problem is that the divide exists and so designers design in a vacuum and then they kind of throw it over the wall to developers or to the implementation team who then they implement it in a vacuum. Both sides are cursing at one another because the designer is like, "Well, this isn’t what my vision was when I thought it up." And the developers are like, "Well, that doesn’t work because x, y and z."
So you end up in a situation where the design doesn’t help the chasm. The divide doesn’t help anyone at all. So bridging that gap is important to me as a developer. There's another thing where we think like Steve Jobs as the guru of design. He wasn’t a designer but a business person driving design, and so design became the center of the organization.
I think when you're an organization like Apple, that might be something that you can work on where a design is part of your DNA. It's entirely about what you're doing. Your product is your design. But for most organizations where you don’t have that as your core pillar, I don’t think it's reasonable to do that. The compromises need to be made both on the design side and on the development side to start to bridge that divide at all. Otherwise, it's always going to be the same way where we're just throwing things over the wall.
Ben: Actually, I don’t think Apple provides a very good case study for this kind of conversation. I think Apple is a very unusual and unique example that I don’t think many other companies would be best trying to replicate, they provide some great inspiration and that has changed the industry. But I don’t think many other people could reach that same state.
What I would say is everybody has a part to play in actually removing that divide. You've got the three main areas: business, technology and design. Maybe that's being shaped by the classic Venn diagram of desirability, viability and feasibility. Ultimately, that divide exists because each of those three areas has happily reinforced it. Designers have worked in isolation in their ivory towers. Design agencies are seen with their headphones on throwing documents for developers to try to build.
Developers haven't reached out and tried to understand and actually take on board design principles and often have had no interest customer needs. But there are simple ways it can be achieved and broken down. Designers can become embedded parts of delivery teams and sit there side-by-side to communicate. It's unnatural to have the two broken apart. But likewise, designers can invite technologists and business people into their process as well.
There are other simple methods that can be adopted such as taking developers or product owners along for customer research in the field so they can observe customers firsthand. Some of these really simple techniques quickly remove that divide when you bring everybody along for the ride together. And likewise from the business side should bring technologists and designers into the conversation before technology becomes a solution.
Technologists have a lot of good inputs that can help head off a lot of problems and waste in the process. By bringing technologists into that original context gathering, they can help provide input and provide both simple tips that can avoid some of the resource wastage that takes place in projects. Or alternatively they can provide simple and easy tools that actually help inform decision making. It's taking everybody along for that entire journey from day one that can produce really simple and innovative results.
InfoQ: What practical advice would you give practitioners around building an environment for collaboration?
Sam: That's very challenging question I think. One of the things that I -- this might be a bit of a tangent so bear with me for a moment here -- admire most about designers, especially good designers, is their ability to take criticism. Actually it's one of the things that part of their job is often to put something up on a whiteboard or put something up on a wall or something and then have people come up and critique the work, and people who are just not at all qualified to comment on it in any way. They're constantly hammering on it and chipping away at that.
It's sort of like trial by fire for designers that they go through. If you don't have the tough skin and the ability to take criticism, internalize it, and then use that to drive out a better product, you won't survive as a designer. Where I think developers often have the opposite where often they work very much in isolation or the large corpus of what they work on it in isolation. And then as time goes on being more and more in isolation inhibits you from taking any criticism whatsoever.
And so as you bring designers and developers closer and as the communication starts to flow more bi-directionally, that will hopefully start to break down that inability to kind of look critically at what it is that we're making and actually end up casting our product in a different light where we're working toward creating a better thing rather than aiming toward my own little fiefdom. It's not exactly what you were saying, but I feel quite strongly about that. It's one of the things I admire most about designers.
Ben: I appreciate that. To be fair, developers do have a lot of those same practices in place.I guess one of the things that actually starts to matter is about culture and practical activities. Practical activities and tools tend to build culture. But it also is that culture of being willing to fail fast. You have to be willing to put something up on a wall, test it and find out really quickly how effective it is and does it actually meet user needs.
It's interesting. There are different practical aspects to that. I actually had somebody pull me up recently and said they don’t really like the term failing fast, which to be fair does create a lot of anxiety in people. They actually prefer the term failing forward which is a really subtle shift but it's about being willing to try something and being able to get feedback from that but do it in a way that is productive and moves you forward as a result. So it's not just about failing. It's about failing with a purpose.
Sam: How many organizations have you worked with, Ben -- especially large enterprises -- where you think that they actually accomplished that? Because in my experience often the larger the organization gets the more conservative. And so it's easy to say we want to fail fast, but it's often hard given the way that budgeting works or the way that projects themselves are incepted to ever get to a point where you can do, say, lo-fi prototypes of five different crazy ideas, put them out there, and then keep only the ones that work because you've already invested in this big huge project. So you almost pay lip service to failing fast by -- you've already chosen what the project is. You do some lo fi prototypes, you go show it to customers, and you try to improve on the product, but you're never actually using it as an innovation driver. It's simply just something that you used to work towards what you've already decided the end goal is.
Ben: It's interesting. I would say it's not really a conversation you can have at the organizational level, but every company I've ever worked with there's examples where I can say yes and no to both those questions. And very few organizations do that consistently across the board. It tends to be smaller teams that are able to in some ways isolate themselves as team a little bit and provide some protection so they have at safe environment to go and start testing it finally or try new ideas. But it all very much depends on the individual team, the product and project they're working on and the timing around it.
What I would say within that though is you're right, sometimes projects really are pre-determined before people start up and start working on them. It doesn't mean to say you can't take that same mindset into every step of the journey, whether you're actually testing the original proposition or concept itself or testing elements within that product. It could be anything from a UI level widget all the way back up to the actual value proposition for the customers. There is a time and a place along that journey for testing all of those things. Then you actually get feedback as you go.
InfoQ: How does the notion of the user or the customer actually shift in an enterprise context?
Ben: The difference is generally that customers are a lot easier to access in startup context whereas in enterprises, there's a lot more layers of bureaucracy that exist between customers and the people making decisions. A great contrast is actually you think about the old school mom-and-pop store. The people running the business have direct daily contact with the customers of the business that they couldn’t avoid it whether they liked it or not. As organizations grow in scale, suddenly that direct contact becomes one step removed, two steps removed, etc. to the point where the business decision makers are completely removed from the customers and really have any particular contact with them.
The key role of UX design is to to bridge that contact and connection between customers and decision makers, and helping people get outside of building and trying to bring some of that outside thinking in.
Sam: one of the key things around enterprise and actually one of things that make it more challenging from UX perspective is that enterprise users are largely a captive audience. So generally, it's much harder to acquire customers than it is to retain them. Particularly, in the finance or insurance sector where you have organizations that have lagged behind technically, that customers are generally used to dealing with crappy software, generally don't mind dealing with it because the barrier to entry for changing it is so high. In a lot of ways it becomes even harder because even when you access the customers, it may still not be enough to drive out what it is that takes for them to actually shift their behavior or to make the product better.
Actually, one of the things that I find quite irritating about this is that in a lot of ways innovating within enterprise or doing radical designs with an enterprise is far safer than doing it from the point of view of a startup because a startup requires that they kind of keep this hockey stick kind of growth; otherwise, they'll die. Where an enterprise can take their captive audience, they know they're not going to leave. They can try something totally off the wall. It may not work, sure, but they're not going to see a huge impact to their business because of it.
InfoQ: How do you approach designing software for internal users in an enterprise different compared to how you would approach it for external users?
Sam: Should there be a difference? Probably not. Is there? Absolutely because it's simply that doing design is expensive and your internal facing customers are a captive audience, literally -- they’re captive!
Ben: I agree. It's funny. I smirked to that question because it's one I've had so many times. Fundamentally, it's a far more costly experience to design a bad piece of software for your customers than the need for internal employees simply because customers can go change companies and go somewhere else, go to a competitor; whereas employees, you can train how to use a bad piece of software. It's not to say there's not efficiencies that can come with improving that and making their lives easier. It's just the fact that the cost goes up. But ultimately you can get around that. In my mind, it's still a cost-benefit analysis but designing and delivering a really crappy product market will kill a company where as doing that internally will just simply slow down your organization and your ability to deliver things.
Sam: You're right, but it does depend on the context. If I'm writing some internal call center software and it means a drop in my ability or the ability of my call center efficiency by 50% or whatever it is but I heavily rely on my business, on the capability of responding to a customer requests through my call center, then of course that's another matter. But ultimately, that's a service the customer. So it's really hard to decide what do you mean by internal facing versus external facing because while that is a piece of software that only your internal employees see, it directly affects those external customers.
Ben: Having said that, I would be very, very disappointed if any UX designer accepts that as a constraint and doesn't try to push the perfect ideal solution to their target audience even if it’s an internal product.
InfoQ: So we're just coming into the end, guys. We're just going to wrap up our leaving the audience with a piece from each of you. I'll ask Sam first. Is there anything at all that just drives you nuts from a design side of things or something that you wish designers wouldn’t do?
Sam: I actually really like working with designers because at the end of the day I'm not there to get delved into the code and solve some super complicated whatever. I'm there to produce a product that people use and that they get enjoyment out of and that's useful for them. Designers have a skill and a skill set and an ability to bring a capability to the project that I don't have. Without it I think we would be less successful.
I don't actually mind designers railing on the way things are done, and I don't mind designers passing up impossibly hard or extremely difficult things. I like working with them and producing their products.
Ben: I agree. It always makes me annoyed when designers don’t enjoy working with developers which is crazy. The thing I would say to that question is the thing that drives me nuts is developers who don't care about fine details. One or two differences or that shade of color and just making a UI just not look as good as it could be drives me nuts. It's not because of the actual design detail. It's about the mindset that's behind that -- to me what that says is a developer doesn't care about the quality of the product. Whether or not they care about the quality of a code base or maybe how reliable it is versus the why, it's all part of that.
That quality to me isn't just about whether or not there are bugs in the code and whether or not things break or not. It's about everything in that production looks as it should. If you don't care about some of the constraints and challenges that technologist face and some of the work involved in being able to build some of these fancy UI elements that you can come up with and imagine, then you don't care enough that your team and the ability to build the best product that you possibly could.
Broadly speaking, removing that divide between design, technology and business is the most important challenge for any organization who is working in a digital world right now, which pretty much means everyone. So it's incumbent upon everybody to remove that divide and work together and collaborate as closely together as possible.
About the Interviewees
Sam Gibson is a senior technical consultant and software developer at ThoughtWorks in Sydney, Australia. More than anything, he enjoys helping people and organisations deliver products that people want through software. Sam has worked across a range of industries and domains, including several successful startups, financial institutions, media companies, and retail businesses. His current interests are to accelerate software eating the world. He’s excited about recent developments that make embedded electronics more accessible and is an enthusiast of open source software and hardware. Find him tweeting at @capnkrump
Ben Melbourne is a Digital Strategist with ThoughtWorks who helps organisations create products and services that make their customers lives better. His background in user experience design provides a passion for a customer-centric approach, along with the research skills required to drive outside-in thinking. When combined with his depth of delivery experience he knows how to take an idea and turn it into a product that customers love. Now that he’s gone Agile, he can never go back. Producing pretty design deliverables just doesn’t give the same thrill it used to now that he has experienced the joy of working in lean, multidisciplinary teams focused on delivering business value rather than documents. Ben Tweets at @benmelb.
Disrupt or be disrupted. Traditional approaches to building great software are quickly falling by the wayside. With myriad of smaller, more nimble competitors rapidly entering the marketplace, how will your business innovate, survive and thrive? This series offers readers tactical approaches to building software that your customers love. Break down existing silos and create an environment for cross-collaborative teams: placing technology, business and user experience design at the core.
This InfoQ article is part of the series “Design And Technology: Joining Forces For A Truly Competitive Advantage Content On InfoQ”. You can subscribe to receive notifications via RSS.
