This is the transcript for The Dirt episode, Designing and Developing from the Middle
Steve: If your face was relatively normal and it was just your ears, I would say your ears are fucking weird.
Tim: Hello, welcome to The Dirt, a show about experience design. I’m Tim Wright. Today I am here with Mark Grambo.
Mark: Hello Tim.
Tim: Hello Mark.
Tim: And I’m also here with Steve Hickey.
Tim: Hi Steve.
Mark: You know we were having a nice, calm like lake Wabagon NPR style show here.
Steve: That’s definitely not what we are doing.
Tim: I like to try and soothe the listener with my voice.
Mark: We want the show to be auditory green tea.
Steve: Tim, that’s bad news for you if you are looking to soothe the people. You probably shouldn’t rely on your voice.
Tim: I have a very soothing voice you son of a bitch.
Steve: You have a voice made for silent movies.
Tim: That’s hurtful.
Mark: Alright. Thanks for listening. So this week we kind of an interesting topic to talk about. We want to talk about designing and developing from the middle. What does that mean Steve? Catch us up.
Steve: From the middle. It’s you don’t get to start from the ground up and do everything awesome and cool-like. Though in the ideal way that you want to do it all. Instead you are inheriting somebody else’s system. That is the more common way we end up designing and develop things. I think we get what somebody has already done and our job is to build on top of it or modify it. It is not to start from scratch.
Tim: Yeah we do — we do have some things where we can start from scratch but especially from a development standpoint the-the chance that we will get to work in our optimal development environment is near zero because you know there are client hand-offs and we want to make sure that the-the designs already experiences that we design and build fit well into the system, the client’s system.
Steve: Yeah, this can happen in some cases where we are fixing something. They say hey we’ve had this product and it’s just not converting you know and so we have brand and we want — we know that the site is not functioning right so clean it up and re-design it but don’t our lose our colors, don’t lose the style that we’ve had, don’t lose the aesthetic we’ve had or yes you can go from scratch you have you know all the leeway in the world however this still need to connects to our other app which is doing fine so technologically speaking you still need to use some certain bit of tech.
Tim: It can affect the-the user flows to a certain extent if they have flow in place we have a project right now that there is a pretty lockdown flow in place and we really can’t change which we love to change or modify slightly but just not-not — we are not capable of doing that so you have to kind of do the best you can and use best practices.
Mark: Yeah, I think you also seem to be running into the problem more and more the larger our clients we get. We are talking about here is baggage essentially. How to deal with baggage.
Steve: So-so what do you think is a nice first step you know if you are trying to identify a way forward?
Mark: Well I think it’s different if were talking about brand baggage versus [inaudible 00:03:04] baggage. With [inaudible 00:03:06] can be kind of locked down depending on who you are dealing with what those requirements are so we can’t walk in and say well you know your into entire twenty years of legacy software is built on PHP but we would really like to move over to Ruby on Rails. That would be super cool because Ruby on Rail is so hot right now.
Tim: The statement kind of doesn’t make sense but okay.
Mark: Oh okay I know PHP is to Ruby not to Ruby on Rails but whatever bear with me.
Tim: But yeah I think the very first thing you need to do is make an inventory whether you’re doing you know it’s a brand locked down or it’s development lockdown. It is okay what do I have to work with? What are my limitations?
Mark: Yeah, so or like a brand baggage for example. You got a logo. You can generally not mess with the logo and that’s even something we don’t really do anyways even if it was an option. We wouldn’t be messing with an underlying identity. You’ve got a set of colors, you’ve probably got some type of typography so you catalog all that stuff and then you start pushing, you start poking at people that are supposed to be the brand guardians to see what can actually be changed. I find a lot of times that the people protecting the brand – there probably a little over zealous. You might have changes to recommend aren’t really against the brand in any way. They are just different from the way people have done it in the past and you really have to be persuasive when you — when it comes down to it.
Steve: I think also it plays into something we’ve talked about before which is the client relationship is often just like an interpersonal relationship or a romantic relationship this is you know a give and take and people get very attached to things and you don’t want to just go in there and blazing and knock everyone down. It’s about respect and listening to the other team. The person defending it may be defending it because we always do it this way or you might be talking to — you might not know it at the time but you might be talking to the other person who spear headed that branding decision five years ago who found the company who did the branding. They were the ones who did the re-branding.
Mark: We-we worked with internal designers before and been on the other side of the equation. It’s-it’s a tough relationship to have I think. What we try to do if that comes up — when we go in there and we try to — the internal designers are allies because I think there’s this perception that when you hire contractors it’s because the people in charge don’t trust the internal designers and you don’t want the internal contractors to come in and run rough shot over everything. We want them to be our friends, we want them to help us, and for them to feel like they are as big a part of the process as we are. And putting them on your side is a huge part of overcoming some of this baggage.
Tim: And I think it’s a matter of also picking your battles. Although as you figure out what you have to work with and you know through this process we have been talking about you determine what cannot change and what has some flexibility and what’s wide open. It– you know there is something there that is on the fence. It’s not necessary — you know you don’t necessarily want to push against every single thing that’s on a fence. You are trying to build a strong relationship and build something that is going to work for your users so you can pick your battles and more often than not if let’s say they’ve got ten big things that you really think they need to change but you realizing it’s not going to be a realistic thing within the client relationship. Maybe if you can focus on the really big leading things you want to be able to change if that goes over very well you may have buyoff to, the relationship may be strong and you may be able to work it on down the road as well. Revisit it.
Steve: Well you know in the past we’ve had things that we recommend be changed and it might not be within the capabilities right now but we can still help them in the future. Say if they are — I don’t know they have some branding guideline that is not great but they are not able to do a re-brand currently. We can still say — within your guidelines here’s what we can do now but we also recommend that at some point in the future you move over however five or ten years down the line, whatever it takes. You know migrate over to this — to this other solution even though we know you can’t do it right now.
Mark: No, I think — I think these kinds of projects. It’s the majority of projects, it is one way or another but these are the ones where the interpersonal relationship level of the client and designer, the client-consultant relationship really matters.
Steve: Building trust.
Mark: Building trust, exactly. I would also argue though that this kind of trouble or baggage or this kind of decision can happen in any kind of project in fact including some that is from scratch. If you are building a whole new IOS, brand new Android app, you still have to wonder what is your decision going to be in terms of am I going to use the design standards, the UI kit, the visual kit out of the box provided by Apple, by Google, by Microsoft or am I going to go introduce some crazy new visual way of doing things. Some new gesture system or whatever it might be and you have to ride that line because if you stick too close, it may make things a little easier, may reduce development costs, and you may make something that fits right in. On the other hand, you run the risk of visually at the very least getting lost in the frame, right? There’s nothing really to stand you out. If you go too far in the other direction, you re-invent the wheel, it may not feel like an IOS app. It may not feel like an Android app. It might be considered at home. People might just think it feels strange and not be attracted to it or it might be difficult to use. So-so I think these kind of decisions really can get at any level of project depending on the way you look at it.
Tim: What about from [inaudible 00:08:16] side?
Mark: What about it?
Tim: Tell me about — tell me about some baggage.
Mark: Oh there’s just you know I mean like-like we mentioned earlier like the legacy systems you just need to deal with. We’ve had clients come in and say we want to use Bootstrap even if it’s from scratch or they are even using Bootstrap for a long time and then we have t figure out a way to get Bootstrap to work in a you know — it effects the design at some points.
Tim: You can almost spend so much time overwriting Bootstrap that it wasn’t worth using in the first place.
Mark: Exactly and that’s-that’s usually the conversation we usually have with Bootstrap. If someone has used Bootstrap from the beginning and as you know our-our when was in our interactions are usually so accustom that fine we have to overwrite the entire framework and it’s really not worth it. It actually damages the experience but there are cases we’ve had lines that are already locked in the systems and we just have to work with it.
Steve: They might be using WordPress for example. Even though they don’t really need it. Let’s say they don’t need the CMS parts, they don’t need a blog but it’s just the guy, the person who they had to build it originally was a WordPress person and they got it in WordPress because it just made sense them. That might not be the right decision. I think upfront when you are building trust and when you are building a relationship, it’s important to ask the questions not to sound like a snotty little kid but to say why, why, why? But they are saying…
Tim: Five why’s.
Steve: Yeah but if they are saying we need to use this, we need to use this. It is your role as a consultant to say well why do you need to use that either to challenge that assertion to say well you think you need to use it for X, Y, Z but in fact it’s more than what you need or to get to the answer that why now I understand where you’re coming from. Like I understand your internal politics, I understand your technological history, you know.
Tim: Everybody needs to get on the same page. It’s-it’s really important. A lot of people see these things as constraints and I think maybe constraints in the [inaudible 00:10:12] world are not constraints, it’s just called being in the real design integrity.
Steve: It’s structure, it’s structure.
Tim: Yeah this is just — this is you are never going to be in your optimal thing. You are never going to be in a project that’s one hundred percent your way and you work on a team, that’s — we are not freelancing and if you are in — unless you are building your own product then you can do everything you want.
Mark: And I have to say as a designer and work a few years ago doing free lance illustration. And two, I don’t actually even know if having no constraints is my perfect world. I like constraints as a designer.
Tim: Constraints are hell design. Imagine — imagine if you started a project and there was wonderfully tabbed interface and then you present it with client and said can’t use tabs period but it was like the perfect solution. That’s-that’s like my dream.
Tim: I love that shit.
Mark: Because you-you actually enjoy somebody crushing your world with a problem that you have to go back and solve.
Tim: Some of the times when I — when I used to get bored on projects. There would be something that would be very obviously solved by a normal design pattern like tabs but I would say you know what I’m taking it off the table. I’m not using tabs. We are going to find a different way to do this and it’s going to be awesome.
Mark: I think that’s a worthwhile self constraint.
Tim: Self constraining yourself almost.
Mark: Well I think there’s some — I don’t know if I agree with that fully but I think there’s value in-in building limitations at the former building process, try and challenge yourself. I think sometime it’s easy to go to the first solution for something.
Tim: You just give up.
Mark: Yeah. Or-or you are either just like oh yeah sure let’s do that. You don’t question why am I using tabs, why am I using..
Tim: Mottle windows.
Mark: Mottle windows are actually a perfect example.
Tim: Mottle was on of the first times I actually did that was with mottles.
Mark: Mottles and carousels I think are the perfect example because it is the default — oh I can just put in a carousel, oh I can just put in a mottle.
Steve: Can you start the mottle movement?
Tim: I hate it. I’ve been trying to do that for years mostly.
Steve: Make it a thing though like you can’t just walk around and say well here’s mottles. That doesn’t make it a thing like you need a campaign and a website and t-shirts and mascot.
Mark: Mottles have a purpose.
Tim: Hashtag no mottle apps
Steve: They do have their purpose but you have to know the constraint
Tim: Hashtag dust the mottles. Hashtag no no mottles.
Steve: Oh God. No, no.
Tim: Yeah do it internet. Go for it. Thralls of listeners, go.
Mark: This is the-the….
Steve: Thralls? Do you mean throngs?
Steve: Yeah that’s the world.
Tim: Throngs of listeners. Go. This is designing from the middle concept that you know we-we just don’t always get the luxury of starting from zero. Yup so it’s always good you know I mean sometimes it’s good to start from the middle. I like it.
Steve: So are we all in agreement? Is that cool?
Steve: That’s also strange.
Tim: When this is done recording, I will club one of you to make up for it.
Steve: Sounds good.
Mark: We have two events to announce. They are first….
Tim: Announce? First time ever. First time ever. On previous episodes.
Steve: We have ten registration forms left for Global Necessity Awareness. It’s on May 15th here in Watertown. You can register at FSTS. GOHDA. If you are not in the Boston area, there are events all over the world – Detroit, LA, San Francisco, there’s a few in Australia – I seem that you are all near each other.
Tim: That’s right, that’s right. It’s the size of Rhode Island. There are tons of events for global accessibility Wednesday check them at Google Accessiblity Thursday dot org and also come to ours if you are in the area. Steve and I will be speaking in Vegas at feature insight live. We have a coupon code.
Steve: Oh God. We didn’t write your guy down.
Mark: It’s totally in front of us. I’ll take it. I’m going to be the difference.
Tim: No, I found it. I found it. The coupon code is FILSPEAK15.
Mark: Yeah I know I’m sorry.
Tim: Oh my gosh.
Mark: My short term memory is just awful. If you want fifteen percent off of feature insights live use coupon code FILSPEAK15. We are also running a little bit of raffle for the 50% off which will see you over five dollars on the ticket. I think that if a raffle — five hundred bucks.
Tim: So send us a tweet at the dirt show.
Mark: Do your best tweet.
Tim: The best tweet you have and we will then fairly pick a winner. Probably in the next week or two.
Mark: Yeah we will announce that.