@jboogie

Brief

Traditionally User Experience Design has been a deliverables practice. Wireframes, sitemaps, flow diagrams, content inventories, taxonomies and “The Spec” defined the practice of UX Designers (IxD, UX Design, whatever, etc). While this work has helped define what UX Designers do and the value our work brings to the business, it has also put us in the deliverables business – measured and compensated for the depth and breadth of our deliverables (instead of the quality and success of the experiences we design). Enter Lean UX. Inspired by Lean Product and Agile development theories, Lean UX is the practice of bringing the true nature of our work to light faster, with less emphasis on deliverables and greater focus on the actual experience being designed. This talk will explore how Lean UX manifests in terms of process, communication, documentation and team interaction. In addition, we’ll take a look at how this philosophical shift can take root in any environment from large corporation to interactive agencies to startups.

began with IA, IA didn’t have any artifacts to demonstrate value. Enter deliverables (wireframes, sitemaps, flow diagrams, etc.). Helped define the practice. Now we are drowning in deliverables and are they getting in the way/hiding the true value of ux/ia (outcome experience/product)? Focus on actual experience being designed/developed.

• Concept
• Prototype
• Validate (internally)
• Test (externally)
• Observe user behavior
• Iterate

This just gets an idea out there quickly. How do you know you have a good product? How do you know it’s an improvement beyond what is already out there? Seems to rely on verbal feedback which is suspect. This is just a (design) slice in a larger process.

Brief

This session is sponsored by Adobe.

DreamWeaver

Adobe is starting to incorporate and contributing to jQuery Mobile and WebKit.

CSS transform, webkit box shadows/borders.
CSS media queries (select css by screen size). max-width, min-width mapped to separate css files.

Dreamweaver: Multiscreen preview. Viewport sizes (different resolutions for mobile, tablet, desktop). Map media queries to screen sizes. Force devices to report actual width. Allows you to design for desktop and then carve from there. Getting to a mobile “web app” very quickly.

Links

• jQuery Mobile
• Browser Lab — hosted browser previews. Onion skin overlays between browsers.

Flash

Uses Flash (ActionScript) to write native device applications. AIR for iOS. AIR for Android. Code snippets to interact with device features (drag-n-drop code).

@jmspool
@uie

Brief

What separates a good design from a bad design are the decisions that the designer made. Jared will explore the five styles of design decisions, showing you when gut instinct produces the right results and when designers need to look to more user-focused research. You’ll see how informed decisions play out against rule-based techniques, such as guidelines and templates. And Jared will show you the latest research showing how to hire great decision makers and find opportunities that match your style. Of course, Jared will use his unforgettable presentation style to deliver an extremely entertaining and informative presentation.

How designers make decisions. Gray’s Anatomy (Henry Gray / James Carter) described every part of the human body. We’re missing a lot of (UI) design language. Anatomy: a study of the structure or internal workings of something.

Language of Design Decisions

The choices we make take the design in a certain direction. We can say “Great” or “Horrid”…

Styles of Design

Every style has a purpose/place/usage. Great designers are aware of which style they are using and use the same style throughout the entire project (decided the style up front). Everyone on a design team uses the same style. Higher up the style path, the more expensive it gets (be sure to allocate the budget required). External agencies can’t go beyond Genius design style. Internal design can take it to Activity and Experience-focused level. The style path is organized from least advance to more advanced, and user satisfaction grows along this path.

Unintentional Design

Focusing on the architecture (organization?) instead of what we’re trying to build; happens on its own. This works as long as our users will put up with whatever we give them (few usage or intense training), and we don’t care about support/training costs or pain from frustration.

Self Design

Designing something for our own use. This works as long as there are a ton of users just like you, and you regularly use it like your users do.

Genius Design

Designing for users beyond ourselves. Expert-based design? What we’ve learned previously about user needs. This works when we know their knowledge, needs, etc. based on research.

Activity-focused Design

Designing for users/activities we’ve never researched before. We make lists (Users, Tasks). This works when we can easily identify users/tasks, we have to get beyond our previous experience, etc.

