Cognition Roundtable

• Blending traditional designer-developer roles
• How closer and earlier collaboration can benefit everyone—especially clients
• Where we’re finding inspiration in others’ open-source work

So pop on those headphones or take a read through the full transcript below. As always, let us know what you think about the roundtable format and if there are other topics you’d like to hear more about.

Cognition Roundtable 002 – Full Transcript

Greg Storey (GS): Hello, and welcome to another Happy Cog’s Cognition Roundtable. My name is Greg Storey and I’m the chief marketing officer of Happy Cog. Today I’m joined with Sophie Shepherd, a designer; Brandon Rosage, a developer here at Happy Cog; and Ryan Irelan, the VP of technology.

Today we’re going to talk about some of the problems that we’ve faced, kind of adding on what we talked about last time, so some of the challenges and how we’ve made some changes in our process. In particular, we’ll talk today about putting more of the development process and what we consider development into design, and some of the design exercises that we do.

Sophie, you want to start us off here? How do we get to or how do we define what the challenges are, and what got us to the point where we decided to make these changes in our development process?

Sophie Shepherd (SS): I think that responsive design made Photoshop pretty inefficient. We couldn’t design sites that would end up looking how they look on the Web. By necessity we had to move into the browser sooner.

GS: Is that because we were having to create too much design to show this is what your site looks like here, and here, and here?

SS: I think that was part of it. It doesn’t make sense to design a mobile site and a tablet-sized site, and a desktop site. Even if we did that, it’s not everything and it never really looks the same as it does in the browser. I think another thing, as a designer, you have to understand what’s happening in the browser. By understanding that, you can design the site a little better.

GS: Would you say moving away from Photoshop and moving more into these prototypes or more of a developed design artifact — how is that helping the client?

SS: I think that gets them talking earlier on about how people can really interact with the site. I think before their expectations were a little wrong. We were showing them all these design comps and they were signing off on them. Then the developer would be tied to these comps, and their only job was to make sure they could get their work, their development to look exactly like the comps. If it didn’t, then they were doing something wrong.

I think by getting into the browser earlier on, the client is understanding how to talk about the Web and they can test stuff on devices. It’s more true to how it’s going to be as an end product.

GS: Brandon, you’re the developer on our discussion here today. But as a developer who gets brought into this process towards the end, what’s that been like, to meet with Sophie who’s showing you here’s all these designs; is that providing you enough information to really wrap your head around the next step, which is turning design into code?

Brandon Rosage (BR): When the design was very Photoshop-centric, as Sophie was talking about, there was a certain amount of “intuit this”. Like here are some mockups and we’ve covered a lot of screen sizes, but there still inherently is always an implication that you get the idea. There’s all this unspoken stuff.

I think the last year has been a lot of trying to not be so presumptuous about things. And actually work together early on in the design process to get at least some of those questions worked out, even if it is just a prototype or hack version of it. So that it’s not just clear to the client and you’re getting those expectations set correctly, but also between us internally as a team. That we’re all building the exact same thing with the exact same assumptions.

Even today, I think no matter how perfect we get our process, we’re all kind of assuming we understand how things are supposed to be, how fast things are supposed to move, when there’s supposed to be shadow and when there’s not. It’s so hard to prescribe those in a PSD.

SS: I think something that’s changed both for designers and developers is that as we’re working, we need to know that things are going to change. As a designer, I don’t expect you to make something exactly as I’ve done it. But I think as a developer you also need to be working and thinking I might have to go back and edit this. And I think on both sides that flexibility is what makes this new type of process work.

GS: If we can for a minute, we go from design to template development and then Ryan, you’re here representing the backend, the CMS development. What’s that like for your world, once it gets this snowball mess to your doorstep?

Ryan Irlean (RI): The nice thing about doing it this way is that it doesn’t snowball as much, or at least we catch the snowball when it’s further up the hill, rather than down at the bottom. I would say the biggest impact on backend development, especially if we’re doing a CMS implementation, is that we get to see the content types and the page layouts. And we start to think about how would we structure this content in a database, or in a CMS, depending on what the implementation is.

That’s a really big thing.

It takes us from having to understand that out of paper wireframes or a site map, and into something that’s actually a living and breathing artifact for the project. I would say that’s the biggest one. We could also help identify issues ahead of time if there are going to be issues.

