Episode 170 of The SitePoint Podcast is now available! This week our regular interview host Louis Simoneau (@rssaddict) interviews Wolf Becvar (@wdbecvar) the COO of HotGloo to talk about Interactive Wireframes and how HotGloo was developed for this job, and where it will go next.
Download this Episode
You can download this episode as a standalone MP3 file. Here’s the link:
SitePoint Podcast #170: Interactive Wireframing with Wolf Becvar of HotGloo(MP3, 24:40, 23.7MB)
Episode Summary
Louis and Wolf discuss the reasons and benefits in terms of aspects like copy and micro-copy of Interactive Wireframing over jumping into design first, or starting in HTML5 prototyping.
Browse the full list of links referenced in the show at http://delicious.com/sitepointpodcast/170.
Interview Transcript
Louis: Hello, and welcome to another episode of the SitePoint podcast. With me on the show today, I have Wolf Becvar. Hi, Wolf.
Wolf: Hi.
Louis: Wolf is the COO of a company called HotGloo, which is sort of this online tool for interactive prototyping. For anyone who builds websites or software, just to sort of sketch out the types of interactions that’ll go into each page before actually launching into full on design.
I thought it’d be great to have you on to talk a little bit about just the role of UX design and wireframes and prototyping in web design, because it’s not something we cover a lot on the show. I just recently started using HotGloo, and I really like the tool, so I figured who better to have on to talk about this stuff?
Wolf: Well, thanks a lot for inviting me. When we started, now three years ago, in 2009, we saw a need in a tool like we built back then. Hannes and myself, Hannes is the CEO and the CTO, we were working at an interactive media agency. He was a developer there, and I was doing project management, I was doing concept stuff.
We were realizing that a lot of our workflow was based on – we were getting into a client meeting. We were writing down specifications. We had our layouts basically of what the client’s idea was of his future website.
What was happening back then was that actually the designers would jump straight in, fire up Photoshop, and would start to design right away. Back then, there was this kind of idea flowing over that we were then jumping on to say, “Well, that’s not the right way to do it. We actually should think about whole site structure, information architecture first. Then after all these processes have been laid out and are being discussed with the client, then we actually should jump in and do the design.”
That was the basic idea for HotGloo back then. What also was very important for us when we started out was that this whole process is actually a really collaborative process. It’s not that in your whole team of 45 people in an agency, everybody’s working independently and one is doing only the design, the other’s doing only the development.
Of course there are these specialized roles within a team, but for us it was really important that everybody on the team was on the same page. Then, when we started out, that actually someone who started doing wireframes would have the designer, the developer, you know, surely every second day looking on the project and bringing in his thoughts and sharing the ideas.
At an earlier point of the project, everybody in the team would know where the project would head to. You’d have the client come in again. You would show them, first rough sketches, the first wireframes. He can click himself through. He can experience his site before even anything is being designed or developed.
So, we realized that this whole process is, first of all, an iterative process for us. The outcome is getting better and better. For the client, it’s easier because he’s been on board from day one, and you actually can show him his work in progress in small bites and small steps along the way. Before it was he would come in, have this briefing and two, three weeks later he’d come back in and we would present him design files. Then, there would be big arguments about color and stuff.
Louis: Right.
Wolf: First of all, getting projects done faster, everyone is on the same page. This whole iterative process has really helped us making better stuff.
Louis: Yeah, absolutely. We’ve just sort of tried to move our development. I work on flippa.com, and we’ve sort of moved our development a little bit more into that model, where sort of everybody can contribute. That’s one of the reasons why I’ve started using HotGloo to work on prototypes, is simply because my role traditionally in the team, I’m a back-end developer. I do Ruby on Rails.
But being able to start working on products and have an idea of what they’re going to look like and be able to get input from everybody… You talk about clients obviously. We’re dealing with an application where we don’t deal with our clients. But we even have, for example, support people who can look at the prototypes and they know our customers better than anybody else, and be able to give feedback early on.
So, the interesting thing about these tools, I guess, is there’s an ongoing discussion between people who tend to value really fully specked out design comps that give you a very good idea of what the visual design of a website is going to be. Some people prefer to do sort of wireframes or sketches that give an idea of the layout and content of each page.
Then, there are tools like this that really are more aimed, if I understand correctly, at outlining sort of the interaction, because they’re interactive prototypes that you can click through and see how the pages link together.
Wolf: Exactly, yes.
Louis: In your work, was interactive prototyping something you were doing before you built this and you just saw that the tools out there didn’t suit your needs? Or was it something you came to as a result of building HotGloo?
Wolf: I think it was something that came with the result of building it. When we started in the first place, we were using other tools, which were out there back then. We were using Axure and we were using Balsamiq.
For us, these tools, when we showed them to our designers they were like, “Well that’s something I can do in Illustrator. That’s something that I can do in Photoshop.” A project management account came up and said, “Well, that’s something I can do in PowerPoint or Keynote.”
When we started with our own tool, we thought, “Well, what’s the distinguishing factor that you cannot do with these tools, and that’s vital to the whole process?” That’s building interactive prototypes and not so much focusing on the high fidelity visual hierarchy, because that’s a completely different story, to build a pixel perfect kind of prototype, fully designed and interactive.
We just wanted to make sure that the process building wireframe is as easy as possible, but you have the whole flexibility of doing a really smart interactive linkaging within your prototypes. For us, it wasn’t so much the visual hierarchy, to be really visual, on the point and really high fidelity, but something that goes from really rough wireframes to adding more and more interactions. Essentially build really interactive wireframe, smart interactions with a few stacks and kind of state changes out of your project.
Louis: Yeah, that’s one of the things sort of drew me to this tool, among other things. I’ve played around with a few different wireframing tools, and a lot of them will have links from one page to another. But sometimes, when you’re working on something that’s a forum or a multi-step process that involves changes in the state, like you mentioned, just linking between pages is difficult. Or you have to create a page for every possible state of the application.
Whereas, in your tool you’ve kind of built in a few little primitive programming concepts that give you the ability to have a little more interaction, like changing a state for example. If you select an option from the drop-down, then that can have an impact on a state, then clicking the next button does something different depending on that state. So, you can really create a prototype that is a pretty accurate representation of the final flow of what a real application would feel like.
Wolf: Yeah.
Louis: At least I don’t think I’ve come up with a situation where there was an interaction that I needed that I couldn’t hack together with combinations of stacks and variables in HotGloo.
Wolf: Yeah. There are a couple out there, which we’re kind of looking at right now. Like some timed interactions or stuff like that. Overall, that was basically our idea. When you’re building interactive wireframes, it could be very time consuming. I get that from the whole discussion that’s going on right now on the web. Now, people say, “Well, the whole process of wireframing is very time consuming. Why not skip that and jump right into HTML prototype?’
Yeah. For those who are familiar with coding, fine. For us it was in order to build the really sophisticated interactive wireframe, we needed to make this process as easy as possible. A lot of other tools, they’re just linking basically pictures they’re making out of the interactions.
But for us, it was important that when you use the navigation and you’re bringing the whole site map into this navigation that once you change, for example, a page name in the site map. Then the page name in the navigation changes as well, because that’s the whole idea of an interactive wireframe as well.
That it’s a smart little thing that updates itself once you change a master, in the master’s view. The master is changed on each page you kind of put him. Interactive wireframes shouldn’t be a process that is so time consuming overall that in the end you kind of think, “Well, wow, I could have saved this time and jumped right into HTML prototyping.”
Louis: Right. You touched briefly on the idea of people wanting to do prototypes directly in HTML rather than using this kind of tool. I guess the argument there is that when you’re done, you have the first steps of the finished product. Do you feel like that for some teams is a valid strategy? Or do you really strongly believe in the idea of creating a prototype outside of HTML and then only diving into code once the interactions are really nailed down?
Wolf: To be honest, I deeply believe everyone has his tool or his toolkit. There are people out there who are jumping into HTML prototyping, and for them they would never go back and do wireframing again in a third-party tool.
I just see that there are a lot of people coming to wireframing that haven’t thought of this process before. When we started out from the first kind of update, we had, we kind of saw that there is also a strong need of kind of talk about it and this kind of educational thing. That we’re also trying to kind of roughly visualize with our Posterous blog and Wireframe Wednesday, where we’re just scanning the web and trying to put together articles we found on the topic of wireframing and prototyping and these experienced topics.
Because I strongly believe that there are so many people out there and so many teams that haven’t even thought about the process of trying to lay out something before they actually go in to build it. So, I’d say for those people it’s really wise to have a tool, because in most cases they’re not developers. They don’t know any programming languages.
Sometimes they’re project managers, designers. We’re also seeing graphic designers jumping into web design who have to do web design projects, who kind of came to us and said, “Well, that’s a really cool tool, because for the first time I can very easily put something together that’s interactive, that’s clickable, that I can show our clients.”
That’s something that’s really important for us. Although we see ourselves as a professional tool, but to actually have people on board that are trying out these processes for the first time, and also get along with the tool as easy as someone who has tried a bunch of tools and is really experienced.
Louis: Yeah, absolutely. One of the things I found is that if you’re either trying to do Wireframes or prototypes in a sophisticated design tool like Photoshop, or trying to do them in code, is that it’s very easy to sort of accidentally be sucked into doing detail work. It’s hard to keep yourself in the mind frame of, “All I’m trying to do here is nail down the interaction.”
I start worrying about the radius of the corner and the shade of the gradient instead of what words are on the page and what links to what.
Wolf: Yeah. Sometimes I feel this whole idea of HTML prototyping is not as far away from the process we had before, jumping right into design in Photoshop. As you mentioned, you’re getting sucked into detail work. That what was happening before as well. It wasn’t so much on the interactive side, but it was on the design side.
But it was also with designing or jumping straight into design in Photoshop, it was from first click on, you’re into detail work. You’re into thinking about gradient radius and thinking about color, the whole color sphere of the project you’re building.
We all agreed back then that it’s not a good to idea to really start with the design. Now it’s this discussion about starting with HTML prototyping. Sometimes I see really similarities of these two processes. Not in general, but in this sort of being sucked into details that with wireframing, you kind of leave out or you cut out.
We have people who come to us and kind of ask for features, or trying to get feedback. A lot of this feedback is, when you analyze it, it goes more and more into details. People would like to have bigger color palettes. They would like to have more fonts. They would like to have all symbols rotating and that kind of stuff.
I always remind them that our vision of the tool is it’s not a visual design tool. It’s a wireframe tool. Everything that goes into too much detail for me personally is like then going into prototyping. That’s something that you can do in the browser. That’s something you do or you can actually do that afterwards when you design the page, which isn’t something you necessarily have to do when you wireframe.
Louis: Yeah. One of the things our team has found with regards to doing this kind of interactive prototyping is it forces a greater focus on the words that are on each page. Not just the content, but sort of the copy that accompanies any of the functionality of an application. Whereas if you start in design you’re thinking about pixels and gradients, and you put some lorem ipsum in there. If you start with an HTML prototype you might be doing the same thing.
But when you’re working with a wireframe or an interactive prototype, the only thing that someone sees when they get to this page is some words on a button. Then you think about what those words are and what are the best words and how to explain the process, especially when you’re working with a complicated process.
The first job I did for this was sort of working on redesigning our whole listing sale process. That’s a massive – it ends up being sort of a seven step wizard with a lot of moving parts. Really forcing us to pay attention to the words on the page was sort of a revelation I guess from a team that had always been sort of “come up with an idea for something and then start building it straight away” to moving into thinking about things a bit more head of time.
Wolf: That’s something myself, I can get very lost in words. Micro-copy and copy for alert messages and stuff like that. Sometimes I can get very hooked on it.
Yeah, as you said, it’s this visual down tempo when you look at a wireframe and you only see gray shades and boxes and buttons. The only thing that sticks out is the copy, and copy is one of the most important things on a website. Especially on a sales websites, especially on a website like our website, the marketing website where you describe your tool and trying to get people to test it and hopefully sign up and become customers.
So, yeah, I’d say anything that nails down and keeps the focus where you want the focus to really be at. That’s something when we’re showing stuff to clients is, you don’t have to explain that much what wireframess are. We only do it briefly in one or two sentences what they are looking at and what they can expect from this.
But, they get the idea very fast. Then almost all of them are trying to like the idea that they can now really focus on the architecture of the website, see which information goes where, and also the copy. Which before no one really thought about in the first place, but it was something that has been added on and on, mostly after the development was done.
Louis: Right. If a client sees a mock-up, they’re not even going to notice what the words are. If they don’t like the shade of green, that’s the first thing that comes to their mind. They’re going to be like, “Can you make that a little bit darker?”
Wolf: Yeah, absolutely. Yeah.
Louis: Then you don’t have the conversation about which page links to where or what the word is. Is it my account or is it your account? How do those words fit together? Which is a lot more important than the shade of green, but it’s hard to communicate that unless you have a very stripped down wireframe or prototype.
How does user testing fit into your development workflow? If you have to do user testing, do you do it with a prototype, or do you actually build out the feature first from a prototype and then look at users?
Wolf: We’ve tried a couple of things. We’ve tried to do user testing with prototype, which requires a bit of work up front. Because you have to explain to the testers what they’re looking at, which actions they should perform, that they’re actually not looking at a done website, but just at a prototype.
The other thing we then try to accomplish is we build something very roughly, like a first take, and put it out, then just recorded mouse flow actions. That was something we did as well.
Other things we did with user testing, we tried to get information up front. We tried to bring people in and to kind of interviews before we built the second revision of HotGloo. We kind of went out and showed people the first website, and then asked them a couple of questions, what they were expecting from a tool like this. Trying to get as much information up front before we even started to think about what we’re going to change for version two.
Sometimes I’d say it’s a whole ongoing process, that you have user testing that starts with doing interviews and getting ideas up front, then doing usability testing with a prototype, going into iterations and testing again. Sometimes you’re just getting your information up front and trying to build something very fast, very quickly. Get it out, test it and iterate on the way. It really depends on the project.
I’d say a lot depends on the complexity of a project. A large project, big e-commerce projects, tend to be much more time consuming and needs a lot more testing than just a small marketing website with two or two, or three, or four pages.
Louis: Right. There’s a question that I absolutely wanted to ask you. Because now that you’ve built HotGloo as a tool and you’re still continuing development on it, when you want to prototype a new feature for HotGloo, do you do it in HotGloo now?
Wolf: Yeah.
Louis: It’s an inception of HotGloo?
Wolf: Yeah. It was also when we did the, I think it was now almost a year ago, when we came out with the new website. Now, we’re doing an update on the whole interactions, and it should be easier to apply interactions, especially if you’re applying the same interactions to a couple of elements.
We also have a few new interactions coming soon. That was also something we, “How is this new property panel going to look like? Do we have to kind of change the whole appearance of the property panel?” That’s something we actually build in HotGloo. It’s sometimes kind of funny when you see the new features that you’re laying out and concepting in the tool that afterwards is being updated with these new features.
Louis: Right. So, you hinted at this a little bit. What kind of stuff are you working on on HotGloo for the future?
Wolf: As I just said, the interactions is the next big thing. Because I think in April this year, I think it was April, we kind of thought about that we wanted to add mobile UI widgets, because we’ve got a couple of people walk in our doors, saying, “Why are you not offering any mobile stencils? I want to wireframe an iPhone app, an iPad app.”
We have all the elements ready. But before we updated all the elements, we kind of found out that with the set of interactions we have right now, it doesn’t really make sense. There are a couple of other interactions that actually in a mobile prototype would really work, so we started to work on the interactions as well.
That’s basically the road plan for this year, is new interactions. It’s the iPhone, iPad UI widgets. We want to improve the feedback nodes, because the whole collaboration process in HotGloo is where we see the most potential besides the whole interactive features, is the feedback nodes.
The communication that goes over these nodes, we want to make this process easier. We want to kind of build something like, some sort of requirement steps that you can actually approve nodes, and so a team sees when something’s done and when an element or a web page needs some work.
Some kind of notification system, that can help teams to actually wireframe their projects faster, and to keep an overview of the project and the process of the project, the development process. That’s the three major things that we’re looking at this year.
Louis: All right, that all sounds really good. I’m looking forward to seeing all of that.
Let me just say, thanks very much for taking the time to talk to me about this stuff. I really appreciate it.
Wolf: Thank you for inviting me.
Louis: For listeners who are interested in HotGloo, the URL is hotgloo.com, that’s H-O-T-G-L-O-O.com. You also mentioned you have a Posterous blog sort of of various notes and articles clipped from the web relating to wireframes and UX design in general. What’s the URL for that?
Wolf: That’s www.wireframewednesday.com.
Louis: Wireframewednesday.com. If listeners want to keep up with you, do you have a blog or a Twitter?
Wolf: My Twitter handle is @wdbecvar.
Louis: All right. Again, thanks very much. I really look forward to seeing what HotGloo has up its sleeve in the coming years.
Wolf: Yeah. Thanks for having me on the show, and take care.
Louis: Take care.
And thanks for listening to this week’s episode of the SitePoint Podcast. I’d love to hear what you thought about today’s show, so if you have any thoughts or suggestions just go to sitepoint.com/podcast and you can leave a comment on today’s episode, you can also get any of our previous episodes to download or subscribe to get the show automatically. You can follow SitePoint on Twitter @sitepointdotcom, that’s sitepoint d-o-t-c-o-m, and you can follow me on Twitter @rssaddict.
The show this week was produced by Karn Broad, and I’m Louis Simoneau, thanks for listening and bye for now.
Audio Transcription by SpeechPad.
Theme music by Mike Mella.
Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.
Karn Broad