Experience-focused Design

Designing for what happens between activities that sums up the entire experience. This works when we can be pro-active, and game-changing is the priority. What is it like to be , ? What are the different contexts?

Making decisions

“Bitches under Trees”

Templates and site guidelines “the rules” don’t work. Design style guides don’t work. Rule–based decisions are the opposite of informed decisions. We’ve been trying to prevent thinking while at the same time trying to build a community of “committed content authors”. Design wants thinking. It requires content authors to think. Content authors (even in a CMS) are designers because there’s still that body box. Since you can’t build a guide with all rules for all situations, when the rules don’t apply you get crap.

Rule-based Decisions: Style Guides.

Informed Decisions: Design Patterns. This is what we’ve done and this is the stuff that worked. Pro-active education.

The path to experience design:

1. Eat your own dog food
2. Start doing usability testing
3. Do field studies
4. Create Personas and Patterns

Journey to the Center of Design

Process: If you ever got something done, you must have had a process. Methodology means taking things and making them repeatable. Dogma. Techniques are skills that require practice. Tricks are misused techniques/tools that gets the job done.

Teaching people how to measure and observe to make an informed decision.

The entire team watches someone use the design every 2 weeks.

Resume that shows what kind of designer you are: What types of decisions do you make? Tell the story of your decisions.

@rhjr

Experience Strategy

Company realizes they have a bad product or service. Where are our pain points? Or are we at a point of stagnation? “The dip”. What are current usage patterns?

Case: Entry: search engine, Landing: content page, Exit: high bounce rate.

Companies usually approach this in reverse order, but should instead start with step 1.

1. Step 5. Measure — Acquisition, Conversion, Engagement (do you keep people around?), Satisfaction (do they like you/vocal?). You can iterate: watch the metrics and adjust, repeat. The things you measure to determine success. The things that mean success.
2. Step 4. Implement — Produce! Start using the app yourself. Maintain partnership with the developers. Test.
3. Step 3. Plan — Identify the problems, figure out constraints (shape your approach), prototype. Design from the end goal/ideal, then plan your way to that goal with available resources. Test.
4. Step 2. Define — “The Big Think”.The target. The vision for the user experience that must be communicated well.. Expression of why this matters (in the context of business strategy). “@simonsinek Purpose is not derived from products. Products are developed as a result of the purpose. The clearer the purpose, the better the products.” “Having a higher purpose keeps the team focused on what matters.” Start with the stories from your audience (and your team) and your co-horts. Learn their problems, seek out the common beliefs and condense to a single paragraph or sentence.
5. Step 1. Audit — Take inventory. What are things like there? Primary tasks? Secondary tasks? Competitive difference? Problems? Obstacles? Pain points?

“Production Mode: fix all your problems by writing more code without design concept re-work.” So many decisions get made at the code level, has a huge impact on initial design. This is why fast prototyping and design/developer partnerships are critical. Use your application yourself.

“If you implement changes without first designing, you will come back to rebuild and rethink eventually.”

The moment you realize that it is time to step back is the moment you have gotten to the really important part of the UX strategy process.

“Why does it matter? Why do you do what you do? Why do you care? Why this problem/purpose?” How does this design/project support that? Makes all the other decisions make sense and be much easier because everyone knows where they are going and why throughout the entire team. Without it, everything you are doing is a guess.

Step 2 Deliverable: Vision onesheet — fit onto two sides of a piece of paper. ALl the information about your strategy and user experience vision in one document. They’re short, bulleted, and get read all the time.

Books/Articles

• How to sell design and influence people, Hoekman
• World’s easiest way to critique a design — What is the one thing you want people to do?
• Designing the Obvious, Hoekman, Jr.
• User experience tools, tricks, and techniques, learnable.com
• Creating great design principles, Jared Spool
• Design Principles bookmarks

@jsoltero — vmware dude!
@cote
@petercoffee

Brief

