Design approaches for developer experience

Transcript

Thank you, guys. So, I'm Oana. Forget my last name. It's too hard to pronounce. It's okay. You can find me on Twitter with a different name, I'm Caelea, long story short. And I'm a senior user experience and user interface designer for a small startup that's based in LA. Basically, we are an OTT network delivery platform, also doing white label applications. That's the part where our experience with the developers come and work hand in hand both for API's part, and as well as right now we are moving to next steps and trying to get products where you can build yourself applications for mobile, web, and TV as well. Except for that, we're gonna find out a bit more that our audience is not only dev-oriented, but we also have young 16-year-olds who are content creators and this is a thing right now. Everybody is video blogging. And we also have media producers. So, we needed to find the common ground for everybody without trying to have one single interface for all of them because that will have been a mess. Of course, I will focus my presentation on the developer part and try to see if there are some design approaches we need to take when we are designing for developers. Oh, and I was also a front-end developer in my early ages, so I still like that part.

Start by asking questions

A little context. A lot of people in the design industry will think, "Okay. We design for developers. They are power users. Hooray for us. Our job is done here. They will get the interface we are building right from the start." Or we don't even have design in your team. If you're a small startup of five maybe design will come last. So, that can lead to a few problems. Very feature-heavy apps, right? A customer will come and ask something of you and you'll say, "You're my first customer. Of course, I will deliver. I'll give you the 10 new features that you requested." And the user comes, "Here are five more features." A big company comes and, "Here are 1,000 more features." And you might never know how to stop. Then, if you have built all these features, it means there is gonna be a very steep learning curve. It will take maybe one month for somebody to get a hold of whatever you have created. And it will result probably in a very, very heavy interface that nobody will love. Maybe something like this. I hope it is old and nobody will hate me for this screenshot. But as you can see, a lot of features that at some point somebody probably requested. So, what can we do to not end up here? Especially, because as we know, developers will probably go to Twitter and rant about us. If we suck, we're gonna know it quite fast.

Where do you begin even if it's a new product or you already have something? You can start by having your simple questions. What's the purpose of your applications beside making you money? What do you want to solve with your application? Who are you addressing? Are there similar apps on the market? And I have to pause here a bit because I know nobody wants to copy anybody else, but we also need to think that you do not want to reinvent the wheel on something that has been already been used for, I don't know, 10 years. It can be small things for this. It can be, I don't know, only a keyboard shortcut, right? Imagine an ID that everybody is using for... In my area, all the design products are using pretty much the same shortcuts, no matter who the company is that have created it, because that will result in a way faster time when I start a new application. So, it doesn't necessarily mean that you have to copy somebody else, but you have to know what they have done good and what they have done worse…not so good. So, you can innovate.

Of course, what are your main features? You will say probably 100 features, you should focus on a fraction of that. What do you want to actually improve? And what do you want to be known of on the market because this will eventually translate into marketing ideas? And in the end, how well do you think you know your users? And probably the answer is you do not. But here, we will get a better look on how you can get to know your users. And for the audience we have here tonight, I think you have an idea of how you can engage with your users or what you should do next, and I think this conference will help you with that if you haven't started on your path.

Just how useful are personas?

Let's say we started somewhere. We already have some bit of a product, it can be a wireframe, it can be a paper mockup, it can be an entire application that you have already built. It might look good. You can say, "Yeah, it's okay." But we still need to improve things. So, your first step. We were talking about audience and saying that developers are power users, but ‘developers’ is not one person, it never is. I put here only a few just to give you an idea of who are we dealing with. In my company, there are frontend developers, backend developers, app developers, DevOps, of course, and a few others, maybe system architects and so on. I think you know way better than me. And each one of them has their own purposes. Why are they using your application and what they want to achieve with your application? They are not the same person.

So, personas. Every single designer will tell you about personas and I think the marketing team will tell you about personas. What I want to do different, or for me is I don't like to think of a persona like a girl that has seen a movie in her free time that will not impact at all what she does at her job. So, I tried to focus and to bring my personas to be more related to the dev industry in this case. I watch their goal frustrations, especially. We all talk about emotions, emotions lead to frustration. And I think every single one of us when you use a product, at some point, you will become frustrated with it. So, trying to work with those can get you a way better understanding of your users. This also helps us to realize that we are not our users. Even if I've been a frontend developer at some point in my life, that has evolved so much. And beside right now I can use maybe Notepad++ or Atom.io, I'm completely lost if I will compared to an actual developer from my team, right? So, I tried to step back and say, "I don't know anything." Even maybe I just have an understanding of a few keywords.

Then you can fall onto the other path: you actually don't know anything about it, you do not understand the technology. You have to design something. You have no clue what that terminology is. A very easy way to help you get through this is to shadow. Shadow your colleagues. This helps in two ways. First, you can ask them questions. Hopefully, they will be nice to you and understand and not spend time on social media. And secondly, they are in their cozy environment, so as opposed to a usability testing which we'll get to which is super useful, shadowing will get you people that feel way more comfortable while using a product. And in the end, if you are building tools for developers, please make your team use your products.