In the past, the designers would say if we did this, would that be possible to implement. We can still ask the same question, but with an artifact like an HTML wireframe or style guide, we can actually see it for real in the browser and then hopefully give a better, more informed answer.

SS: I think working in this process and working with backend developers from the beginning has surfaced a lot of design issues, which is nice as a designer. I’ll have a developer ask me questions like how is this going to work, and I’ll realize I haven’t really thought about that yet.

GS: We’ve awkwardly segued from here’s the challenges and issues we didn’t like about our process that was much more based on a waterfall process. Let’s talk about some of the changes that have been made for the better. What have we done to improve this, both for communicating and collaborating with our clients, and also for internal communication as well?

SS: I think the first change that we made to our process, to move in this direction, was prototypes. Getting rid of wireframes and moving more towards HTML in-the-browser prototypes. And I think even though it’s not all of our process, it completely changed our thinking about this stuff. Right from the beginning we were right in the browser.

First of all, designers are the ones who make the prototypes, so that got us used to working with code in the browser. I think that carried over into our design process. Once we’d done that in the browser and realized how much faster, easier, and how much more we got out of it, that carried over to the Photoshop design, and we started thinking how can we move that into the browser as well.

GS: Does this mean we’re creating as many full-page templates, mockups as we were in Photoshop or is there something here we’re also trying to improve upon when it comes to moving more of the development into design? Brandon, I know you’ve been working on this.

BR: I think the volume of how much content are we going to try to represent during the design process, I think that’s probably the same. I think where there’s maybe an increase in volume is in the amount of code we generate. I don’t know how you feel, but I feel like there was a time where there was an aversion to writing too much code. Let’s streamline that; only write what we need to. And wherever we need to play and experiment we’ll do that in Photoshop.

I think there’s been an increase in the amount of code we write. The prototypes aren’t production code. That’s stuff we know is going to get tossed, as it pertains to the website that gets launched. I think that means there’s a willingness for somebody in my role as a developer to build something I know is probably going to get changed and revised five times. And for that matter, to build six different versions of an article page. Or what that might look like.

SS: It’s a lot easier in the browser. I think to follow up on what Greg asked, which was are we doing more templates; I think the way we’re thinking about the site is completely different. In the past it would be okay, we’re going to do these four or five template page layouts that serve these four or five purposes. We’re not doing that anymore. We’re doing individual, small pieces of the site, and then layouts as a separate piece. I think from those combinations you can make a lot more layouts that we used to. Instead of doing pages, we’re doing an entire system that you can build an infinite amount of pages with.

GS: How’s that been working so far?

BR: This is one of the changes I think has impacted every person across the project. And by that I don’t just mean in this room, but the client too. Inevitably at the end of projects, when there is sort of a handoff and the client finds himself asking that question, like what do we do now, what are we going to do with this, there was a time where they might think we only have six templates. And we’ve got a lot more ideas.

By having these pieces and building blocks, and then some examples, and also some sort of education about how they can be put together, it creates even the sense, and the reality that there are a lot more than these six pages you’ve seen. There’s a lot of possibilities and room to grow, without the need to build a lot of new stuff.

SS: I think the education factor is what becomes the most important now, that maybe wasn’t in the past. How to use this stuff we’re delivering and how to look at the code we’ve written, the designs we’ve done, and how to put them together and expand upon them.

GS: This is no more Happy Cog, this is really prescribing every detail of a site experience, and how maybe everything is put together. We certainly do that to an extent but it sounds to me like we’re also empowering the client to take it from there, and move on.

BR: Absolutely. I think some of the growing pains in that is language. Even though we’re template/page, because we’re talking about a design system that is made up of smaller parts, what do you call those parts? And then even early on in the process, when you’re showing them and communicating with them the system, which of those do you focus on. I still feel that’s an open question.

Do we ultimately try to talk about templates — this is what the home page is going to look like, or do we try to really encourage them to think in those smaller ways: modules, fragments, whatever words we use, so there’s a shared language. And it’s much easier then, all throughout the process, to have a conversation about the reason that thing isn’t working is not because the page is broken, it’s because that piece needs treatment.

SS: I think it’s important to talk about it as the pieces, but I think it also can be very confusing for someone who doesn’t work in the Web and understand it. I know I’ve delivered small pieces to clients before and they’re like “Is this the whole page? Is this how it’s going to work?”

RI: The nice this is that by breaking these up into small pieces, we can still put them together and talk about them when needed, as pages.

SS: It’s easy for us to put them together.