After many years there now appears to be agreement from traditional software vendors to web-based companies that we are now shifting from the desktop to the cloud. Is there truly harmony in the industry or are there still disagreements over how the cloud is delivered and utilized? This panel of cloud pioneers and experts will debate the state of cloud computing and where its future lies. Where does the cloud stand for consumers vs. the enterprise? How do mobile, social and open trends impact the cloud? And what is the future of the cloud – will one cloud win out over all others or will there be seamless data sharing across multiple clouds of a customer’s choice?

“Cathedral built out of toothpicks in your data center.”

Collection of services. Private / hybrid clouds exist as bridges from local data center to services. There must be some duplication of service. Lock-in: Public? Private? Closed? Hybrid? “You can have an app in the marketplace 2 months from now that looks great, runs great, user’s love.”

When to use clouds?

The elephant in the room: storing critical business data in a place that you didn’t have physical access without mix or sharing with competitors. “Can’t let go” cos of regulation? “Can’t store this in the cloud” == tax payer / SSN numbers out in the cloud. Then have anonymous customer id in the cloud and the “mapping” tables back in your data center.

Consumerization of IT

Cloud has been driven by the “everywhere” of consumer apps like twitter, facebook, apple. Where are the great apps? Not in the enterprise data center anymore.

@bokardo
@performable

Brief

For every design change you make affecting your user’s experience, do you know if you’re having a positive or negative impact? Are you adding to your organization’s bottom line or eroding it? Are you sure? Or, are you like most design teams who release work through a ramshackle process made up of politics, prayer, and paralysis? The health of the business must be the highest priority for designers. With a plethora of fast and cheap analytics tools available that bring us the ability to measure almost anything, we have no excuse not to be measuring every design change we make. From a/b testing small interface tweaks to measuring time-on-site for new users to measuring user satisfaction over long time periods, we can know more about the people who use our software than ever before. In this talk, Joshua Porter will provide you with a simple, easy framework for metrics-driven design. By using a combination of research methods as well as powerful new tracking tools, Josh will show you how to align your design priorities with what keeps you in business. You will come away from this talk with a clear idea of what metrics are most important, which ones to focus on, and which ones to ignore. So don’t drive blindly: use metrics-driven design to make sure the impact you’re having is a positive one.

Metrics for Designers

Data driven design. testing optimizes to a local maxima (best in current model). intuition driven design creates new maxima (next better design). cycle through both phases. 1) ideation 2) optimization. 3) iterate.

• reduce opinion arguments
• answers about what works (w/ valid data)
• show your strengths and weaknesses (visual designers are not necessarily interaction designers)
• test anything you want
• metrics let you show the most effective choice to clients

metrics can be as unique as your business is unique.

GA not so great for design decisions. metrics have to be actionable.

The Usage Lifecycle

interested. trial. customer. passionate customer (vocal fan).

hurdles: acquisition. conversion. engagement. satisfaction.

metrics measure how well you move people past these hurdles. CPA > LTV = bad.

@waxpraxis
@emilylewis
@eklimcz
@rickbarraza
@tommylee

Brief

Wired declared Web 3.0 the age of apps and that the Web was dead and the future is native apps. Insight or naiveté? We’ll discuss the current merits of HTML5, and which companies and technologies will accelerate its adoption among mainstream consumers and create new opportunities for developers. We’ll also discuss the impact this can have on current native application strategies for Windows, Windows Phone 7, Mac, iPhone/iPad, and Android by looking at the impressive work that is being done today with the Web and apps to deliver compelling consumer experiences. But we’ll also address the shortcomings and the reality of HTML and what Web and app designers and developers can and should be doing today. This session is sponsored by Microsoft.

app or browser? app for specific premium content. web for commodity? identified v. anonymous?

“semantic markup arsenal”

“rich Internet application” “intersection of design and technology”

are we looking for solutions that no longer need web tools? is the web the lowest common denominator/default? does html5 bridge the gap?

progressively enhance content starts with web (documents). if you are building interaction and not content go app?

html5 : more support for semantic machine readability. more elements to work with. content. not a technology stack.

object/seeking perspective v. action/task(environment) perspective.

