Sum of the Parts Speaker Series - Experience Engineering and UX

Editor's Notes

• #2: Hello everyone. Thank you Courtney and Carbon 5 for hosting this event and the folks at Autodesk (Eric Fain) who have partnered with Carbon 5 to sponsor this speaker series. It’s a real pleasure for me to be here at Carbon 5 tonight. It’s a nice full-circle moment for me. We engaged Carbon 5 a little over a year ago…that experience opened the door for new ways for our UX team to work. They sort of got the engines started and the car is still running a year later. So it’s great to be back to talk about our experience. This talk is a practical nuts and bolts talk. It’s a case study in how we have integrated experience engineering and its associated tools, process and skills into our team. And the changes that afforded our team through this engagement. Let me tell you a little about what my team does and how we got to where we are now.
• #3: We work on the AutoCAD web product. It’s a one page web app pretty much. CAD drawing in a browser. We have the usual UX suspects: visual designers, interaction designers, researchers, learning designers. And we had a team of developers and we pretty much followed and still follow agile development methodology (the Pivotal flavor). BUT…
• #5: Through my own experience working on web teams I had a pretty good idea we had to be able to solve this. Designers who code is a one way.
• #7: I knew we needed to be able to build some working prototypes but it was almost always impossible to get development resource to dedicate some cycles to something not relevant to the immediate needs of the product. Sometimes you can get those resources, but only on a handful of markee top priorities and with a lot of advanced planning. I knew UX needed to have some role in speeding up the dev process by being able to make edits directly into the code and they also needed to be able to do quick prototypes. So I set out to try to make a change on our team to address this problem. And I stepped right into this controversy.
• #8: Luckily this was not controversial for our team of designers. They dove right in head first – got training. We were getting the skills but having a hard time practicing them in the real code. We also knew we needed a dedicated prototyping resource that was more skilled, but weren’t sure how that person was going to integrate into our team. That’s when we brought in Carbon 5 to help.
• #9: This is where they helped us figure out what the real long-term goal was and what the potential impact for UX and really the whole development team was.
• #11: This is what we came up with.
• #12: So we also looked at what other companies are doing…here’s a few data points that are signposts as we thought about this.
• #13: Now I’d like to step back and talk reflect on what some of the greater UX community thinks about this.
• #14: Now some of you may already be doing this on your teams. Autodesk is a 30 year old desktop company so this sort of “in the wild” prototyping and testing was not really possible and not much on the radar.
• #15: I like that last quote the most about HTML, etc. being a design tool.
• #18: It all comes down to prototyping…which is really just another word for iterating. We all do this and various levels of fidelity from talking, to paper, to click-through prototypes, to high fidelity prototypes Understand technology we’re using: Sometimes the only way to iterate a design is in the actual technology it is being built.
• #19: So we built a prototyping environment. Carbon 5 helped us build a flexible environment and pushed us to have the exact same release and repository process and tools as the “real” code environment. That way we would have the confidence to push real code when it was ready. We also made sure we hosted this “development” server publicly so we could send users to it without any special logins. I won’t go into the details of how this environment was set up, but Carbon 5 helped us build this. It’s a playground for designers, but under the hood, it’s really no different than the environments the developers are working in. Carbon 5 added some bootstrap-like libraries and the good news is that we haven’t had to add any more. Open to public Built on same technology as the production app Uses same deployment tools Uses same code repository process
• #20: So here are the 3 categories of prototyping we do.
• #21: Built by our designers
• #24: 2 day user validation. 1 hour to code/design. An afternoon to set up the test. Runs overnight and results in the morning.
• #25: Here’s an example of a test we did.
• #26: Now that we’re not reliant on PM or SWD to do some of this experimentation…there is actually a gap in those areas knowing what we’re doing. SO we put these up. So that’s how we’re working to get better designs. All of this is lower case experience engineering.
• #27: Now I get into the role of Experience Engineering.
• #28: The previous answer sort of answers this question. By having designers who code (which is really experience engineering), We DO speed up dev process.
• #29: Apologies for any inadvertant stereo typing going on with these avatars. Except for the designers…they really do look like that. These “experience engineering” skills we’ve developed as designers really do help us speed up. They give us more control over where experess. And it builds empathy, BUT to really to optimize this new skill on the UX team is to make this a separate role.
• #33: Keys to making experience engineering a success.
• #38: Just like a potter at the wheel who understands the limits and possibilities of the physical clay they are working with, UX (for web at least) needs to understand the technology they are designing in.