Audio: Cognition Roundtable

If you consider yourself a speed reader or just can’t imagine turning off Rdio, we’ve also included a transcript of the conversation below. Like this roundtable format? Comment or tweet us with what you think, topics you’re interested in, and let us know what you’re currently tackling.

Happy Cog Cognition Roundtable 001

Greg Storey (GS): Hi, welcome to Happy Cog’s Cognition Roundtable. My name is Greg Storey and I am president of Happy Cog. Today I’m joined by the vice presidents of project management, design, and technology. They are Brett Harned, Chris Cashdollar, and Ryan Irelan.

Today we’re going to talk about some things that we learned in 2013 and how that affected our process for making websites. And then we’ll further talk about how we’re going to take what we learned last year and improve what we’re doing this year.

So, first I’ll ask Chris what do you think was the most fundamental thing that we changed up in 2013?

Chris Cashdollar (CC): There was a big one. There was actually a pretty big change in how we tackle some of the early design thinking in our process. The biggest of that was with the mass proliferation of responsive design; we needed to be a little faster and a little smarter in terms of how we started to create the artifacts that determined the overall user experience.

So what we found was that we needed to be more efficient in the way we were creating these documents. That led us to exploring the idea of what HTML wireframes could actually give us, and allowed us to actually start baking some of the responsive thinking into these artifacts much earlier in the process.

GS: How did that affect both on the team side their ability to go from drawing on paper sketching, OmniGraffle, to thinking HTML prototypes? It’s the designers who are the ones tasked with this, from what I could see.

CC: Correct, and for the team and for the designers that are creating these, this is a pretty big task. Many of our staff has come from the traditional let’s draft this in OmniGraffle or in Illustrator and then create page after page of state and variation and piecing these experiences together with paper, essentially.

Their process starts still very much in the same way with ideation, sketching, something very lo-fi. Ideas obviously are the currency we want them using. But instead of then taking these ideas and translating into what I sometimes call dead artifacts, something that really doesn’t have a life beyond the creation of it, let’s create something that has more permanence, and can do a better job of educating downstream, not only in our internal teams, but the client side as well.

We had to hit pause and say what do we need to do to get our staff trained up and prepared to actually start being able to create these. That took a lot of effort and took a bit of patience. We even relied on our own training courses that came out of Mijingo, The Happy Cog Way, and we were able to kind of put together a little taskforce internally to make sure we were setting up our teams and designers for success, to provide what they needed to know to actually start creating these.

GS: How long was this transition and was it just from the design side, or Ryan, was technology—how was your group involved in this?

Ryan Irelan (RI): The development team was involved in terms of some of the technical setup that it took to get up and running with the tools that they need for HTML wireframes. Chris referred to the Happy Cog Way, the course that Patrick Marsceill did on HTML prototyping and wireframing. And we’re using some tools that required a bit of technical setup.

So the dev team was there to support and to help train, but I think Patrick Marsceill was the one that with his video and his expertise sort of led that and then taught one person. Then you could see in the office, as one person was learning, someone that already knew would then help them as sort of this snowball effect. I think now a large chunk if not everybody on the design team, Chris, is trained or has started training on HTML wireframing.

CC: That’s correct.

RI: Which is really cool. The great thing about this for the development team is it now gives the developers and designers this common thing they can talk about and discuss. It’s very familiar to the developers because it’s all HTML and CSS. And it works in a browser, so they can wrap their heads around that, and they can see it move, can interact with it, and they can understand where there might be some questions they have for functionality or interaction. It’s also for the designers because they can very quickly iterate on it and make decisions, respond to client feedback.

What we’ve seen is some developers jump in and start doing some wireframing as well, but the most important outcome out of this has been the partnership between the designer and developers on their teams, working together on these deliverables. It’s no longer just a design deliverable that a developer gets sort of thrown over the wall to them. This is like a living and breathing thing we go back and update. And it’s not this dead document anymore. It’s been a fantastic improvement for us over the last year.

GS: Good. That’s on the Happy Cog internal side. Brett, what are you seeing with the difference between clients receiving paper-based wireframes versus some kind of responsive artifact in the browser?