• @karlnieb
• @krismet
• @agileisbroken

Brief

Agile is broken. How can designers help deliver products that users will love while grappling with the constraints of agile in corporations? With large companies rapidly adopting agile methods, it is crucial that these teams include designers to create great products. But the agile framework available to larger companies doesn’t take into account the work style of design team members. Agile, by its nature, shortcuts the design process without considering the value that design brings, not only in providing on-the-fly design solutions but also when crafting the vision of a product that the team can build towards. We are designers with agile team experience in the corporate world. These are our stories of triumph and tragedy. Come hear what worked for us and share your own war stories.

Agile wasn’t created with design practices in mind. It was about developers figuring out quick solutions and pushing out code as fast as possible. Innovation projects are off release schedules/calendars. Modern software needs design (because we’re no longer bounded by what the technology can do, we are more and more concerned with how and how well it can do it).

Attempt #1: Design up front (Waterfall)

The problem with doing design first and only developing in agile is there is no collaboration on what is possible, no “working design”, and it’s a blackbox/silo’d design. It’s still waterfall and doesn’t count. Pro: Certainty in design boundaries. Cons: Design can’t respond to change based on testing/new information. A good team doesn’t have conversations like “well, we did our job, it’s your problem now.”

Attempt #2: Design at the beginning of each sprint (Mini-waterfalls)

All the same problems of waterfall, but in every single sprint. Not all design problems can be solved within the timeframe of a sprint. There is no chance to re-think.

Attempt #3: Design working in front of Development (Just in Time)

Finds a compromise between doing all design in advance and doing design in each sprint. Places design 2 sprints ahead of developers, who play catch up. Seen as best practice. Still means you can’t foresee tech issues in design ideas. The farther ahead design is beyond developers, the less agility you have because of colliding processes/splintered design focus (inefficient time usage). Testing is too late to respond to development issues.

Attempt #4: Design Sprints

The entire team needs to be involved in the design process (communication and buy-in). It’s more fun to solve problems together. Every few sprints (release/milestones), bring entire team together to collaborate on vision/strategy and come up with a framework. Felt like we were pulling people away from their work to talk about someone else’s work. Disruptive: tends to throw off the developer rhythm. Risk of team members getting poached because they are in a “down sprint” when the team shifts back to vision/framework collaborations.

Attempt #5: Designer/developer partnerships (Fused Innovation)

The partners speak each other’s professional language and should be located physically near each other. You’re effectively re-creating the JOAT but as a team. It means that developers are constantly explaining capabilities to designers, and designers are finding new ways to solve problems. Starts to break down the inherent project prioritization/gatekeeping of developers over designers. Also breaks down the diva designer whose designs are unassailable. When everyone gets involved, you have more opinions on the table but more opportunity to unify opinion. This is where early vision articulation is key. Brainstorming can get both on same page early, meaning prototypes are built while sketches are solidifying (side-by-side). Then you are watching each other the whole time, and share what you’ve learned/done (good ideas and happy accidents). Iterate quickly and fail faster. You can’t know the perfect design before you start testing, so this gets you to testable faster.

So how do teams get to this level of “bonded bliss”?

Original Principles of Agile

Make a crucible of innovation. Emphasize individuals and interactions over process. Make working code. Responding to change instead of only following a set plan. Teams aren’t assembly lines, rekindle the engaged collaborative feel of a startup team.

Rules of Engagement

1. Create and share a vision with all team members and make sure they can agree with the goals (multi-disciplinary)
2. Designer: Engage the team to keep the team on track with the big picture
3. Get stakeholder buy-in on this process; acknowledge risk and high potential for reward
4. Use working prototypes to keep the rest of the business informed on progress
5. Sit together (physically close working environments; work on a single project at a time)
6. Communicate regularly
7. Get out of the way and be accountable for your work

• @joemccann

Brief

