Thanks for listening to “Don’t Make Me Code,” a Heavybit podcast that discusses developer experience design and the unique challenges of building developer-facing products. Don’t Make Me Code is hosted by Steve Boak, co-founder and CPO at Opsee, and David Dollar, co-founder and CEO at Convox.

In this episode David and Steve are joined by Dustin Larimer from Keen IO. They discuss affordances—the visual cues or attributes of a thing that inform you how it works – for developers.

This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market.

[soundcloud url=”https://api.soundcloud.com/tracks/251905881?secret_token=s-mL7jb” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

---

Steve: Welcome to “Don’t Make Me Code,” episode four. We’re calling this episode “Affordances for Developers,” and with us today is Dustin Larimer of Keen IO.

And he wrote a really excellent blog post about how they refactored their code based on some documentation and we’re gonna get to that in a second. I think, first though, since we’re talking about affordances for developers, we need to start with what are affordances? Since not everyone may know or realize what they are. And so I don’t know if you want to kick that off, Dustin?

Dustin: Yeah, sure. It’s a really cool concept. It comes more from product design and industrial design. We’re talking about the visual cues or properties or attributes of something that tell you how it works.

Like a really great example, like we’ve got buttons and knobs and dials and levers all around us in our environments and when you glance at it you can kind of tell. Like, “Well, this flips up and down,” or, “I can push this in and push it out.” And so, with physical products, it’s possible to embed a lot of knowledge about how something works simply in how it looks and that’s the idea of affordance, is that the thing kind of teaches itself to you.

You don’t have instruction manuals for coffee pots, unless it’s some kind of crazy new thing with coffee pot. Or, like, tea kettles or things like that. You know, if there is an instruction manual, it’s probably been poorly designed. Because it’s considered successful and you can just, kind of, figure it out. There’s not a huge learning curve to make it work.

And this gets really interesting with software because we’re moving from design of physical things to the design of, pretty much, invisible things.

Steve: Yeah, and in a digital space, we have things that we call affordances. Things that look like buttons or look like links and we’ve moved from these skeuomorphic designs to flat designs and a lot of that stuff, I would argue, is getting harder.

We have to rely on patterns that we know and trust and I honestly can’t tell, sometimes, if that’s getting easier or harder as we get better at this.

Dustin: Yeah, totally. Like early on things like tabs were kind of based on the little tab of a filing cabinet. Like filing sheets. Because people were familiar with those in the analog world and so it kind of transferred nicely into the screen world.

You know, things like drag and drop were brand new back when, you know, operating systems became consumer-friendly, so how do you teach people about drag and drop? So the little mouse cursor was a hand that literally grabbed and let go of things. So, it’s kind of a transition and the skeuomorphic era was largely to introduce mainstream public to how these interfaces work.

‘Cause they were familiar with how they, you know, they’ve seen them before so if something looked like a big ugly dial on the screen, you knew it could turn. But then, I guess Apple’s a good lead for moving away from that with their big redesign a few years ago. They justified it by saying, “We’ve moved into a time where enough people have learned about interfaces and screens.” We have a larger shared competency around these things so we don’t really need to make things that painfully obvious and rooted in the analog world anymore.

People have a little more capacity for figuring this stuff out and so they could move into a new world where there’s not really a lot of basis for how these things work. They just invent new patterns and it succeeds or it fails. So, a hamburger menu was one of those. Everybody agreed it worked and now they’re everywhere. To a detriment, I think. But things like that, these new languages, new vocabulary kind of goes mainstream. New words become very popular or fall out of favor.

Steve: Yeah, and they come and go kind of like fashion. The hamburger menu, again, being a good example of that. I feel like there’s been a lot of backlash against that because of the cost of using it that we only realized after playing with the implementation of it for a while.

Dustin: Yeah, it kind of also became kind of a crutch. People didn’t have to think so much about their information architecture because they could just hide it all behind a hamburger menu.

And that was the mobile, a mobile invention that made it into desktop and larger screens and a lot of the usability testing around that and, sort of, analytics around things like that find that it’s not a great idea. You know, it’s not a very effective design feature to just paste in arbitrarily anywhere. You kind of have to keep thinking about things.

David: It is interesting to think about though, because even if you do end up with a bad design, like if everybody comes on the same design, then there is some sort of value to that, right? Like, even if the hamburger menu is terrible, now that I’ve encountered my 550th one I kind of know what you expect of me here.

Dustin: You figured that one out. Yeah, totally. That kind of becomes part of our shared vocabulary around these interfaces.

Steve: 
And in the digital world, it’s kind of one abstraction away from the physical world, but then dev tools feel like a whole other level beyond that. Because now there isn’t even a clicky UI, necessarily. There’s nothing to latch on to, visually.

And that’s part of what made your story so interesting. And maybe we can start talking about that now. Like, what was the problem you were trying to solve and how you tackled it.

Dustin: At Keen IO I’m on the Experience Team, I’m a product designer, I’ve been doing engineering, also, for a long time. Kind of both interchangeably and when I came to Keen IO I took over all of our Java Script tooling, data visualization, dashboards and all that stuff. And so, that was the first time I was ever really faced with having to shepherd along a product that’s made of code and designed for people. There’s a lot of interesting moving pieces to that. But the idea was that we could keep adding new features and tacking new things on and just calling it whatever we wanted to and sort of letting feature bloat run away and do that or we could try to consolidate and shrink the footprint.

A big challenge is that when you’re designing a product you like to believe that it’s this really important crazy thing that people are going to spend a lot of time on and love, but then you have to recognize that you’re just one more vendor in their stack. You’re just one more thing to integrate so they can get on to doing what they really care about and you can’t afford to require people to learn about you. I think that’s going to become very competitive of developer facing companies is that time to value.

How long does it take for me to figure out what the hell you’ve created and how to use it and how to plug it in. And so, looking at that, we started designing with that in mind first. Like, how quickly can somebody find the code, install it, wire it up with minimal impact, minimal footprint and start getting immediate feedback that it’s working. And so we can’t just keep tacking features on and expanding the docs forever, we have to start shrinking at some point. So, with Java Script SVK where I’ve put all of my time, that’s a huge factor, it’s our most popular SVK.

Most of the data that goes in and out of Keen IO goes through that. Most of it’s coming from browser traffic and that sort of thing. So, its got to be super effective at people being able to learn it, install it, use it. And a big part of that is having confidence to know that the thing you’re using, or the way you’re using it is the right way. That’s another big one. Where a lot of things fall down. Where you’ve set it up and you’re running it, but you’re not totally sure if you did it right. The things, the names of methods, and the way that things are called. It’s sort of ambiguous and it leaves you wondering if you’re gonna get surprised one of these days, like you just did it wrong.

Steve: And we’ve talked before on the show, too, about the importance of boiler plate code and CLI’s and examples. Like, all the things that you rely on. And so for your Java Script API, this was just all in one place, it was one giant document?

Dustin: Yeah, it was one monolithic library. One big document. It did tracking, recording events, querying, running analysis and then visualizing it all in one monolithic pile and we started breaking those out into their own standalone libraries and we wanted each one of those to be very purposeful and effective and super easy to glance over and get it.

So, another thing we’ve run into with SDKs is the method name to log and event or just save an event into Keen IO is called a lot of different things. Like cross different SDKs it’s add event, or record event, or push event or whatever. The common thread being events, we talked about events, which is another point of confusion sometimes.

And so we thought, “Well, let’s just shore that up.” Let’s only say record events and let’s say it everywhere and that way when you see something that says record events you know with absolutely no hesitancy whatsoever that this is the thing you’re looking for, you’ve found the right method, this is the way to do it, it works in a predictable way.

So it’s really consolidating our vocabulary and shrinking the footprint so that it makes our messaging more effective because it works across all these different languages and it helps us focus the message and give people confidence that they’ve found what they’re looking for.

So they don’t have to spend hours hunting through docs and looking for examples and asking questions on stack overflow to get that assurance that, yes, you’ve done it right.

Steve: I thought one of the interesting things about your approach, too, was the team that you put together. It sounded like they’re developers, designers, product managers, people from all disciplines in the company that got together to work on the problem. Can you talk more about how you approached it?

Dustin: Totally. Yeah, so part of that is to do with Keen IO itself. So, we’ve always been hedged on generalists. Mission-driven generalists, specifically. Where we like to have people come in who might have some, in most cases do have some, really great specialty and competency in one important area, but have a lot of lateral interests across other areas and have spent time doing marketing or content strategy or design, in addition to engineering.

We find people who were doing one thing in life and then became platform engineers. And so, they bring a lot of really amazing breadth to the perspective when we solve these types of problems. And so, on my team, experience team, we are part of engineering, but we’re the part that makes the API fit for human consumption. So we built apps and interfaces and tools, developer tools, point-and-click user tools, all that parts of the website that people interact with when they log in. So we own the developer experience and the, just general point-and-click user experience. We want people to find what they’re looking for and get value fast. And so, to do that, we have some amazing engineers on the team. Some really brilliant engineers.

A lot of our stuff specializes in Java Script, ’cause that’s just the environment that we spend most of our time in, we build stuff in. But also people who have also done product management and design and content strategy and things like that in the past. So, we’re a very small team with a lot of very broad experience. And I think that important, to sort of keep breaking yourself out of the bubble where you might only see things inside of one paradigm and I think that’s where you get caught.

Steve: Yeah, and you were talking about the need for consistency, both in the Lexicon, and in the function of the tools. And so, it sounds like you ended up figuring out a logic to break what was one big monolith into pieces. And there was some pretty logic, it sounded like, that came out of that. So can you talk about the results?

Dustin: So the way we went about it first is we used the idea of breaking it out and having standalone SDKs for these three functions. For tracking, querying and visualization. We looked at it as a chance to, kind of, break away from some of the patterns of earlier stuff and try to build, like the ideal and then try to work our way back and make it somewhat backward-compatible. But we took the chance to really get our thinking clear first and to that.

And that’s where the thesis and that blog post came from is if we were building physical product, we wouldn’t start building a tea kettle by bending aluminum and hammering something out in the shop. We would probably just get a big piece of paper and start sketching and start thinking through all of the different what-ifs and maybes and to really push the forum of that until we could remove all the things that weren’t necessary and we could focus on what mattered.

We could get our thinking really, really clear. And so, we did that with these SDKs, also, where we realized that software is more or less invisible in that sense, but its form is its documentation. So we started out just sketching docs, just doing install guides, writing pseudo code for how to install and run this thing. Looking at all the different method names and functionalities people wanted and making sure it was consistent, you know?

It’s like if you, you don’t want the situation where if you use this method, it gives you a callback with these arguments, and if you use another one, it gives you a callback with different arguments, or maybe no callback with no explanation whatsoever.

So we wanted that consistency to become part of the vocabulary for how the thing functions. And by doing that, we came to a very, very clear spec of not only how the thing works, but how I use it. How I install it and run it and under what examples and situations. So we wrote a lot of example code. And all this was before we wrote a single line of code.

The beauty in that is once you have that perfect clear picture of what you’re building with good rationale for why it needs to exist, putting the code together, actually took no time at all.

Steve: Yeah, and it sounds like a lot of the code was already there and you figured out a really nice way to sensibly reorganize the documents and then you reorganized the code to fit that.

Dustin: Yeah, yep. So we started by designing our thinking and designing the conceptual form of it and then filled in the rest. And really wrote a lot of tests before we even wrote the code itself. So that really changed the way that I thought about making software. Where, now, if I ever catch myself getting stuck on something new, I realize it’s because I’m looking at a very granular level and kind of pinning myself into a corner, so stop, drop it, back up, and start writing out pseudo code and docs for it and then it makes sense.

You can follow the show on twitter @dontmakemecode and email Stephen and David at dmmc@heavybit.com to suggest a topic or guest for the show. You can also subscribe to all of our shows by copying this link into your favorite podcast app. Stay tuned for show-specific feeds!