RI: It’s fine, but we still have the flexibility of those small pieces. It’s great for the client if a company or if the client is doing the implementation of the front-end code, then it’s great for them. It’s also great internally for us because we have all these pieces.

I always talk about how in the old days, we used to get a full homepage template, or an article-page template, and then have to break that up and implement it. We’re essentially moving that much earlier in the process. So we’ve taken that task, it’s actually built into our whole project now. It comes from design and front-end code, and we don’t have to do that anymore. It’s already there, and that’s kind of a nice thing because we have to break that up eventually. It’s nice to have that much earlier in the process than we do now.

GS: It sounds to me like some of the efficiency here is taking out the deconstruction that used to happen between design and HTML or coding, and again having to deconstruct HTML into a CMS. With this, we’re not having to do that at all, or I would assume very minimal.

BR: There’s a lot less reverse engineering going on. I think too, one of the unintended but surprisingly awesome results of this as it pertains to communicating with the client is again speaking as a developer, there was always a bit of frustration that the clients, developers, or the people who cared about the technical aspect of it, weren’t engaged until very late in the process. That has problems in terms of getting their feedback on what is design-related stuff, because they’re not looking at the code.

But also, when you’ve broken it out so early and not just focused on pages, you have that to show them. They’re then engaged much earlier and more people on the client side are engaged and thinking about things throughout. The sort of pitfalls of the last week of the project and how come this font is that size — just stuff that should’ve been addressed a lot earlier, everybody has had their eyes on it the whole time.

SS: I think internally too, not only on the client side, but doing this — the backend developer is looking at our prototypes and thinking how these can become a CMS.

GS: Which – correct me if I’m wrong, but that’s also meant we can get started on content management or application development sooner.

RI: Yeah, absolutely. If you have these prototypes, you can start to see what the site is. If we’re building an application from scratch for a project, then one of the first things a developer will look at is how am I going to set up my database to store this content. How am I going to chunk up this content into a way that makes the most sense for retrieving and storing it? And by having a prototype, obviously things are going to change. There will be new decisions an updates, but we’ll be able to make those initial decisions. We’ve done that. We’ve been able to start with implementation to a CMS much earlier than before. We can stub-out some of the aspects of the CMS much earlier because we have an idea of what the pages look like.

SS: It’s easier to edit things you have done. It’s the same with front-end code. I had this on a recent project, where the backend developer had put it all together. All he had to do at the end was move the order of things around, but it was all there for him to edit. I think it’s the same thing for front-end code. You start that earlier. The design may change, but you’re just going to have to change it a bit. You’re not going to have to start over.

GS: Playing Devil’s advocate here, if it used to be let’s talk about design and we’ll get through that, and then we’re going to talk about development and HTML development, that kind of presentation layer; and then we’ll eventually talk about CMS development — to some extent on the client side and even for us, that allowed different people to kind of move in/move out, and engage/disengage. Just playing Devil’s advocate here, if all of a sudden there are designers and front-end developers and backend developers on both the Happy Cog side and client side, and if you’ve got all those people engaged at once, isn’t that making things confusing? Is this making for longer meetings or more arguments in conversations?

SS: It makes for more talking.

RI: A lot more arguments.

SS: There’s definitely more communication needed and more talking but I don’t think that’s a bad thing at all.

GS: Is a downside that there are more people involved in each meeting than before? It’s less segmented?

SS: I think there’s less in some ways, at least there are more people involved but they’re always the same people. If we’re talking about last meeting —

GS: Everybody knows what’s up.

BR: There are more cooks in the kitchen. I think there if you have five meetings a week, one of them feels overwhelming, and the rest work themselves out. To me, it’s been worth it to hear some really obscure or detailed thing come out really early, even it was sort of a non sequitur in that meeting, than to hear it at the very end. Or to make assumptions. Again, this kind of goes back to what we were talking about earlier with responsive design. It’s good, it’s worth it to talk about code, even though we’re totally in the wireframe phase, and talking about the implications of that, than even if it may feel like why am I thinking about this right now. At least that seed is planted and I think it improves the process all the way along.

SS: I’ve found a lot of what we do crosses over. I find myself doing more development, but I also think developers are having to do more design and make more decisions. I think that’s a cool thing. I like to have a developer give me design feedback based on how it’s going to work or not. I think that having those conversations makes for a better end product.