Brett Harned (BH): First I’d say the response has been great because it facilitates a discussion much earlier on in the process. We can actually show clients a living, breathing prototype of what a page or part of the site might look like. That gets them thinking more about responsive states and how things are actually going to act much earlier on, rather than looking at a paper PDF.

I would say that we’re not necessarily doing HTML wireframes for every single project. We’re definitely making assessments based on what our clients need, how our client stakeholders might react to certain deliverables into account before we actually prescribe we’re going to go straight ahead into an HTML wireframe.

We want to make sure we’re collaborating with our clients on a level where they can actually understand what the process is and how we might take an HTML wireframe or prototype and turn it into a design, and how that’s going to affect their content. Content’s a really big thing here too. It gets our clients thinking about content much earlier, which is good for us. We all know that ends up being a delay in some projects, when some clients aren’t ready to rewrite content. But when they start to see things in a state that feels like it’s living and breathing, it makes them want to act on it much sooner. That’s been really awesome to see.

GS: Have you seen where we’re getting more people on the client side responding to that earlier work than paper-based wireframes?

BH: I can’t say for sure, just because it depends on the client. But I like to think that the presentation of a prototype and what a client walks away with is much more interesting than a PDF deck of wireframes. They can actually sit down at their desk and play with it, critique it, and think a bit more critically about content and hierarchy. And also thinking about the different states: iPad, iPhone size, that type of thing. I think in that respect, it’s been pretty helpful in gaining more stakeholder feedback, and at least attention.

GS: With that attention, have any clients in the past looked at the prototypes and mistook that as stage one of their actual website? They look at this and say this is great so let’s just color this in and call it a day.

BH: I think the one thing our team at Happy Cog is really good at is educating our clients about our process. That’s never really mistaken, though it could be. We definitely talk about the process of taking this HTML wireframe and evolving it into a graphic design, and then actually coding those pages. The prototypes we’re presenting aren’t necessarily the website or templates that our clients are going to get at the end of the project.
Ryan: We don’t use the HTML wireframes as a basis for a final production code. All of that code is written from scratch during the development phase. Ideally, we thought about that and tried it.

CC: I was going to say we tried that once.

RI: And what happened was it really put so much of a burden on this wireframing process, to where it was no longer about quick iterations and getting ideas out and responding to feedback. It became like oh we have to do this in a way to where it’s still markup we would consider production ready, up to standard. When you let that go and realize this is just a deliverable, it makes that process much easier. We’re still writing all of our frontend code during development stage.

One of the things we can do and have started to experiment with is move the beginning of development a bit earlier because now you can start to see hierarchy in the grid, and you can start to make some of those foundational decisions that you would in your markup a bit earlier in the process. That’s still something that we’re still playing around with a little bit.

Stephen Caver, one of our developers, is a big proponent of that, of trying to move the beginning of development even a little bit earlier. And so we’re further eliminating the typical waterfall process, where it’s just dumping down from one discipline to the next.
Greg: Earlier, it was mentioned that developers are working with designers earlier on prototypes. Chris, does that mean that developers are actually designing or how does that work out?

CC: Good question. One of the things we like to say here is that everyone can contribute and when you have a designer and developer and also a content strategist too, working a bit more in harmony earlier in the process, you’re going to come out with better ideas, a bit more baked, a bit more cohesive, a bit more considered. That’s what we’re finding.

We’re finding we’re able to see those sparks happening between the trio of roles, so that the effort that’s put together for these prototypes is a bit more real. Ultimately, gets the job done faster, whereas each one of those disciplines would have to come up with their own idea and then vet that idea with the other roles who need to chime in.

Another thing we’re finding, and this is extremely valuable to the design process; when we create these HTML wireframe and we can iterate on them quickly, we actually hypothesize design thinking, and get users to actually test. So we don’t have to wait.

GS: You don’t have to wait until the end.

CC: Correct, and we can come up with an idea that we think solves a problem, and then we put that through the ringer for user testing, and then make a determination whether or not it makes the cut.

