IA Summit 2015 Main Conference Talk
Topic(s): coding, communication, content modeling, and documentation
For Information Architects concerned with reducing cognitive load for people that use and interact with our products, we’re making the process of interpreting, understanding and getting that product built, a rather bumpy road. Add in an increasingly fragmented browser and device market, and the once somewhat manageable communication problems we originally had as IA’s have now doubled.
Flexible documentation speaks not only to the physically fluid nature of future IA artifacts but also the portability and scalability that we need to inherit as a means to communicate more effectively.
Whether you work in a startup or fortune 500 company, utilize a waterfall or agile approach to product design, this presentation will give you tools you can use today to increase your efficiency in design and effectiveness of design communication.
About the speaker(s)
Jon Hadden is a product design director, speaker, and writer with over 10 years of experience designing and developing digital products for millions of users across the globe. He is Founder of NiceUX and Simple CMMS.
Jon Hadden: Thank you for coming. I’ll tell you a little bit about myself, to give you a little bit of background. Thirty three years ago today, my parents had what they call a unicorn. It’s a mix between a narwhal and a horse, and were responsible for rainbows, and then also information architecture, and frontend development, kind of a mix.
Jon: Actually no. I said today, but I was lying. I’m sorry. You can still trust me though. I’m going to say a lot of things, that are true here. I do a lot of things, and I work with a lot of teams, as an independent contractor. Sometimes I’m on the IA side, sometimes I’m on the frontend development side.
This is a mix of all the things that I have learned in terms of responsive design, when we think about documentation that we’re producing, and the amount of waste that we instill in the process when we produce our documentation.
Observing people and seeing how people work with things and seeing how people work with the web and just life, in general, but when you remove those things, I love helping people enjoy the web, but I like to do this by doing as little thinking as possible, [inaudible 01:09] onto my plate when I have things to worry about like wire frames, content modeling, ready code to build out a prototype.
I don’t like to do things and I’m pretty adverse to doing things when thinking is involved. Turns out I came to the wrong conference.
Jon: This is a wonderful conference, and we’ve been doing a lot of thinking, very divergently, in thinking about the process of, “Why do we do things? Is this the right problem that we’re actually solving?”
This is actually a little bit like some of those tactile things like documentation. It’s a subject that’s a little boring for some, but I think we need to talk about it, especially with responsive design added in. Is anybody from San Francisco? What happened to the grid system down by Diamond Heights. Noe Valley. What happened there?
Jon: I don’t know how to drive there. It’s incredibly difficult to get around. I go there every now and then, every couple of months or so every month I’m in San Francisco. I’ve adapted to the environment that I’m driving in.
For Minneapolis, we live on a grid system and everything is north to south, east to west. You know how to get places or at least if you don’t you can find a landmark within the city to allow you to find your way to the north side of the city or the south side of the city.
One of the first times when I went to San Francisco, I was driving, and I naturally looked for information to how to get around. I’m fairly confident in my way finding ability when I’m driving a car.
I look at a map, I know there’s a couple right turns, I need to take the freeway there, and there might be some traffic here or there. Then, when I get a little bit closer, it’s like, “Holy crap, look at all these turns. Look at all the…” This is not a grid that I’m used to. Regardless, I have this map, I’m good.”
Then when I get to the actual environment I’m in, I get something like this.
Jon: Then all of a sudden anxiety gets added on, and I have to do a lot of thinking and making decisions on the fly, 30 miles an hour, with California drivers. I’m sorry.
Jon: Actually, you find your way to the place, and then I have to park like this. I’ve never parked at a 45 degree angle. I’ve never tried to do that before. How am I supposed to navigate this? It’s especially amplified if you have a manual transmission car. Fortunately I didn’t.
Once you finally get to your parking spot, you walk about a half a block and you see this. I take one look at this, and without thinking at all, this kind of just equates to, “Don’t park here.”
Jon: It’s a terrible idea to park here. Someone actually approached this problem to reduce the amount of thinking that someone has to do when they’re parking in a situation like this, and actually that signage was in Los Angeles so San Franciscans, it’s definitely an LA problem.
But Nikki Sylianteng — I’m probably butchering that — provided a little context around that exact same problem. This was actually in response to one of those signs. I think Andrew Hinton put this in his Understanding Context book.
It’s wonderful, and it’s giving you and providing you that context of, when do you think you should park here, when can you not, and this was a prototype that she put together and the city actually implemented it. It was wonderful. You don’t even have to think. Monday, nine o’clock, don’t park there.
But in life, when I was driving around and trying not to think, and trying to get around day to day and get from one place to another, and getting to point B, from point A to point B, there’s four things that I really think are very helpful.
Paying attention to the peripheral information around us, so knowing at least when you’re going into a particular situation, and that’s probably the thing I should have done when I was looking at those Google maps, just looking at Street View, and knowing that there’s a 45 degree angle and knowing that there’s this signage in this particular route, that I can set my expectations properly. There’s a lot of peripheral information around us, and these are way-finding tools, right?
Signage, you hear this recurring theme throughout the conference, to help us find our place from point A to point B.
Be efficient when you are making decisions. In the real world, I don’t like to do more work than is necessary to get the job done. We’ll talk about that in one second.
Remain flexible and adapt to your surroundings. This is incredibly important, especially with responsive design. I see seasoned designers even go in to a responsive project, and not know how to handle it.
It’s like, “You have these tools, you know how to wireframe. You know how to approach problems of defining context and dividing content for a particular context and an environment. It’s just that this environment’s a little bit smaller.” Yeah, you might have to think about the navigation a little bit differently. Yeah, but it’s the same kind of design problem. But when you get into these different situations you need to be able to adapt.
Then being able to effectively communicate and probably set expectations to the people that you’re working with. Responsive design is the thing that really hinders our communication between each other, because when you go from what we traditionally had done with 1024, with 768, or the static mockups where you go from a million different PSDs or a million different wireframes, and then put that into the web into a responsive solution, things change. It’s not those fixed widths anymore. There are points in between that need to be addressed.
Actually communicating that is very difficult. Let’s talk about that documentation.
Now, responsive design…I’m picking a little bit on responsive design, but it didn’t really introduce new problems to IA. It didn’t introduce new problems to designers. It really amplified the ones that were existing. Between these different groups, between these different groups that I’m working with, every way that they do a process, every way they do documentation, approach documentation, is very different between them.
There’s some of the same problems. It really boils down to efficiency and communication. Can we effectively deliver this? Can we get to point B efficiently, without waste, without having to think about it, and do that within budget? Then also communicate that to the people that going to be buying this thing, or investing money into it?
Let’s talk about a real-world story. Let’s put this into the web. At the end of this I’m going to ask you, this is a project you’re going to take on, if you had this on your plate, would you say, “Yeah, I’m going to take this project on” or “Hell no”?
There was this application…this is a theoretical situation. It’s an application and the main goal…there’s a couple different tasks that you just have to perform. The main user and the main goal is to approve an invoice. It’s an invoice approval system.
The personas, the people that are using this are close to retirement. But their end-of-the-year bonus actually is dependent upon the amount of invoices that they approve, and so that’s what they do all day. They approve invoices.
They primarily use a PC, IE7, old browsers. Really bad. This actually is a redesign or we’re upgrading it. But the original application was built on a desktop, as a desktop application and then just jammed into the browser. Performance is terrible.
Our user needs four things to approve an invoice. There’s four simple things that they need to approve an invoice — invoice amount, bill amount, route details, associated notes. These are just four pieces of information that they need to be able to say and make a decision yes or no.
Now, this particular application in its current state makes you go to pick an invoice from the list. Go to a tab within that. That takes a long time to reload. Get the invoice amount. Go back. Go get the bill amount. Go back. Route details. Go back.
Actually, no, go from that invoice list over to another section of the system and get the notes. Find the invoice. Go get the notes, all the while writing these pieces of information down on Post-it notes and tablets.
Go back and then I actually have to go back to this transactions area to approve that invoice. You get very low expectations. On the surface level the usability problem’s through the roof. You just see it. It looks like this. It looks like this.
As a designer is this a project that you want to take on? Oh yeah. Absolutely. This is just on a silver platter for you. This is amazing. You can see the inherent usability problems. You have all these tools that you know about, how to fix these problems.
You have this little toolbox with all these different things that you know how to get from point A to point B effectively and this thing is a train wreck. It’s just awesome. Yes. I’m going to take that project.
This is going to be a responsive project. We’re going to turn it into a responsive as well. You get into it and actually you start working with them and then all of a sudden they say, “Oh, this is our process, all those kind of things, those things that [inaudible 10:57] things, this is how we do it. You have to do it this way.”
For large screen size, you produce a bunch of different wireframes, static wireframes, visual designs to create those PSDs, medium size, all the different sizes. A lot of documentation for a couple of different concepts. It is piling up. You are up to your ears in documentation.
Also, at the end of that design cycle and through all the iterations and everything and the political drama that you’re going to navigate around, it ends up looking like this on the other end. Is this a project that you want to take on if you have to work nights and weekends? You have to change the color blue just because it’s not blue. It’s “we’re going for blue.”
File names that end up like this draft of the final, uppercase letters. I’m yelling at you now. Then just a general sucking of your life because you working nights and weekends and it’s just terrible. Is this a project that you want to take on? Not at all.
Whenever we approach websites, we’re thinking of all these different angles of how do we improve it, how do we give users this really nice experience, and how do we make it easy that they don’t have to think and get from point A to point B and get out of their way, but we don’t do it so much for our documentation.
Approach to cognitive load of consuming, creating, delivering, understanding the documentation that you’re putting in front of the stakeholders who might not know how the web works. Also, your users, like you would the usability of an application.
There’s three questions. Actually, that project, that wasn’t theory…that happened to me. It was awesome. It was a great learning experience and it helped make a talk for today.
There’s three questions of myself for my own process as I go to my next client because I’m not working with them anymore. What are the opportunities to reduce? Misinterpretation when viewing this design whether it’s visual design or the wireframes.
How can I make my process efficient or reduce the amount of work I need to do to get everyone from that point A at the very beginning when we say, “This is what the problem is and here are the things that we need to do to get to the end state and make sure that everybody has the same expectations of what that end state would look like.”
Can I increase the portability of my documentation? When I talk about flexible documentation, I always talk about in the scope of responsive designing naturally go through the physical traits flexible. Flexible grids and adaptive grids, but I’m also talking about flexibility in terms of portability.
These things that I’m doing right now, this time that I’m investing right now into content modeling, can I reuse that or am I going to have to redo like laying a content set out in wireframes?
Then the visual designers are going to have to lay that content set on in visual design then the prototype is going to have to lay that content set out in the process. It’s not too portable for the content set.
Let’s talk about three different areas that I think are pretty apparent that you can improve content modeling, wireframes and visual design. Not only how we communicate to each other, but also how we create it.
Rachel Lovinger in 2007 wrote a “Boxes and Arrows” article about content strategy. It always start with a question, what is this content? I think this is not just content strategists. This is for information architects as well.
When we talk about putting together a content model, we’re talking about the structural relationship of those pieces of content. We’re not talking about just the image or just the title, but there are things that you don’t see within that content that need to be brought out into this content model.
The volume of the content. The frequency in which it comes at you. All the details. Boolean value is like if this particular piece of content is a feature, yes or no in any frequency or maintenance that are with the content.
A lot of time, content models, there’s no one right way to do everything. Sometimes, my content model will look something like this. Some hierarchal list of this for finding contact lenses. There’s a manufacturer or manufacture within that, has multiple brands, there’s multiple lenses, different quantities within a particular one.
Let’s actually take it and put it into a real world situation. I listen to Rdio a lot. Some of you might listen to other services for music players, but I listen to Rdio. Let’s take this and reverse engineer it.
A content model, I get this from A List Apart talking about content modeling and what is content modeling. It’s very simple at the frontend. It’s what the relationships? What are the pieces of content that we actually have?
This can be visualized in many different ways. Even just a hierarchal unordered list or maybe like this, when I put a little bit more structure around it. Actually, if you start adding those things that you don’t see on the surface like for responsible design, the small art, the medium art, the large art, is there an order in this album that this particular song lives?
When I create content models when I can actually prototype with that, I write JSON. It’s just naturally where I go because I have a frontend developer beside of me, but then I can take those pieces of content and I can deliver them to different WiFi enabled devices like toasters, watches, phones, your car, all these different WiFi enabled devices. You can take different chunks and splice it up.
Utilizing JSON gives me structure insurable information sets that I can distribute in these different environment. Actually, I thought I heard of that somewhere. That’s right. Wikipedia, the one source of truth on the Internet. I’m kind of saying the same thing here though about information architecture.
Within wireframes that lends itself to identifying, from point A to point B, are we properly setting expectations? Here’s a wireframe that I did. You could see, there’s a two-column list within this list of people.
When we actually get to the browser in real estate that we have, it turned into a three column layout. That’s small potatoes, but there’s instances where it’s a much larger impact.
Now, when we start getting to source ordering, those little minor breakpoints, not just the major breakpoints, but all those little tiny things that happen between those major breakpoints that we really need to figure out, it’s really difficult to do it in traditional wireframes.
My wireframes look like this. General relationships between pages, sketching, just a lot of doodling, then actually getting in more refined flows, more refined UIs and even iterating on one particular page multiple times just to see what works, what doesn’t, doing this with multiple disciplines in the room. Maybe it’s a storyboard, this is how this thing works and this is how the multiple parties interact with it.
After I get done with sketching, traditionally, if I can help it, I jump to a framework like bootstrap. Even if you’re not a frontend developer like a frontend developer, this is still a wonderful framework. This foundation [inaudible 18:35] or something else. There’s other ones out there.
You can basically copy and paste and create something that lives in the natural environment. You can create something like this. This is an example of a product that I’m building right now for myself that I was able to prototype within an afternoon utilizing bootstrap and utilizing a theme that was out there that I bought.
You might it’s cheating, but actually I could build this prototype in an afternoon and get it in front of a user the next day, in the browser.
Then also you see edge cases. Those edge cases really come out when you start looking in the realistic environment that it’s going to live. This is something that actually happened to me. Has anybody else been in the vortex of a GoToMeeting or the vortex of a Google Invite, and just…I found the meaning of life, it’s right there.
Jon: We’ve got to be wary though, like be careful. If you’re going to use code to prototype, people think that you’re a lot further than you actually are. They think, “Oh, yeah. If I could click it, it’s in the browser, I’m done. We’re done. This is great.” No, actually not, it’s [inaudible 19:46] hooked up yet and actually they’re going to probably review. I write a lot of this stuff, they’ll probably review some, but yeah.
If you’re building like just maybe a little tiny prototype, they want the whole thing. You have to set those expectations because that might not be what you’re trying to do in the current state. Then, there’s still specification documentation. You still have to supplement it somehow.
This is a static PDF of annotations that still happens, but you still have that reasonable portable prototype of code, of JSON, of your wire frames that will help you get from point A to point B easier.
Visual Design, this was incredibly imperent on the iSummit website. Going from wireframes, visual design to frontend development, we had a disperse team that added a level of complexity to it, but then also we utilized Style Tiles.
Is anybody familiar with Samantha Warren’s Style Tiles or Dan Mall has a version that’s called Element Collages, but it’s a wonderful way to reduce that waste, reduce the amount of time that you’re spending in visual design.
You’re not making a million PSDs for every screen that you have. You’re looking at just these UIs and Steve Fisher put this together for us. Here’s our common colors, here’s all those wonderful things. He created screens.
He’s created full-screen composition, that’s totally cool, actually helped out a lot because when we went from that to applying it to the wireframes whether it’s myself or these are from Mike Atherton, I can see the structure, but then I can also see “OK, this makes a whole lot of sense when I’m looking at this.”
You can see the logo, I see the skyline, it’s blue. Here’s all the colors, it’s wonderful, but there are still things that you need to adjust. There are still points of communication that we need to have between design to development. There’s one that’s a design, there’s one that’s a development, a frontend code, which one is the design, on the right or the left?
Audience Member: Right.
Jon: Close, actually not close. No, you’re wrong.
Audience Member: [inaudible 02:04] .
Jon: Thank you. Thanks, I feel good. No, it was wrong. There was a couple of adjustments that need to be made. You go into a meeting and you talk about the adjustments that need to be made, and we start talking about, “Well, there’s too much spacing. The text isn’t bold. It’s a wrong typeface.
There’s not enough leading. The text is too big.” These are very generic terms, and I could go make changes, and then the next meeting we have and they say, “All the text is little too small now, let’s make it a little bit bigger.”
We run around in these hoops. The wonderful thing about our browsers is that we can actually look into this and see what kind of HTML and CSS that we’re using on this particular page for this particular element. It changes the conversation. We can communicate better. We’re on the same page. It’s not the text is too big. You need to reduce the line height actually here to 1.25. You need to increase the padding top to 300 pixels.
Much more efficient way to communicate to each other because then we fix those things and we move on. Changing any part of your workload, there is no one right way to do things. We want to be as effective at getting from point A to point B, properly set those expectations, but doing that means workflow change and change is scary.
It’s very difficult for [inaudible 23;23] , that’s why we stay in these little ruts, but responsive design, I think it added that new element to say, “Well, now you’ve got to do it three times over.”
You’ve got to do it, you’ve got to worry about all these extra things so the tools in the process that you’re using is a little bit different. The one real way to measure the success if you are making that work flow change doesn’t make everybody happier on the team. Are you happier? Are you not sucking at life any more? Are you not working nights and weekends? Thank you very much.