GS: Happy Cog is certainly not the only group who’s moving into this. And trying it out, testing the waters, iterating to get this defined, so that it’s a well-oiled machine. Who else are you talking with or who’s out there inspiring these changes, people that listeners should also check out?

BR: On the last few projects I’ve been involved with here at Happy Cog, a lot of the inspiration that I’ve taken into how we’ve managed these projects comes from this pattern library that Brad Frost and a team of other guys have put together and open sourced. And I’ve iterated on it a bit, in the sense that their pattern library is a code repository. It’s intended — I don’t know if it’s still based in PHP, but it’s intended to be this mini application that you can set up and develop in, so that all these building blocks that we design and build can be presented to the client in a way that matches the thinking behind it. They’re organized into categories and you can see them just as modules, or you can see them in the context of other things.

We’ve built our own version of that, that works for the delivery of our stuff. I think the iteration there is to draw connections for us between those deliveries and the date that we delivered them, so there’s sort of that time element. And I think a little bit more connection also between the patterns and their genesis in Photoshop, so there’s also the image assets and wireframes. It’s all kind of baked in, so it’s a bit of a spin, and maybe a more ambitious version of that, but the kind of stuff that Brad Frost and those guys are doing has been a really big inspiration to what we’re iterating on here.

SS: I think to add on to what Brandon said, this is another Brad Frost thing, but also Sparkbox has been doing it. They make these things called “content prototypes” so we do prototypes, but they have layouts. We’ll often use a framework so there’s a bit of design there, even if it’s not something we’ve put in. There’s a button style or list style, and I think clients often get a bit confused by seeing these when they see the layouts and see that they have some design applied to them. They’re not sure how these are going to evolve into their website.

The content prototypes are just listing exactly what’s going to be on the page, with no layout, no style applied. So, it’s basically just an HTML document. I think this is really interesting because backend developers can then look at this and see connections between different pages, and how it can be implemented. Clients can talk about the content on the site without being distracted by anything. And it can also start to become something you add design to.

RI: I like that. Getting back to my comment about stubbing out pages, is that we did this I think last year, for the MTV O Music Awards is sort of stubbed out some pages, coded them on the backend with functionality but the design wasn’t ready yet. So just kind of outputted what we thought was going to be on the page. This is almost similar to that because it’s just the content. You could actually output that content onto the page, and then come back later and know that you have all the functions written that you need to have that outputted. And you have any other considerations, field trade, whatever you need, and you can come back later when things are done and drop that in. And you basically have done that legwork already, much earlier in the project. You mentioned Sparkbox probably delivers this pretty early in the project?

SS: I think it’s one of the first things. I think it’s almost like the yin-yang of pattern library. You have this thing, which is the content, with absolutely no styles. And if you’re doing the pattern library separately and you merge them, then that’s your site. Those are the two pieces that you need.

BR: I’d imagine that would help later, when you bring that content to life with a design around it, that it helps in those discussions around what if we added this, that, and the other thing. You could say we already have decided what the core purpose of this is.

SS: Yeah, this is what we want to say without any distractions on top of it.

GS: How long have we been doing this? I know it’s been at least a couple months, but when can we come back and talk more, revisit everything we’ve talked about here today, and talk about what’s worked and what are we iterating on, and what are we improving from here?

SS: I think it’s changing every time we do something. We could come back in a week or two years and have stuff to say.

RI: I’d say we’re working on a pretty large project that Brandon is a part of, where we’re going to be using the pattern library. I think that’s going to be a good testing ground for a lot of these ideas, to see how they work with multiple stakeholders, that are all interested in different parts of the site. And an outside development team, and see how that all comes together. I agree with Sophie. We’re kind of building it as we go but that’s really the best way to do it.

BR: I think these processes — talking about the pattern library, something we built as an internal product, and that has a very wide-open vision. It will evolve, depending on what each project needs, and we’ll all contribute to it. I feel like in the next four to five months, especially the project you mentioned, that it’s very collaborative. A lot of the implementation is going to be on the client side as much as it is on ours. It’s going to be interesting to see how that as a communication vehicle, all the way along, succeeds or doesn’t.

GS: We’ll talk later this year and share with everybody how this has been going thus far, and how the big project you mentioned Ryan, has been going. We’ll see how it went. Thank you everybody.

Alison Harshbarger: This has been Happy Cog’s Cognition Roundtable. Thanks for listening. Be sure to follow us each week here on Cognition and on Twitter, @happycog.

Back to Top