DEVELOPERS Alexander Baxevanis - @futureshape UX Scotland - 20 June 2013 Hello everyone and thanks for having me here. My name is Alex and a long time ago I used to be a software developer.
developer 2 I still know enough to be dangerous when left alone with a piece of computer code, but nowadays I sit on the other side of the fence, designing websites, apps and other digital products for a lovely agency down in London called Webcredible.
3 I work here I get to work with some great colleagues and some even better clients, but there’s still a few problems that nag me from time to time. The problem that prompted me to come here and talk to you today is that I get to hear all sorts of things from both my colleagues and my clients about developers
me, it’s like I hear another language” When you end up making such complaints, it’s often difficult to tell who’s right and who’s wrong, but the truth remains that however great your design, it won’t get in front of users and it won’t have any effect unless someone builds it into a working product. And for the foreseeable future, this someone will have to be a suitably qualified developers. A word of warning – my talk will contain some sweeping generalisations, but bear with me.
IN THE CREATION OF THIS TALK When I talk about developers today, I mean anyone who gets to build your designs into a working product, whether that’s a website, a mobile application, a home control system, or anything in-between. By the way, I’m sure developers have as many debates about job titles as UX people do, but for our purposes today there’s more commonalities than differences. And if there’s any developers in the audience, you may think that I’m oversimplifying your work, but I’m just trying to summarise things for the purpose of this talk. Please bear with me, and come and find me at the bar later on!
11 Photo: http://www.flickr.com/photos/eepaul/5002302580/ We probably know more about how buildings are built than we know about how software is built. When a building is built, you often get to see the progress - from a big hole in the ground all the way up to a skyscraper. And if you pay close attention you can see distinct parts of the building going up: a metal frame, concrete floors, brick walls, windows, pipework, and so on.
Photo: http://www.flickr.com/photos/merydith/8445637186/ If you want to see how software is built, all you have is a room full of developers, and the things on their screens are generally incomprehensible to anyone but their peers. To see what developers do, we need to think about what software is actually made of.
does 13 • Storing data • Displaying data • Interacting with data • Communicating data to other software Model View Controller Regardless of how it’s built, almost everything that software does can be broken down into 4 functions. For the first 3 parts, you may hear developers using the terms ‘Model’, ‘View’ and ‘Controller’. In smaller projects, you may get the same developers involved in all of the above aspects, whereas in larger projects you’ll often find developers specialising in of these aspects e.g. storing data.
Someone dealing with storing data will need to give the computer very detailed instructions about how this data is structured and where to store them, and will need to ensure it’s accessible quickly and easily when you need it.
On the aspect of displaying data, developers need to create the right templates for showing that data on a screen, or communicating the data to the user in any other way. In the case of screen-based user interfaces, developers typically have to convert your wireframes and visual designs into instructions to the computer to place and decorate elements at certain parts of the screen.
http://www.flickr.com/photos/inky/3038840896 When developers deal with the interaction bit, they need to feed into a computer the rules that explain how the software respond to certain events, for example what to do when the user presses a button, or an action that needs to be repeated every 30 seconds, such as refreshing some data.
Finally, in a world where the software we use is spread across multiple devices, developers need to deal with communicating data. This means setting up the means for devices to talk to each other, defining what needs to be transmitted, how often, and in what format. Regardless of which of the above aspects a developer is working on, there’s a few principles that he or she must take into account when building software.
http://www.flickr.com/photos/donald/4433219470/ First of all, developers need to consider performance & scalability. You hopefully all acknowledge that speed is an important element of user experience - nobody likes to wait too long for something to happen. If a website or application is slow, people will abandon it, or if they have no choice but to use it, their productivity will be affected. Depending on the type of product, developers must also consider what happens when hundreds or thousands of users attempt to use it at the same time. Does it still respond as expected, or does it grind to a halt? Sometimes things like that can be fixed just by buying faster hardware or adding more servers, but in other cases there’s bigger structural issues that need to be addressed.
important principle that affects the user experience. In an ideal world, you’d want your product to work with the widest possible variety of device and in all sorts of environments. But getting to this state can require a lot of time, or a lot of compromises. There’s other principles that don’t directly affect the user experience, but have a big impact on how software is structured internally and how long it takes to build.
is one of the most important software principles because most of the software that gets built nowadays is never built entirely from scratch. Developers depend on libraries of reusable components to build things quickly. For example, when you build an iPhone app, you usually don’t have to come up with a new way of storing data on the phone - the iPhone operating system gives you enough components to do that. Reusing such components is great when they do exactly what you want them to do, but if they don’t, it might be quicker for a developer to build something from scratch than reuse something that someone else has built. At the same time, good developers hate doing the same work twice and strive to create components that they can reuse throughout a piece of software.
maintainability means that software is built in a way that allows it to evolve and adapt to user needs and other variables that change over time. There’s always a tradeoff between maintainability and development time. You can quickly cobble together a piece of software today that will be impossible to maintain tomorrow, and might need throwing away and starting over.
you can see that developers have a lot on their mind, but on the other hand a lot of their goals can be very well aligned with designers’ goals. So what is it that sometimes makes things go wrong between designers & developers? Sometimes it might just be that the people you’re working with are unprofessional or just not very good at their job, but that’s not really 100% of the time.
23 Photo: http://www.flickr.com/photos/goatopolis/211438486/ One reason is that while designers often focus on the happy path - the path than 90% of users will go through, developers tend to worry a lot about the edge cases. For example, what happens when you have an internet banking user with 20 bank accounts instead of 1. That’s because you can’t build software without specifying all the options. For every decision that you ask a computer to make, you need to specify what happens in each case. Sometimes the happy path is obvious, but often developers can’t distinguish it from other options. In fact, because developers tend to be “power users”, they might believe that some of the most complex use cases should are more important than what they should really be.
http://www.flickr.com/photos/waywuwei/2501242542/ Sometimes the technical correctness that developers focus on isn’t the same as correctness from the user’s perspective. For example, imagine you’re logged in to your internet banking and trying to make a transfer to another account. The first step in such a process might be to specify the amount you want to transfer. Now imagine you enter here an amount that’s larger than your available account balance. From a developer’s perspective, there’s nothing wrong here - the transaction hasn’t been executed yet, and by the time you go through a couple more necessary steps additional funds might have arrived in your account. From a UX designer’s perspective, I’m sure we’d all want to warn the user before they reached that last step.
There’s also a difference in the work dynamic between designers and developers. You won’t go very far as a designer unless you learn to get out there, meet a lot of people (both users and stakeholders) and communicate your ideas in the clearest and most persuasive manner. On the other hand, developers need a lot of focused time to deal with multiple layers of abstraction, fix bugs and sort out a lot of the details that make software work behind the scenes. I would argue that, compared to designers, developers need to spend a lot of time being in a state of “flow” that allows them to focus on the increasing complexities of today’s software. For that reason, developers often appear to live “in their own world” and are difficult to communicate with, even if they’re in the same room. Then there’s things that aren’t directly related to how developers work, but to the overall context and governance of a project.
A common issue is when developers are engaged on a fixed scope of work which was agreed too early, without taking into account that requirements might change as a result of your involvement. Or the predicted scope was simply too small. By the way, have you ever been in a situation where a design you thought you’d complete in a short amount of time took you much longer? It’s the same issue with developers - estimating how long it takes to build a piece of software is very hard, even for experienced developers. That’s because building software involves an element of design as well - there’s no fixed way to do things, you need to make certain choices and hypotheses that might later prove wrong.
other issues relate to the transition from a current system to a new one. As designers, we often focus on the ideal end state: what the new system should look like when all work is done. But the transition between now and that future state isn’t always straightforward. And we often don’t spend enough time planning this transition path, and prioritising what needs to be built first and what can wait until later.
isn’t always easy when developers have to evolve a system that wasn’t designed with the future in mind. It might be, for example, that it was built in a rush without any provisions for extensibility in the future. Developers have a term for this, it’s called “technical debt” - that’s because the time you saved earlier on will need to be “repaid” in the future. Now that we know what can go wrong, how do we fix it?
http://www.flickr.com/photos/simplerich/2888201504/ First of all, treat developers with the same trust and respect that you show for all other project stakeholders. Avoid playing a blame game and creating unnecessary escalation. A good developer is also a proud craftsman, and when he or she is convinced of the value of what they’re building, they want to see it done as much as you do.
empathy. Empathy is what we do for a living as designers, so you should be good at that. You should treat developers as users of your design - spend as much time as you can to understand their goals and challenges. Find out what the scope is from their perspective. They might have already realised themselves that something is wrong with that scope and if you back this up you might be able to go one level up to whoever holds the budget, speak in a common voice, and get things changed.
you can’t change the scope, you should treat developer time as a finite resource, discover what might delay them and prioritise. Deal with this as any other design tradeoff, such as designing for a small screen. It’s your responsibility to join if not lead the discussions that lead to such tradeoffs. If you let someone else make the decision, don’t complain about it! Even if you don’t anticipate any such tradeoffs, always highlight the important bits that are the core of your experience and shouldn’t change.
Of course your best chance to avoid scope problems is to involve them in the process as early as possible. Tell them all about your amazing ideas, but also let them talk to you about how they work, what their current platform can do, what their future plans are.
Try to understand what their working patterns are and how you can fit into this. If they don’t like to be interrupted often, can you get a regular daily or weekly slot to talk to them? If they’re based abroad, can you at least meet them once? Or if you can’t meet them face to face, can you arrange a video call? Do they have any regular progress meetings or demos that you can tap into. Often developers will assume that these are too technical for you and you’re not interested in attending, but if you do attend you can spot a problem before it becomes huge.
you’re lucky enough to be able to work in parallel with developers, find out how what deliverables need from you. Are they happy to start building based on sketches? Would an interactive prototype be more useful than a detailed specification? And when do they need it by? Try to prioritise your work based on what they need to build first. They may not always be able to build things in the same order as you design them - for example you may want to start from exploring the most challenging user journey from a UX perspective, while developers want a basic template they can apply to all pages in order to get started. In this case, and in many others, you need to find a compromise.
code When we design something, we usually try to step into the shoes of a potential user and see the world from their perspective. Since developers are also users of your design, try to step into their shoes as well. Start learning some basic development skills. Try to follow a tutorial and build a simple website or a simple application such as a to-do list (there’s quite a few tutorials out there e.g. codeacademy). You’ll immediately start having a much better grasp of what developers actually do, and you’ll start seeing the importance of some of the software design principles that I mentioned in the beginning of this talk. You don’t need to become an expert or take part in building the system yourself in order to have a more productive conversation with developers.
Once you understand what developers do, it’s also easier to pinpoint problems. Remember the 4 major things that software does … When a developer says that something is “impossible” or very hard, try to dig deeper and understand where the problem lies. Perhaps your designs calls for displaying data that’s not readily available in the data model, or not available in the right format. In this case, you should work with a developer to think of a better data model, and plan how to transform existing data to the new model. Maybe your design calls for interacting with data in a way that’s not readily supported by the platform used by developers, for example you need to support dragging and dropping some elements around the screen. If this is something that needs to be built from scratch, can you explain which user and business benefits justify the technical effort? Is there any small change you can make that makes things much easier?
of justification, most of the developers I’ve worked with are easily convinced when you can justify a design decision with data. Building software is a very data-driven and rational endeavour - it’s hard not to be convinced when you have all the data in front of you. And if you need to get the right data to make a design decision, developers can help you extract and analyse data from a working system.
see, once you’ve started building a good rapport with developers, you’re not just avoiding problems, you’re creating new opportunities. One of the benefits you might not expect is that you can tap into their experience to help you come up with a better design. Developers might not be designers, but the experienced ones have seen a lot of design come before their eyes and might be able to give you a spark of inspiration or stop you from heading down a dead end. If it’s difficult to remember all that when you’re knee-deep into design work, here’s a quick summary:
Show them the same trust & you’d expect from them 2. Build empathy - treat them as users of your design 3. Manage the scope and the priorities of your collaboration 4. Involve them early How to work well with developers 5. Understand their working patterns 6. Clarify the deliverables 7. Learn to code* 8. Dig to the detail of problems 9. Justify your decisions 10. Use their experience *Optional but highly recommended Have a look a this list at the start of every project, follow the guidelines, and I promise you: Developers will become your allies, not your enemies.
futureshape
sig
thebogheart
hayashirine
takumasaito
layerx
cyberagentdevelopers
sms_tech
yuichi_hara7
one0
kiyou77
tak073
cpineda57
thekraken
phodgson
bcantrill
jeffersonlam
shpigford
erikaheidi
nonsquared
danielanewman
morganepeng
kneath
davidbonilla
jlugia
![Alexander Baxevanis Chief Developer Negotiator and Senior UX Consultant [email protected]](https://files.speakerdeck.com/presentations/7d5ef610bc7e01300f863e4d25b30b1b/slide_40.jpg){kind=link}