RI: Doing these interactive wireframes isn’t really new for user testing but the difference here is we’re using web-standard technology, HTML CSS. It’s not like a proprietary system. We do learn on Zurb Foundation a lot for the framework for building things up. But it’s just HTML and CSS. That’s core to what we do and so almost anyone on the team, from you to me to Stephen and most of the designers can just get in and create these wireframes. I think that’s really where the power is.

GS: Nice. Moving on from the prototypes, one of the changes I think I’ve seen, and Chris mentioned this to me the other day, is our shift moving away from full-fledge templates, where we may in the past have said here’s your 8 to 12 to 14 templates. Use these to create all of your website. Now, our focus is more on a modular system, a design system. Chris, I’m not going to be able to go into detail. Can you kick us off here?

CC: Sure, the system I think is much more powerful than the page. That doesn’t exclude us from having to get the basics right. We still need to actually consider what is the underlying structure, what is the range of core page types that need to make up the design system. Then from there we start to think about how can we keep styles and content more modular, more malleable, so that we’re creating the Lego blocks, per se, of the design system, that not only make up the work we’re going to be doing that we’re going to create for our clients, but it allows the client then ultimately to maintain and grow that system long-term.

I think, Ryan, I’ve heard this term used coming out of your team where it’s not necessarily templates anymore, it’s a frontend framework. Something about that I really like because we want people to stop thinking about here’s your five pages. That’s not really a website anymore. It’s all the pieces that make up these. It’s the interactions between states. The beauty of the web is it’s more than just what you’re seeing in a static page. It’s the interaction with it.

GS: How has this deliverable type had an impact on clients and I think their ability to perceive what they’re looking at, because not everybody is able to look at pieces and see the entire puzzle. I would imagine that’s a challenge, Brett for you and your team, when you’re delivering this kind of work. What’s the impact been and how much more education have you found that we’ve needed to do in order to make this change?

BH: I think Chris and Ryan would agree this is definitely an educational deliverable. We’re kind of setting our clients up to succeed beyond our engagement with them. Essentially when we deliver a pattern library and style guide, we’re giving them the building blocks to continue the site out when we leave the room. And the site’s up to them to maintain.

One of the things we definitely run into with clients every once in a while is the in-house ability to do some of that. Again, we’re working with our client teams and making sure that the deliverable is suitable for them, that they understand what we’re doing, and what they need to do in order to keep the site living and keep the lights on after we’re there.

GS: Are there additional deliverables we hand off to the client to teach them how to use this in perpetuity?

BH: One of the cool things the team has been doing is making videos of some of this stuff, to show them how it works and how they might work. That’s been helpful in the review process, to let not just our main client contact understand what we’re presenting, but also to share that around an organization for the people who might not be able to be in a meeting, or maybe for people who joined the team later on, who might have to keep the site going; that kind of plays into that educational aspect of it.

RI: We will assemble modules into some templates to demonstrate how that works. In the past, before we did it this way, we would create some large templates that displayed a bunch of different styles, like a general styles template. But this approach allows us to document it.

What I really like about this is that we didn’t say we want to create a style guide, and to do that we need to be more modular about how we code. We said we want to be more modular about how we code, and a natural byproduct of that is now we can actually start documenting these modules. Now we have the style guide or this pattern library.

At the beginning, Brandon Rosage said he was throwing snippets into an Evernote notebook as a way to categorize, then take screenshots of it, and place the associated code with it. Like a lot of things that we’ve had success with over the last year has been an experiment. One of two people have tried something, demo’d it to the team. Brandon did a demo to the whole development team of what he was doing on a project, and everyone said that’s cool. It sort of ignited and took off from there.

That’s what I really like about this. It was informed by a better approach to code, and thereby the client now has a better tool they can use to implement. Some of the projects that we do are not full implementation projects. We don’t do all the backend development.

That’s where this is key because we can then hand this off and we have some time set aside where we can work with the client’s development team, whether that’s in-house or another company. And they have this guide we’ve built, so they know exactly what our intention was with where to use the modules, how they can be coded, what your options are for coding them. Maybe different class names to give variations to those modules.