HTML5 is no question the “buzzword du jour” in tech nowadays, but looking past the vernacular cruft one will discover that the HTML5 technology STACK is actually an incredibly powerful & useful framework for apps well beyond the traditional web browser. Massive companies like Google and Hewlett Packard are placing huge bets on the future of “HTML5 App development”. From HP/Palm’s WebOS to be used in their mobility products to Google’s Chrome OS, HTML5 is not simply another buzzword that can be treated as a mere passing trend, but should actually be taken seriously for app development. But what makes up the HTML5 stack and how will it truly be the future of software? What are the benefits & risks associated with using the HTML5 stack? Prove to me it works. All of these questions & demands will be answered & showcased in the presentation including important issues such as: What constitutes the HTML5 stack Benefits of using the HTML5 stack Use a single codebase Rapidly prototype an app targetting multiple devices including: iPhone, iPad, Android Devices, Chrome OS Devices, Mobile Webkit Browsers, Desktop Browsers Target thousands of developers for extensibility & community development See code & install an actual working HTML5 app that works on a number of devices See code best practices in use for tailoring the UI based on the user’s device See code using Phonegap to create native mobile apps See code using Titanium to create native desktop apps

Web as a Platform

• Content: the HTML doc itself
• Style: the CSS3
• Business Logic: JavaScript

JS gives you access to geolocation, local storage, web workers, etc. The web stack has a much smaller development (language) and design (artifacts) skill and maintenance footprint.

Tools

• Phonegap — write web apps for native mobile applications. JS bindings to native device libraries. build.phonegap.com (automated build of different device app versions).
• Sencha Touch — development toolkit to create native apps.
• Appcelerator Titanium — native device apps and create native desktop applications (JS bridge).
• jQuery Mobile — (alpha) mobile web applications that gracefully degrades across devices.
• YQL — turns the entire web into an API (screen-scrape that won’t get blocked) that lets you parse any web page and collect it in JSON/etc..
• Node.js — C++ bindings to V8 (Google Chrome) to make highly efficient network applications; server-side JS built on JS. RESTful web services that use common libraries as your desktop (offline) side. I.e., validation of form fields (requires client and server side validation) is exact same code on client as server. This solves the issue of this presentation’s glossing over of server-side code?

Demo

Filesystem

appfolder
- clients
– android (phonegap)
– desktop (titanium)
– web (/key folder/ that other folders symlink to)
— css
— html
— js
- server (Express node.js)
– public (symlink to web)

Demos/Code

Demo: http://freebeernear.me

Responsive design tip: Only load the libraries (jQuery) you need for the screen size a person is using.
Write logic that finds out what kind of framework you are in (phonegap, titanium, etc.) to handle deltas.

Code: http://github.com/joemccann/freebeernearme/

Responsive Design

CSS media queries + fancy JS = same code that’s good for multiple devices and screens.

• A List Apart: Responsive Web Design
• Zeldman: Responsive design is the new black
• A Blog Not Limited

• @paulgelb

Brief

A jaw dropping 80% of iPhone and Android apps have hardly any active users. Tens of thousands of developers and hundreds of thousands of mobile applications have gotten it wrong. But mobile apps done right can provide unprecedented value to users and rapid transformations of businesses. Gilt Groupe, USAA Bank and Pandora can attribute much of their recent success to their mobile applications. The biggest barrier to success? More is absolutely less. As Mark Twain famously said, “It would have been shorter if I had more time.” With seemingly infinite options of features, ‘what’ and ‘how much’ is the hardest part of development. This presentation will provide a detailed unbridled view into the strategy and creative process of creating a compelling, successful mobile app by finding the right balance between business objectives content, design, functionality, and concept.

Mobile: This decade’s battleground

“Channel and connective tissue duality”. WTF. This was a lot of business speak. It was in the Business track; I can only blame myself. Tricked by the words “mobile” and “wizardry”.

This part was extremely useful. Apps should be (figure 1):

• Efficient. Performance and minimal navigation paths, contextualized communication
• Engaging. This is a relationship contact point
• Experiential. Intuitive interface
• Always On. Proactive and notification-driven
• Opportunistic. Leverage the affordances of the device
• Malleable. Should be sustainable over time with new messages/products

figure 1