So, I was telling that besides developers, we try to mix our audience with a few extras. So, we did, in the end, create personas for them as well. And we also thought of their interests. For example, if we were addressing young video creators, we think, "What are the most used platforms right now?" and probably is Snapchat for example, or they are uploading videos to YouTube. So, we have to bring that kind of attraction and part of the functionality into our platform as well to still make it appealing to them. Afterwards, they can still have access to the developer parts bit by bit, so they…in the end, if they are attracted to technology, they can also start learning to code. We offer documentation. So, hopefully, we can convert them to something that's much more.

Making assumptions

Okay. So, let's say you started doing your personas, you improved your product a bit, but it's still not enough. Probably this interface, say, can work for one of your personas, of your users, right? Maybe it will work for the content operations team, I don't know, but for everybody else, this will not be enough. So, we still have to go on in order and see what other tools can we use to improve the general experience. So, it can move to assumptions. I think everybody uses assumptions on a day-to-day basis, right? I try to give an example because if you're really moving to assumptions and hypotheses and like writing them on paper, you can start thinking of smaller ones. So, assumptions are, in general, ideas that you know that are true. So, you assume this, but if you based your product only on assumptions, you might fail. You really need to move a step further and go to hypothesis. The big difference between them and how you test them is assumptions you test them with research. So, I will assume that the dev-ops team needs a monitoring tool, right? And I do a bit of research. I will question the DevOps users if they really need such a tool. If you move to hypothesis, you can test that with actually experimenting. You build a first mock-up, a wireframe, whatever, and see how they use it or if it's really necessary for you to build that. Based on this, you can finally build your minimum viable product.

So, you can think that you are designing pretty useful things, but the most key aspects should be that first of all, they should be useful, then you can iterate until you also make them pretty. Right here, for example, is one step in our application where we are trying to build layouts for a certain page. This is from a larger part. We're thinking…we're also geo-blocking and regions and stuff like that. This is just a small step. So, we tested this on a easier version of it to see if we get enough attention, if people understand what we are trying to do with this kind of interface before moving forward. Otherwise, you might spend up like two or three months on something that nobody will use in the future.

Testing those assumptions

So, focus. Focus on one thing at a time, like a conqueror who is invading another country. Not a very good example, but if they were smart about it, think of it as a feature quest, an approach to how to invade another country. Think of future, past, they were trying an approach with the other country. It's the same for applications. Don't try to redo an entire website or entire app with just one usability testing. It won't work. If your website is like 200 pages…and I've been there in a previous job at Veeam, you cannot resolve everything in one month with one usability test. You have to focus on something, maybe search information architecture, one feature at a time and results will come and this will also help you talk to your stakeholders and lay out all the analytics you have that you have improved something, and things will started moving forward better and better.

So, in the end, we've seen that our users really needed some dashboards that are different and that can be customized for each of their roles in the applications. Our app is made to be super modular, so we can have user roles and user permissions, so we can address their needs based on whatever they are doing and what their job is. Because part of these needs, not only persona related, but are job-related, especially if it comes to developer products. Their job requires them to do a certain task or a certain thing. So, let's say 80% of them will have to perform it.

Testing methods. These are only a very, very few. This is the rapid way of doing and this is just an example. You can start by having a few questionnaires around for your user to start engaging them, see what they like most about your product. Mid-project, do a usability testing. You'll be amazed on what things you can discover and it doesn't even have to be a working prototype. It can be even on paper. You'll see that people do know how to click on paper. And, of course, you can go the extra mile and if you have a working product, you can rent Toby Eyeglass Tracking Software. And like the previous talk you have seen, you can imagine also seeing points where people are actually looking. It's one thing what they're saying, and another thing to what they were drawn to. Maybe a button draws their attention first and they will say something else about that.

Do not design for yourself

In the end, what else can you do? You can do A/B testing and you can do beta testing. Again, a great, great way to get feedback and it's also free. And, of course, good old analytics because they provide a lot of data and they do not like to engage their users over coffee at Starbucks. Avoid common mistakes. I'll try to be super fast. Do not design for yourself. One small example. We had a download button on our commercial website. The problem was nobody was using download because you were supposed to install something on your server that was like 2 gigs, everybody was using, I don't know, NBM installer, something like that. So, if marketing team thinks, "Oh, we only need to change the colour of the download button." That was not the problem. The problem was the download button itself. Not testing for accessibility. And I'm not sure if you know, but like 10% of the entire human population has at least one type of vision impairment. So, they may be not see some colours. And of course hidden action. When you think that your close button for a model is somewhere and is not, do not try to innovate where you put the close button. A different way to plan for success besides the usual measuring tools, make sure that your tools are used as intended, that it's easy to find the information, and, of course, you can't wait to show your mom and dad to be proud about how your design looks.

In the end, look on Twitter, look on Stack Overflow to see what people are talking about you. You'll find problems there as well that you need to address. So, in the end, key takeaways. Validate your assumptions even when dealing with somebody you think you know, you'll always be surprised about what your users say. So, know your audience, every developer is unique, and testing is your best friend. To answer the question that has been playing around here from this morning, like Peter said, "A developer is like a normal user." In the end, everybody wants something that is super easy to use and de-cluttered and it will work. It doesn't matter what type of developer you are. That will be it. Thank you.