1. Matt: Welcome everybody to this month’s interactive primer. This month we are talking embedded UX. We’ll get to the definition of that in a little bit. Just to explain who we are, we’re The Nerdery, we are an interactive development shop that works with agencies and Fortune 1000 companies. We work with anybody, really. But what we do is, we’re kind of the backend developer to a lot of projects. You guys’ll come up with art and stuff like that and then we will take your idea and develop it for you. A few stats on us, and actually these are probably like 2 months out of date again but, it says we have 176 people working here I’m pretty sure it’s at like 196 or we might be over 200 within the next few days. Over 100 of those people are developers, so it’s like an army of developers here. We’ve worked on tons of projects. Right now it says 3600, I think it was 3800 when I checked it this morning, but, we’re doing tons of work and like I said that’s a 2 month difference so 25 people and an extra couple hundred projects in 2 months.

    A little housekeeping on the presentation today: This webinar is broadcast only so we can talk to you but you cannot talk back to us. There will be a slide coming up on ways you can submit your questions. Other things, we are recording this right now. We have the video, we have slides, we have all this stuff, and expect that on our blog sometime in the next week. Let’s introduce our speakers today. First up is Mike.

    Mike: Hi guys, this is Mike. I’m the Director of User Experience here at The Nerdery. I’ve built a 13 person UX team, 13th guy is starting in May. What’s up, Zack? We’ve been doing UX for about 3 years here at The Nerdery. A year and a half of that was just me. Demand has increased tremendously. In the last year we did 5500 hours of UX-only work, which is roughly 3.7 person years if you stack it end to end. If the direct sales team here meets their goals we’re expecting to double by the end the year. My co-presenter here is Nick Tietz.

    Nick: Hi, I’m Nick. I’m the Senior User Experience Designer here at The Nerdery. I’ve been here for about 2 years, and we’re just kicking ass and taking names.

    Matt: All right, so here’s the slide. If you guys have any questions there’s 3 ways you can send them in. Feel free to send them in, if they’re in the middle of talking about something and an idea pops into your head don’t feel worried that you’re going to interrupt them. I’m moderating them but you can send them using the questions panel in the GoToMeeting app, send them to us on Twitter @The_Nerdery or send us an email at primers@nerdery.com

    Mike: All right, so let’s kick this off. Here at The Nerdery we have a concept we like to call Project DNA. We work with a lot of different types of clients. We’ve got the agency partners, which Matt touched on briefly, where we’re essentially the technical back side of the project and the designs come all baked from the agency and we just execute on them. We work with direct clients, big corporations, smaller companies that have ideas and strategies that they need executed and part of that is UX and design. So, we’re used to engaging in a variety of different scenarios. The way we like to look at it is all of our clients have something they can bring to the table. Whether they have a freelance designer they hired or they’ve already done all their market research or they want to use our research. We’re totally open to that, we don’t force our clients into a specific streamlined process. What we like to do is kind of identify what you guys bring to the table and fill in the gaps to create a complete project. That’s something we do on a lot of different projects and if there’s a conflict, if we work with an agency and “hey, we do user research and you do user research” that can all be figured out during the planning phase to figure out who does what. Just a quick “what is UX?” for those who are fairly new to it: UX is user experience and, as a field, it’s fairly new. I guess you could call it an emerging field. It’s been incubating for years under different guises. When people think of design they traditionally think of how something looks or how pretty something is but in UX we’re really more concerned with how something functions. We want things to work well, we want them to accomplish goals, so the simplest definition of UX that we’ve come up with is we want to take the goals of your users or your customers, we want to take the goals of your business, how you want to make money, and we want to align that with the application or the interface that we’re developing for you.

    Nick: So, for example, you want to make it easier for your users to sign up, or find information, or register. Our goal is really to understand, using a user-centered design processes: What do your users need to do? What do you want them to do? What do they want to do? Then make sure they can accomplish those things. Taking away those barriers in those processes to make sure that it’s easier for them to accomplish both their needs and your needs.

    Mike: At the end of the day it’s all about minimizing frustration. You hear the term usability thrown out a lot and usability is supremely important, especially for high volume clients like an Amazon or a Bing. Just a fractional improvement in the user experience can pay extreme dividends. So really it’s all about happy users, happy customers, loyal customers, bringing people back. Why does your project need UX? Well, there’re a lot of different reasons why a project would need UX. The main one is everyone has a different idea of what we should be building to accomplish our goals. Even if there is an illusion of agreement, there are so many different ways to interpret functional requirements and how they’re going to be implemented on the web. There needs to be a process that creates a visualization that everyone can rally around and say “Ah, yes, this is what we’re building and this is how much it costs.” In addition to getting all the stakeholders in alignment, we find that a lot of our customers haven’t actually talked to any of their users, and are getting in to situations where they’re putting their website or application in front of users for the first time, and getting their responses can be pretty shocking for some customers when they find out that the website that they love isn’t actually accomplishing what they set out to do.

    We have one role at The Nerdery on our UX team, essentially, and it’s called User Experience Designer. There are a lot of different roles out there in the industry that are specializations of the User Experience Designer role; we like to think of UX Designer as a Jack of All Trades. However, you might have heard of agencies or other design shops that might have had roles like this.

    Probably the most well known one is Information Architect, and I really think that User Experience Designer is an evolution of the Information Architect role. Information Architects are traditionally really organizational information interaction type people. They don’t deal with the visual creative side, they would deal with “Hey, I’ve got 600 products and I have eight axes of categorization I need to align these with, and I’ve got 100 pages of content.” An Information Architect would take that, organize it into a hierarchy and figure out the best, most usable way for users to approach that information.

    Visual Designer is another role that’s pretty well known. We like to separate out Visual Designer because we believe that you can be a really, really good Visual Designer and a horrible Information Architect because they’re kind of left-brain/right-brain activities. Some people are good at both, some people aren’t. The Visual Designers are really all about taking brands, color, type, all those things, and applying it to information architecture. For those shops that don’t have IAs the Visual Designers do all the work. That’s pretty common.

    Usability Specialist, really some of that’s kind of just a “human factors” geek and looking at accessibility – how people access things from different devices, people with disabilities, things like that.

    Content Strategist is another term you might have heard and this is kind of a hot role right now. A lot of people want to redesign their website but without changing the content you’re kind of doing yourself a disservice. The way that people approach content on the web these days is a lot different. It needs to be scanable, it needs to be concise, and it needs to be digestible. A Content Strategist kind of comes from the editorial world with an interactive spin on it. This is a really interesting role that we’re exploring as well.

    A Researcher would be someone that just specializes in digging up information whether it’s market research, what your demographics are, or who your users are. Research is for your business. Sometimes it’s called Business Analyst if they’re specifically looking at your business processes and things like that.

    Another new role that’s come up that is probably not as well known is Creative Technologist. We like to think, since we work with a lot of ad agencies and we work with a lot of developers, the Creative Technologist role is something that we kind of pride ourselves in fulfilling as a bridge between good design and technology, which we’re going to get into here in a second.

    We design for a huge variety of platforms. The reason we do that is because we have developers for all these platforms. In the web/interactive column you’ll notice I have some browsers. I can hear you saying “What? A browser is not a platform” but actually a browser is a platform because a browser is that interpretive layer between your application and the user. Browsers have different capabilities. There’s this web standards movement that’s trying to bring all these browser capabilities into alignment but it’s not quite there yet. We have a huge team of frontend developers that know every little quirk, “You can’t do that footer stuck to the bottom in Internet Explorer” or “Hey, Chrome supports this really cool new HTML5 gizmo,” whatever, so that’s a platform that we consider.

    Nick: Mobile - Android, iPad, iPhone, Blackberry, with our developers behind us we’re really able to understand what’s needed on those type of devices, designing for those constraints so that as we move into the development phase we’re really thinking proactively. That goes into our tablet devices as well, such as iOS and Honeycomb. Then also into embedded devices like ATMs, vehicle systems, handheld scanners, appliances as well – refrigerators, washing machines. Anything that has an interface that needs to interact with a user are things that we design for.

    Mike: We hear this a lot, some of our agency partners get nervous and say “Well, you guys are doing design now.” We have kind of a special brand of design here. We design interactions. We’re not a design agency, and there are a few distinctions here to make to illustrate that point. The first one being we don’t create identities. We’re not going to do your logo, we’re not going to come up with your brand, we’re not going to come up with the brand voice guide for your company. That’s just not something that we do. We work with companies that have an established brand, ideally a company that has an established style guide, although that’s not completely necessary. You really at least need a logo. I can’t stress how important a logo is for the success of your application. So, we’re not doing any of that stuff. If you don’t have that and you have an idea that you want to build, we would bring in one of our agency partners to help develop that for you. The other thing is we don’t create content. What I mean by that is we don’t have a photography studio to go out and shoot all the new vehicles for bmw.com, we don’t do video production or even really have writers on staff. But we can work with your existing content and help you create content templates for that so that you can write your own content. Again, the really content heavy, marketing-type sites we do, but really the strength of UX is in the more complicated tools and web applications and facilitating those complex interactions across platforms. That’s where our UX team really shines.

    So what do we do? We design interactions. There’re a few things that you bring to the table. You bring your assets, you bring your brand, you bring your goals and we help you identify the constraints, which is a topic we’re going to get into here in a second. All that translates to an interactive experience. So, just to touch on designing for constraints – constraints, if you talk to any designer, are one of the most important things in the design field because they limit the solution space. When a designer sits down at the blank canvas it’s really intimidating and constraints help focus your ideas. As things are getting more complex in the interactive world constraints are becoming a lot more important because platforms have different capabilities, there’s all these new integration points with social systems and things like that.

    The first is Physical Device Constraints. Web applications are becoming more ubiquitous. It’s really common to have something run on your laptop and your phone and your tablet, but there’re considerations to be made for that to actually work. You’ve got viewport constraints, liquid layouts, things like that. In the mobile space it’s really important too because – just look at Android phones for example – you’ve got hundreds of different models with different screen sizes and some have keyboards, some have touch screens. We understand the hardware enough to design towards those physical constraints.

    Integration Constraints - You may have heard the word API thrown around it’s kind of a hot term in web development. An API is an Application Programming Interface. Essentially it’s a channel for your application to communicate with another application’s data. Probably the most popular example of that is Facebook. If you want to integrate a commenting system on your blog that ties in with Facebook, or you want to integrate with Salesforce.com or your ERP system when people submit leads on your site, these are all integration points. The only way to know what’s possible integrating between systems is to understand the API level. Having our developers is really helpful for us to figure out we can to do in terms of systems integration.

    Software Constraints is a big one. Like I said before, the browser is a constraint - between Chrome, Firefox, Internet Explorer, all the different mobile operating systems. All of these software systems have specific constraints. Something as silly as “Hey I want to make these buttons blue on the iPhone,” we go run that by our iPhone developer and they’d say “well, we have to customize. There’s a default GUI component if you want to do it blue but if you want to do it green, we can use this right out of the box.” So the capabilities of the actual user interface tools within the software are going to dictate what’s easiest and most cost effective to develop.

    Another one is User Constraints. Who are your users? Are they little kids? Are they old people? Are they blind people? Knowing your audience is going to dictate how your interface looks.

    The other constraint is Budget. What can we do with the amount of money you have to spend on your application? Our process is really flexible; we’re able to tailor that to just about any budget.

    The Nerdery is primarily known for development, and that’s true. We have, I don’t know, 150? I can’t even keep track of that number anymore.

    Matt: 100+ is what we always say. Out of the 200 people most of them, probably 75%, are developers.

    Mike: So we’ve got upwards of 150 developers in all disciplines of web development: Python, Java, PHP, Ruby, .NET, iOS, Frontend developers that can do jQuery, Prototype, MooTools, everything you can think of. Even ColdFusion.

    Nick: All the way back to IE6

    Mike: All the way back to IE6. So what that gives us is a wealth of knowledge to tap into. That’s really what makes our team unique here at The Nerdery. Our UX team is immersed in technology every day. We don’t design in a vacuum. As we’re going through the design process we’re always bringing developers in to assess the feasibility of the things we’re coming up with to come up with new ideas to give us opportunities to move forward. We talked about software constraints. There really are a ton of different constraints depending on which platform you want to go into. As a web development shop, we’re also a consultancy. You don’t need to understand technology necessarily. When you come to us if you say, “we want this done in Drupal,” that’s fine. We can do that in Drupal. What we’d like to do, though, is pick a technology that fits to the solution that we’re designing. If we’re starting from scratch and you don’t have any technology picked out we can actually decide on the technology: “Hey, this would be cheaper to do in WordPress” or “Let’s just do a custom using CodeIgniter” or “Since you have e-commerce capabilities we can use Magento. It has a lot of e-commerce stuff out of the box.” Knowledge of all those different platforms within specific languages gives us the power to recommend specific technologies that best fulfill the design

    Matt: Just to jump in right there real quick – we did another webinar. We actually have a team here, we call them Solutions Engineers, and you come to us with your PQR and we have our Solutions Engineer team review that stuff and they’ll actually be some of the people that help you make some of these decisions early on.

    Nick: What’s really important to get out of this is that not only are we recommending specific platforms but we can better compare and contrast the different platforms based on the solution. Really, what we want to do is make sure that the technology recommendations follow your business requirements and also are going to meet your user needs and your long-term strategy.

    Matt: If you want to learn more about our Solutions Engineer role go to blog.nerdery.com. We’ve done a previous interactive primer titled “Requirements Gathering” and it’s all about the Solutions Engineer process so check that out if you’re interested.

    Mike: Cost, money, this is obviously a big one in the web development world. You guys might be familiar with iron triangle; well this is the golden triangle. There’re really three sides on the triangle of any project: How much you want to pay, the cost, how many features you want to implement, which we refer to as the scope, and when you want it done, which is the timeline. The way this works is you can’t have all three. Essentially, as one or two sides move, the other sides have to move as well. So, as an example, if you want to increase the scope of the project it’s probably going to increase the cost and push the timeline out. If you want to reduce the cost, then we have to reduce the scope. All these things follow each other and technology is notoriously expensive with custom technology but we have ways to limit that. The user experience process is actually designed to help limit scope. One of the things that we are really striving to do during the upfront, initial sales and UX process is put a gate around what you’re trying to do specifically, get down to the nitty gritty requirements. As development progresses it becomes more and more expensive to make changes. Just to use a really simple analogy, let’s say you’re building a house and you hired us to be the architects. We created a blueprint for your house and you said “yes, this is perfect, let’s go and build the house.” As you’re building the house, the sheetrock’s going up and the windows are going in, you realize “oh, you put the window on the wrong wall.” At that point the builders, in this case, have to rip the window out, they have to bash a hole in the other wall and they have to move the window. You can see how that can get pretty expensive. Now, if you would have just talked to the architect during the architecture phase of the project they could have just erased the window on the blueprint and drawn one on the other side of the house. We like to think of ourselves as architects in the same way. We want to maximize changes in the UX phase in order to minimize cost and changes during the development phase of the project.

    Nick: Our UX process: We have kind of four pillars of UX. We try to talk about them more in the term of phases than process because it’s not that you have to go through every step but in each phase we have different tools that we use to make sure that we’re up to speed and in alignment with the business objectives of your company and also making sure that we’re aligning those needs of the users. Our four phases are Project Definition, User Research, Information Architecture and Visual Design. We have this broken down into some of the different tools and things that we use as we go through this. This is just an example of what our UX plans look like. The Project Definition phase will consist of creating a plan, doing stakeholder interviews, doing process flows/use cases, mental maps, doing some heuristic analysis and audits of the current site. During that research phase, depending on what’s needed, we’re going out doing surveys, testing, focus groups, user interviews and creating user personas to make sure that we understand what the users are trying to do, what their motivations and scenarios are. Then moving into the Information Architecture phase, where we’re really aligning all those business objectives/business needs that we figured out in the definition phase and aligning them with the users and coming up with that information architecture which traditionally consists of wireframes and site maps. This is also where we can introduce prototyping and do some of those things. Finally, in that last phase, we’re getting to the point where we’ve got sign off on the wireframes, we understand all the interaction points for your website and your experience and now we’re putting on the visual dressing and making sure that we understand what’s going to create that experience from a visual standpoint. So, going through our story boarding, and mood boards if needed, and basically producing the actual visual design and style guide, kind of call it an interactive style guide, what the developers need to actually produce that website.

    Mike: The point of the UX plan is, what you’re seeing on the screen right now is like a playbook of all the different deliverables and processes that we can apply to your project. Realistically, we would only choose a subset of these processes to apply to your project depending on your budget, and also depending on what you bring to the table. If you have a bunch of market research that you’ve acquired from a 3rd party research company or you’ve done that on your own we’re not going to go and redo all that work. The UX plan is basically a document that we create after we meet with you, looking at your hours. We essentially figure out how we want to break up your project and which processes we want to apply to it. Some of that’s going to be done in the Solutions Engineer phase when you first engage with our company but we’re going to take that initial allotment and really refine it and come up with a plan that going to tell you what we’re doing, why we’re doing it, and when it’s going to be done by. That’s what we call the UX plan.

    Matt: Got a question from the audience here. What is content mapping and how is it different from the site map?

    Mike: Content mapping is essentially when you design a web site without content first. A lot of times we won't have content at the beginning of the project. The content mapping process is essentially a document for developers or someone that is implementing a content management system that maps specific blocks of content to specific templates in an information architecture. If you have these wireframes that are all greeked out with lorem ipsum and different content blocks reserved but you haven’t actually specified which content’s going to be there, the content map would say this piece of content goes in to this template and this piece of content goes into to this template. That is essentially what that is.

    So the first phase, Project Definition. There’re a lot of things we do in this phase. Really the point of the Project Definition phase is to get a clear handle on what the requirements are and get all the stakeholders into agreement. This phase is really a lot of meetings and a lot of face-to-face time, talking through your business and your goals and what you want to do. We have this activity called a Mental Map, which is just a brainstorming activity that helps us get all the requirements out. One of the things we’ll do is, as requirements come in that aren’t necessarily estimated for during that scoping process, we will put them in a pink note just to track them but also to say this is outside of the scope of your budget. It’s something we can phase in. We like to create phase plans, depending on what your budget and time line is. We will try to get as much of your requirements in as we can during the first phase of the project but really that’s a function of the prioritization. What are the most important core attributes of your application that needs to go in and how can we do that with that first block of money? The rest of the stuff can come later.

    Nick: It really helps us set up the course for the rest of the project and identifying where the tools that we are going to use as we continue to move throughout, which really segues into our next line.

    Mike: User Research - This is not a part of your project, but user research can be really important. There are two groups of thought here, there’s the quick and dirty user research techniques which actually aren’t that expensive. Basically, testing prototypes in front of real people, testing information architectures, can you find a product in this categorization? Bringing real users into the design process, engaging their feedback. We can do that really cheaply through surveys and things like that. The more formal, more expensive side is focus groups, the behind the smoked glass type stuff. We can do that as well. We don't have the facilities here but we do have partners, and we can help moderate those sessions as well.

    Nick: The truth about user research, whether you’re going out and actually interviewing people or not, is that you really want to make sure that both your design team, your UX team and the stakeholders understand what the motivations are behind the users. How are they trying to use the site? Why are they trying to use the site? What are those scenarios and features that they really need? So that as you come out of the user research phase you really understand what are the core features that need to be built and designed. That way you’re not over building and that way you’re not under building so that you can meet those business objectives and meet your user’s expectations.

    Mike: One of the tools we use a lot in user research is called a persona. You might have heard of this but essentially a persona is representation of a specific user group that you may have. You may have thousands and thousands of users on you site but if you actually analyze the behavior and motivations of all those different users you will find that groups of people have similar attributes and we’re able to identify patterns in those groups and assemble them into what we call personas. These personas basically just generalize the motivations and needs and demographics, scenarios of a specific type of user. We use this during the design process. It‘s kind of a tool of empathy for our designers to say, “What would Gary Hartman do in this situation?” It’s been really powerful for us. Another simple technique that we can use is just looking at analytics. That’s really the most granular form of user behavior is where your users are clicking on your site, where they’re going. If you’re doing a redesign of your site, looking at your analytics can be really helpful. We can see where people are leaving; we can see where people are bouncing out of the conversion funnels that you’ve set up. We can see the important content of your site. We can look at that and compare it to the information architecture you’ve set up and say, “Your users think that your ‘contact us’ page is the most important part of your site but you’ve got it buried four levels deep in your information architecture,” help bring that stuff in to alignment.

    Nick: This is really helpful if you haven’t gone out and done any formal target audience or demographic research. This can help us fill out those personas with out having that specific detailed information.

    Mike: Information Architecture is a really important phase. This is really the blue print phase. When people think of information architecture sometimes they think of wireframes. Wireframes are a big part of information architecture but there is a lot more to IA. I brought up the product categorization example. Information architecture is really all about organizing information. Websites and applications are becoming more complex. There’s more data, there’s more information and there’re more screens. There is a lot more need for organization of your interactions, layouts, content, navigation. Findability is super important, how does your user get to your information in the easiest way possible? This is all accomplished in the information architecture phase.

    Nick: People are going to get to your site via Google but once they get off of Google they don't want to be using Google to navigate your website. They want to find it on your site.

    Mike: There are different levels of prototyping that we do here. Low fidelity prototypes or simple sketching is a really cheap and fast way to do prototyping. We often do this anyway, even if it’s not a final deliverable. Essentially we can sketch all these interface elements and cut them out and assemble them on a piece of paper and take pictures of them. You can put that in front of users really quick and see how they react to it. That is the cheapest kind of prototyping we do. The most common is the static prototyping, which is basically what you see in the middle here, which is the annotated static wireframe. The most expensive form of prototyping we do is interactive prototyping, which is a step up from the static wireframes. It’s really just a clickable interactive version of your applications but it’s not going to have your visual design aspects, just the bare minimum interactive aspects to it. There are pros and cons to all these things. It’s really is how much you want to spend on it and who your audience is. A lot of people come to us and they have an idea they want to develop but they’re presenting it to their investors. In that case maybe an interactive course might be better. They can put it in front of investors and get money to do that next phase. All three of these are really effective in communicating the interactivity before you get to the visual design phase.

    The final phase of our design process is Visual Design. This really is the final layer on our application. We take the information architecture, we take the wire frames, we take your brand, and your design constraints and your logo and your colors and your style guide and we basically just merge those together. We work with a lot of agencies as well that do visual design. We’ve engaged with agencies in a lot of different ways. One of those is let us do the information architecture for your application. You want to design a Facebook application but you don't understand the Facebook API? That’s perfect. We can do the information architecture for you, we can show you all the interactions and you can take those wireframes and apply the visual design. Back to the project DNA concept that I started the slides with, we can engage on all different levels within this UX process. You want us to do wireframes? You can do visual design. That works perfect for us. Or you have a user research firm; you just want us to help come up with a scope document with the project requirements? We can do that too. We are really flexible. We can take it in to end or we can work with you however you see fit.

    Nick: I think what’s really important to convey too is that through each of these phases we have a very collaborative process here. In each phase we’re working with you to make sure that we’re constantly moving in the right direction, reviewing, making sure that we’re continuously checking that iron triangle. Our developers are in the meetings with us to make that sure we’re staying within the technical constraints. We’re crosschecking with the stakeholders to make sure that we’re in alignment with the business needs and objectives. Then, that whole time, we’re kind of there taking that user-centered design process and making sure that we’re reducing the barriers to make the most fulfilling experience. Even coming at the end with that visual design phase and making sure that this experience is going to work really really well; it’s going to meet the brand and identity requirements and, most importantly, that we have created a really usable design experience.

    Mike: One more thing to touch on before we wrap up here, half of my visual designers are also frontend developers. For those of you not familiar with the terminology, a frontend developer essentially takes the design and translates it to HTML and CSS for the browser. This gives us the ability to design for the web. For those of you that are coming from a print background, you probably understand what I'm talking about. There are a lot of inherent constraints in designing for the web, which we’re intimately familiar with. Expandable content, tiling, graphics, typographic limitations, using font replacement technologies, all that stuff we use to form our design to make sure that it’s not only compatible with older browsers but compatible with future browsers, and that it will reach the hugest audience possible.

    Matt: That basically wraps up the presentation but if you guys have any questions feel free to send them in any of those three ways: using the GoToMeeting app, send them on Twitter @The_Nerdery or you can send us an email at primers@nerdery.com. While we will wait a few seconds for questions to come in, I want to stress one thing. After you leave the presentation you’ll be presented with some questions on how did we do today, way the information useful, etc. The most important question on there is “what do you want to hear us talk about next?” The interactive primers are to serve you guys so if you have some question on, let’s say, Facebook comes out with something new next month and you want to know what this new technology is, feel free to send an email to that primers@nerdery.com at any time and we can put together a presentation for it. With 100+ developers we all know what’s going on and what’s new.

    Nick: Or you want to know more about contact strategy, or rapid prototyping, or guerilla usability testing.

    Matt: Or if there’s something you heard today, and let’s say you were the only one from your company that could make it today and you thought this was great information you can contact us at primer@nerdery.com and we could do this presentation privately for your company.

    Nick: We make house calls.

    Matt: We actually did one last month for the Facebook one. We sent some people out. All right, we’ve got a few questions here. What if we already have designers, which most agencies are going to, how can your UX team help us?

    Mike: I think it goes back to understanding technical constraints. A lot of designers come from more of the advertising world and they’re really good visual and emotional communicators but not necessarily deep into the techno-babble that we are here. So we can slay visual designers into our process from your team by doing the information architecture phase and helping them understand the constraints and limitations of the systems before they start visual design process. I think that’s the simplest answer.

    Nick: A lot of what we see coming from many of our clients is we have a concept, we mocked up a couple screens, and inevitably there are interactions and screens that are missing and need to be fleshed out. That’s something that we can do we can do really efficiently here, help you work through your processes, your user interactions and make sure that stuff gets figured out. Inevitably, when it gets into development, those screens are going to have to be designed and, going back to that maximum and minimizing changes in the development process, we can help figure that stuff out while everything’s still in the paper mode.

    Matt: Which leads us perfectly to the next question. So what if we’ve already done our design or may be even have our wireframes? Is there something you guys can still come in and help out with?

    Mike: We do something that’s, it’s basically consulting, but we call it UX Documentation Intake. If you’re planning on developing at The Nerdery or if you just want a second pair of eyes on it we can actually review the designs with the developers in whatever specific technology that you’re trying to develop in and get their feedback. They’re going to tell you “Hey, this is really expensive to do in Drupal” or “Hey, there’s a plugin that does this in WordPress. If you just modify a few form fields it’ll work right out of the box.” Or if you want to get a quick estimate for development we can do that too. If you just have a few screens and you want someone to do production on the rest of the screens we can do that as well.

    Matt: Is there anything you want to add that maybe wasn’t in the slides?

    Mike: No. Like Matt said, just send us an email. We’re happy to talk more about this stuff. Everyone at The Nerdery is super passionate about this stuff. It’s something we’re working on every day, trying to get better. We love to share it with everyone, clients, partners, competitors. Just hit up Matt or go to our website for more information. Hopefully we’ll talk to you guys soon.

    Matt: It doesn’t look like we have any more questions. Like I said at the beginning of the broadcast, we’ve been recording this and it will be posted on our blog sometime next week. That wraps it up. Thank you for tuning in and hope see you next month.

    # vimeo.com/22461237 Uploaded 5,526 Plays 0 Comments
  2. Just over a minute showing how you can use Kickstrap to rapidly build feature-rich sites. Download Kickstrap at getkickstrap.com

    # vimeo.com/55423707 Uploaded 21.9K Plays 0 Comments
  3. In this screencast I give a basic introduction to bootstrapping a new Backbone.js application and go into detail on how to use views.

    # vimeo.com/27723557 Uploaded 19.8K Plays 10 Comments
  4. This video will teach you how to create websites with KISSr.co using HTML

    # vimeo.com/42097891 Uploaded 5,654 Plays 2 Comments
  5. Generate your own interactive website from scratch with Bootstrap, the mobile-friendly framework from Twitter, in this start-to-finish course with developer and author Ray Villalobos. First, you'll plan and prototype the interface with MindMaps and Balsamiq Mockups. Next, download Bootstrap and dive into organizing your site structure with its scaffolding feature—adding PHP includes to break your code into reusable modules and building in the core navigation. Ray then shows you how to build interactive carousels, modal features, and forms, and control these features with JavaScript. Finally, learn to style it all with LESS and prepare to publish the results online.

    Learn more gfxdownload.ws/tutorials/bootstrap-3-advanced-web-development-with-ray-villalobos.html

    # vimeo.com/72324846 Uploaded 147 Plays 0 Comments


Immanuel Sun

Browse This Channel

Shout Box

Channels are a simple, beautiful way to showcase and watch videos. Browse more Channels.