It’s an education deliverable but it’s a great document. Again, we could come back, if there’s a redesign of the site, we could come back and update that document. Or if they work with someone else, that person could update that document.

GS: I have to imagine for those teams that have to implement the work that we do, we’ve reduced stress and anxiety.

RI: Yeah, because they don’t have to then reverse engineer someone’s templates. We’re already doing that for them. We’re already breaking it apart and showing the system, and showing them how it makes sense together. They don’t have to do that anymore.

I know from experience as a developer you get someone’s static templates, and have to figure out how this is going to be best chunked up into the most reasonable piece as possible. We’ve done that already.

GS: We’ve talked about some of the changes we’ve made for the better in the last year. What are we doing moving forward? How are we taking what we learned, both with prototypes and with design systems, and how are we moving forward in 2014? Chris, is there just more finesse or is there more big thinking, based upon what we’ve learned?

CC: Some of this modularization of content and this breaking it down that Ryan suggested, we’re starting to hear some of that back from our current clients and potential clients to be. We know there’s definitely traction on their side with thinking that’s great to hear coming back from us. What we’re trying to do now is start having this discussion about the style guide, about the pattern library much earlier in the process.

We’re starting to think about how we can implement it, but we’re also listening. We’re asking our clients how can this help you so that we can tailor deliverable to their needs and their team’s needs, to ensure we’re giving them something they will use. We hope they will use it, but we want to make sure they actually do.

We have a varying range of what form this takes, but in most cases, when we’re going to leave it behind and we want it to be as powerful as possible; it’s a visual guide and also kind of a living, breathing example of how this code reacts. It’s almost like an inception of a style guide. You have the pattern in there; you have the example of code showing you what’s actually making up the pattern. But the actual style guide itself is responding to the browser width, so it’s a living, breathing example, in addition to just being a visual example of what we hope happens once we’re out of a project.

GS: Brett, how’s that going to have an impact on how we manage projects, but I think more importantly, how we manage post our involvement, or beyond our deliverable?
Brett: I think as far as the way we’re managing projects, I think like Chris said; we’re experimenting with some clients who are open to that, and don’t necessarily see the experimentation as much as we do internally.

I think the team has been handling it very well. I think we’re able to get to decisions earlier, which is making for a quicker, smoother process. It’s also making the process much more collaborative, not just internally with our teams, and getting to ideas faster, but also with our clients. We’re using prototypes, style guide, and pattern libraries in a way that we’re actually opening a dialog on things sooner on projects than we would have in a waterfall process.

I wouldn’t say we’re going Agile. That’s definitely not where we are, but we’re definitely getting to decisions faster and it’s in a comfortable, really collaborative way with our clients. That’s been great.

I think in terms of post engagement, I think clients still love working with us and hanging on as long as they can, and we love that too. We want those decisions to be made and we want to be a part of those decisions. But I think they’re starting to feel more comfortable when we step away, knowing we’ve given them the tools to really continue to maintain and build their site, and keep it high quality.

GS: That seems to me not just tools, but an education as well. It’s a new thinking that they can implement on the inside.

BH: Yeah, absolutely.

GS: Ryan, what about you? How is this going to affect development in 2014?

RI: I think the same way it did in 2013, which is going to make development much more efficient. I think we’re only going to improve that. I would say what we’ve done so far with the HTML wireframing and style guide, is I want to see us refine that and improve it. That’s sort of what we’re doing with each project.

We’ve tested both of these against some pretty big projects and it worked out really well. But on the development team, the developers really like to improve process and streamline things, and they’re always looking to try to refine. I think that’s what it’s going to be about for these two pieces of the puzzle for our projects.

GS: Fantastic. I assume any changes we make, anything we find, we’re going to be sharing with the community either through Cognition, through Twitter, or whatever that might be.

RI: Absolutely.

GS: Thank you both for your time. Let’s check in, in six months, and see how this is going. We’ll let you keep us up to date on how things are going with design and development at Happy Cog, and where we’re going from there.

Back to Top