There’s a dirty secret in the turf war between agile, lean, and waterfall: they each use the same product development process. What’s different isn’t their process, but how they apply design activities in different ways to eke out different design value.
So how can you alter the design process? Even better, how can you customize the process to provide more value for the way your organization works? How should you change the design process from sprint to sprint to get the most value out of your design activities?
How do you hack user experience?
In this presentation, learn how to hack UX Zombies to pieces using two tools: models and fidelity. You’ll be introduced to how to control the fidelity of our models, to hack UX for the right design.
BOOM Units: Four steps to turn you team into a lean, product development machineAustin Govella
In the agricultural age, it took 182 years to build Notre Dame cathedral. In the industrial age, it took Bell Labs 22 years to design the push-button telephone. In the design age, you can build big, huge systems as fast as you can connect different frameworks. You no longer have 22 years — much less 182 years. To succeed in the design age, product development has to evolve.
Successful product teams have evolved into something akin to an emergency service:
Triage to identify what needs fixing
Treat acute, urgent problems as quickly and safely as possible
Prescribe actions to prevent future problems
Successful teams launch new products with big impacts quickly like a bomb going off: Boom. Successful teams are B.O.O.M. Units. In this presentation, we’ll examine the four attributes of these high-performing teams:
Balanced teams: activate the talents of every team member
Outcome-focused: teams focus relentlessly on the experience
On-time delivery: each team member delivers their part just-in-time
Maximized impact: team members choose the smallest change that creates the largest impact
To illustrate these behaviors, we’ll look at four stories that show BOOM Units in action, and for each behavior, we’ll look at a tool you can start using when you go back to work on Monday morning.
For developers, UXers, and project managers who want to deliver more innovation, you can transform your team for the inside out into high-performing BOOM Units.
Design is all about value. It helps transfer value from one person to another. Design insures you have an experience: that at the end, you’re different than when you started. Design makes this difference, and like Babbage’s Difference Engine of yore, specific knobs and levers control how much value you can create with design.
In this presentation, we’ll learn how five levers — models, fidelity, audience, annotation, and velocity — work together. We’ll see how agile, lean, and waterfall teams apply these levers differently at different times to create different value from design.
Friday at work, you won’t be able to stop yourself from asking five, simple questions. You’ll be maximizing design value for every project you encounter.
UX + Agile: The Good, The Bad, and The UglyJoshua Randall
There's a rumor going around that user experience (UX) and Agile don't play well together. In this talk, I'll explain that they do -- most of the time! I will draw on my experiences at three large Cleveland companies.
This is the short talk I gave at the beginning of the June 2nd, 2011 meeting of the NYC Agile Experience Design meetup. It is meant to give context to the panel discussion which followed. That consisted of 4 non-designers (dev, product, qa) giving their POV on Lean UX. The full video of that talk is here: http://www.vimeo.com/24638334
Lean UX: Building a shared understanding to get out of the deliverables businessJeff Gothelf
This is the latest iteration of the Lean UX conversation as given at UX LX (Lisbon) in May of 2012. Many thanks to Jeff Patton for the opening imagery.
In this presentation, learn how to hack UX Zombies to pieces using two tools: models and fidelity. You’ll be introduced to how to control the fidelity of our models, to hack UX for the right design.
BOOM Units: Four steps to turn you team into a lean, product development machineAustin Govella
In the agricultural age, it took 182 years to build Notre Dame cathedral. In the industrial age, it took Bell Labs 22 years to design the push-button telephone. In the design age, you can build big, huge systems as fast as you can connect different frameworks. You no longer have 22 years — much less 182 years. To succeed in the design age, product development has to evolve.
Successful product teams have evolved into something akin to an emergency service:
Triage to identify what needs fixing
Treat acute, urgent problems as quickly and safely as possible
Prescribe actions to prevent future problems
Successful teams launch new products with big impacts quickly like a bomb going off: Boom. Successful teams are B.O.O.M. Units. In this presentation, we’ll examine the four attributes of these high-performing teams:
Balanced teams: activate the talents of every team member
Outcome-focused: teams focus relentlessly on the experience
On-time delivery: each team member delivers their part just-in-time
Maximized impact: team members choose the smallest change that creates the largest impact
To illustrate these behaviors, we’ll look at four stories that show BOOM Units in action, and for each behavior, we’ll look at a tool you can start using when you go back to work on Monday morning.
For developers, UXers, and project managers who want to deliver more innovation, you can transform your team for the inside out into high-performing BOOM Units.
Design is all about value. It helps transfer value from one person to another. Design insures you have an experience: that at the end, you’re different than when you started. Design makes this difference, and like Babbage’s Difference Engine of yore, specific knobs and levers control how much value you can create with design.
In this presentation, we’ll learn how five levers — models, fidelity, audience, annotation, and velocity — work together. We’ll see how agile, lean, and waterfall teams apply these levers differently at different times to create different value from design.
Friday at work, you won’t be able to stop yourself from asking five, simple questions. You’ll be maximizing design value for every project you encounter.
UX + Agile: The Good, The Bad, and The UglyJoshua Randall
There's a rumor going around that user experience (UX) and Agile don't play well together. In this talk, I'll explain that they do -- most of the time! I will draw on my experiences at three large Cleveland companies.
This is the short talk I gave at the beginning of the June 2nd, 2011 meeting of the NYC Agile Experience Design meetup. It is meant to give context to the panel discussion which followed. That consisted of 4 non-designers (dev, product, qa) giving their POV on Lean UX. The full video of that talk is here: http://www.vimeo.com/24638334
Lean UX: Building a shared understanding to get out of the deliverables businessJeff Gothelf
This is the latest iteration of the Lean UX conversation as given at UX LX (Lisbon) in May of 2012. Many thanks to Jeff Patton for the opening imagery.
Real World Lessons Using Lean UX (Workshop)Bill Scott
Half Day Workshop given 5/22/2013 at WebVisions Portland.
In this workshop Bill will explore the mindset of LeanUX and how it relates to bring products to life in the midst of big organizations that don't normally think "Lean". He will look at how teams can create a strong partnership between product, design & engineering in a way that tears down the walls and instead focuses on three key principles:
Shared understanding
Deep collaboration
Continuous customer feedback
The workshop will take a look at how Bill has been able to apply Lean UX at PayPal — a place that in recent years has been the total antithesis of the lean startup idea. With very specific examples, he will share lessons learned applying lean to the full product life cycle as well as how it relates to agile development.
Finally, the workshop looks at the technology stack. In the last few years there has been an explosion of open source technology stacks that can support rapidly creating products, launching them to scale and rapidly iterating on them when live. While startups embrace these stacks from the get-go, large organizations struggle with how to embrace this change. This workshop will also look at the shift that has happened, what is driving this change, and how organizations can embrace this stack and how to marry Lean Tech with Lean UX.
Here's a deck I put together for our weekly learning seminar at Verbal+Visual.
Special thanks for General Assembly, my instructors Luke Miller, Rashida White, and Nevan Scott.
http://www.verbalplusvisual.com/interaction-design-rapid-prototyping/
Get hands-on advice for rapid Agile prototyping in a product team.
You'll learn:
- How to determine the right depth and breadth for MVP prototypes.
- How to prioritize use cases for prototyping.
- How to elicit the right stakeholder and user feedback.
- How to correctly annotate prototypes for dev and QA.
An introduction to Lean UX, grounded in Lean Startup and Agile principles. A starting point for shifting today's organizations towards a safer sustainable approach to product design and development.
User Story Mapping for Minimum Lovable Productsuxpin
You'll learn:
How to visualize user needs instead of product features
How to make better decisions when prioritizing a UX backlog
How to align sprints with UX strategy
Design Spikes for the Dual-Track Agile Processuxpin
You'll learn:
How to fit design spikes into a Scrum framework
How to address user stories without neglecting UX strategy
How to solve design problems before they become development issues
Introduction to user experience design + usability
Describe the field of UX + how it relates to other disciplines
Identify the different roles within UX + the responsibilities of each
UX Process: Traditional [“Waterfall”], Agile, Lean
Learn to conduct UX research
Introduction to user experience documentation + deliverables + software
Learn about personas, user flows, sitemaps, wireframes
Determine when to use which documentation
Discover new tools and frameworks for creating deliverables
Introduction to usable web forms
Identify the different elements of forms and how to use them effectively
Learn what makes a strong user experience with forms
Identify expected outcomes
Curated list of UX resources
Recommended blogs, books, experts to follow, companies of note, local organizations and recommended conferences
The JoomlaChicago Loop sponsored "Joomla & Responsive Design", a presentation focused on the key ingredients and dynamics of making a Joomla website flow and react to the different viewing devices and browser viewport sizes.
Dennis Kmetz (Director of Interactive Media, Taylor Bruce Design Partnership) presented Joomla & Responsive Design on Thursday, March 1, 2012.
The experience your customers have with your products is a critical component of success. Valuable products can solve real human needs, fulfill desires, and improve the quality the of life. This goes beyond just building more features, or making things look pretty. It involves understanding and empathizing with your customers, and involving them in the design process.
How do we do this? And how do we do this in a way that fits into the operational rhythms of Agile development? These perspectives are shared by a long-time UX designer who has recently moved into Agile.
About Kazumi Terada
- Available for hire
- Born in Tokyo, Lived in Dallas, Lives in New York. US Citizen. Bilingual.
- Parsons School of Design, BFA in Architecture
- Work Experience: Panasonic, Shutterstock, Vibrant Media, Bertelsmann
- Building websites since the 90’s
- UX Design Immersive Certificate from General Assembly, May 2016
- Co-founder of a design firm and a non-profit
In this deck I explore how design can improve products and industrial processes showing how starting from a radical change in the approach to business, any company could improve not only their own products, but can literally create new needs in their customers and, at the end, new markets and new business potential.
Real World Lessons Using Lean UX (Workshop)Bill Scott
Half Day Workshop given 5/22/2013 at WebVisions Portland.
In this workshop Bill will explore the mindset of LeanUX and how it relates to bring products to life in the midst of big organizations that don't normally think "Lean". He will look at how teams can create a strong partnership between product, design & engineering in a way that tears down the walls and instead focuses on three key principles:
Shared understanding
Deep collaboration
Continuous customer feedback
The workshop will take a look at how Bill has been able to apply Lean UX at PayPal — a place that in recent years has been the total antithesis of the lean startup idea. With very specific examples, he will share lessons learned applying lean to the full product life cycle as well as how it relates to agile development.
Finally, the workshop looks at the technology stack. In the last few years there has been an explosion of open source technology stacks that can support rapidly creating products, launching them to scale and rapidly iterating on them when live. While startups embrace these stacks from the get-go, large organizations struggle with how to embrace this change. This workshop will also look at the shift that has happened, what is driving this change, and how organizations can embrace this stack and how to marry Lean Tech with Lean UX.
Here's a deck I put together for our weekly learning seminar at Verbal+Visual.
Special thanks for General Assembly, my instructors Luke Miller, Rashida White, and Nevan Scott.
http://www.verbalplusvisual.com/interaction-design-rapid-prototyping/
Get hands-on advice for rapid Agile prototyping in a product team.
You'll learn:
- How to determine the right depth and breadth for MVP prototypes.
- How to prioritize use cases for prototyping.
- How to elicit the right stakeholder and user feedback.
- How to correctly annotate prototypes for dev and QA.
An introduction to Lean UX, grounded in Lean Startup and Agile principles. A starting point for shifting today's organizations towards a safer sustainable approach to product design and development.
User Story Mapping for Minimum Lovable Productsuxpin
You'll learn:
How to visualize user needs instead of product features
How to make better decisions when prioritizing a UX backlog
How to align sprints with UX strategy
Design Spikes for the Dual-Track Agile Processuxpin
You'll learn:
How to fit design spikes into a Scrum framework
How to address user stories without neglecting UX strategy
How to solve design problems before they become development issues
Introduction to user experience design + usability
Describe the field of UX + how it relates to other disciplines
Identify the different roles within UX + the responsibilities of each
UX Process: Traditional [“Waterfall”], Agile, Lean
Learn to conduct UX research
Introduction to user experience documentation + deliverables + software
Learn about personas, user flows, sitemaps, wireframes
Determine when to use which documentation
Discover new tools and frameworks for creating deliverables
Introduction to usable web forms
Identify the different elements of forms and how to use them effectively
Learn what makes a strong user experience with forms
Identify expected outcomes
Curated list of UX resources
Recommended blogs, books, experts to follow, companies of note, local organizations and recommended conferences
The JoomlaChicago Loop sponsored "Joomla & Responsive Design", a presentation focused on the key ingredients and dynamics of making a Joomla website flow and react to the different viewing devices and browser viewport sizes.
Dennis Kmetz (Director of Interactive Media, Taylor Bruce Design Partnership) presented Joomla & Responsive Design on Thursday, March 1, 2012.
The experience your customers have with your products is a critical component of success. Valuable products can solve real human needs, fulfill desires, and improve the quality the of life. This goes beyond just building more features, or making things look pretty. It involves understanding and empathizing with your customers, and involving them in the design process.
How do we do this? And how do we do this in a way that fits into the operational rhythms of Agile development? These perspectives are shared by a long-time UX designer who has recently moved into Agile.
About Kazumi Terada
- Available for hire
- Born in Tokyo, Lived in Dallas, Lives in New York. US Citizen. Bilingual.
- Parsons School of Design, BFA in Architecture
- Work Experience: Panasonic, Shutterstock, Vibrant Media, Bertelsmann
- Building websites since the 90’s
- UX Design Immersive Certificate from General Assembly, May 2016
- Co-founder of a design firm and a non-profit
In this deck I explore how design can improve products and industrial processes showing how starting from a radical change in the approach to business, any company could improve not only their own products, but can literally create new needs in their customers and, at the end, new markets and new business potential.
As we all know, there are more confounding alarm clocks than elegant iPods in the world. Despite our knowledge of design, companies continue to churn out bad products. How can we improve our chances of creating great products? I think it requires designers to understand a little about finance and strategy, and managers to know a little about design. It requires using design skills to communicate, selling your ideas, and patience.
During this event I'll introduce a few specific techniques for thinking about the business situation. Then when you're tired of listening to me we can do an exercise to create a product that fits a particular strategy, then talk about how this approach applies to your everyday work. Hopefully it'll be both useful and fun.
A lot of what we know about user experience comes from the fields of cognitive science, psychology, and neuroscience. However, often this information ends up coming over as pop psychology, instead of through actual research. Here I discuss 5 myths that I've heard a lot in the UX community, and how they stand up to science.
UX in Agile: How one team is making it workWill Sansbury
At Daxko, specialized knowledge doesn’t mean specialized work. It means responsibility to coach the entire team to execute well within the specialist’s area of expertise. That’s how we approach user experience (UX) design—our embedded designers on each team have a responsibility to coax good design out of the team through a variety of methods and techniques, but they’re not solely responsible for generating the design.
In this combination presentation and panel discussion for PMI Atlanta's Agile Interest Group meeting, we shared how we work at Daxko, how we account for UX in project planning, and how we practice design as a team sport. We also fielded audience questions and gave an honest and transparent view into what we’ve done that works as well as some of the failed experiments we’ve undertaken.
Taller de experiencia de usuario en el Congreso de Periodismo Digital de FOPE...Emiliano Cosenza
A veces construimos productos periodísticos técnicamente novedosos, pero la audiencia no los adopta. En general, esto se debe a que la experiencia de uso es mala, porque los usuarios no los consideran útiles y fáciles de usar.
¿Podemos definir cómo será la experiencia de nuestros usuarios? ¡Por supuesto! El primer paso es tomar la decisión de diseñarla desde cero y poner mucho foco en las personas.
En el taller vimos algunas técnicas rápidas para salir de la caja y pensar soluciones poniéndonos en sus zapatos. No sólo para que les resulte fácil de usar, sino también para que disfruten hacerlo. Y se enamoren de nuestro producto.
Taken from Future of Web Design (#FOWD), London 2015 Conference. http://futureofwebdesign.com/london-2015
Reports are in from Twitter, Medium, and the like; we can’t make full comps, use Photoshop, or even utter the phrase 'visual design' anymore. What’s a designer to do? Has our role evaporated? Fear not! Dan Mall will help redefine the tasks of the modern day designer in light of the multi -device world that snuck up on us.
The Kenya Ushahidi Evaluation Project was 9-month Ushahidi evaluation project in partnership with the Harvard Humanitarian Initiative supported by the Knight Foundation. Jennifer Chan and Melissa Tully conducted research which lead to the creation of case studies and toolboxes. (2011) This is Toolbox #1: Assessment.
Diseño de la experiencia de usuario para emprendedores tecnológicos - Proyec...Emiliano Cosenza
Qué aspectos podemos tener en cuenta para lograr que nuestro producto digital no sólo sea fácil de usar, sino también que las personas disfruten hacerlo.
Nos enfocaremos en cómo somos como usuarios y en cómo podemos diseñar con ellos y alrededor de ellos, hasta lograr que tengan la mejor experiencia.
It has been argued that UX standards are just a seductive fantasy. No matter what we do, our carefully-crafted libraries and templates seem inevitably doomed, sacrificed to one-off solutions pushed live in the name of "Agile." Yet we, as designers, continue to find ourselves spending countless hours re-explaining basic interactions and citing best practices. Inevitably, someone will suggest the development of site-wide standards…
And the process begins again.
This session will present Style Frameworks, a new standards format designed to break this cycle. Style Frameworks consolidate visual and coding standards from marketing, user experience and engineering into a single, unified source supported by the entire company. This step-by-step walkthrough will cover everything required to create and effectively maintain a Style Framework. In the end, attendees will be provided a link to download a sample Style Framework they can freely modify and implement right away.
The elements of product success for business leadersNick Myers
All software, whether it's for consumers or workers, needs to meet the ever growing demands people have in today’s world. Greater user expectations and influence are forcing companies to create and deliver better products, but not every organization has a rich heritage in software creation like tech giants Apple and Google. Most companies need to be more customer-focused, become design specialists, and transform their cultures as they shift to become both software makers and innovators.
Myers, a 16 year specialist in design and head of design services at Cooper, will share the elements of product success that companies need to possess and be market leaders: user insight, design, and organization. Myers will share principles and techniques that successful innovative companies use to truly understand their customers. He’ll also discuss the methods effective designers use to support their customers and create breakthrough ideas and delightful experiences. And he’ll finish by sharing the magic formula organizations need to deliver ground-breaking experiences to market.
This talk was initially given at Visualize 2012.
A decisão em equipe envolve vários agentes, critérios, alternativas, interesses, pontos de vista conflitantes e grupos de pressão. Quando uma equipe não consegue tomar uma decisão, o poder da decisão acaba ficando na mão de uma única pessoa (uma fuga para o velho paradigma de gestão, onde poucos pensam e a maioria apenas executa o que foi pensado). Nessa apresentação, você vai conhecer 5 abordagens diferentes para tomar decisões em equipe. São papéis, técnicas e ferramentas que farão a sua equipe trabalhar de maneira efetiva na resolução de problemas cada vez mais complexos, praticando a auto-gestão e aumentando sua autonomia.
Slides da Trend Talk apresentada no Agile Trends 2014.
Keynote presentation delivered on November 12, 2016 at the 10th Italian Information Architecture Summit in Rome, Italy.
Description of the talk:
https://jarango.com/2016/11/22/leaving-your-mark/
We created a remote-first productivity tool that would enable teams to collaborate in real-time without friction. We wanted to build a remote-first productivity tool https://www.taskade.com
1
User Interface Development
User Interface Development
Shashank Pitla
Wilmington University
Iteration 1 – Develop a storyboard
Plan
Nowadays, as the technology and the Web are continually being used to perform various operations, it becomes paramount to have an interactive and attractive user interface (Molina, Redondo, & Ortega, 2009). That is because humans interact with these systems through an interface. This iteration entails storyboarding for the user interface. A storyboard is a technique used for illustrating the interaction between humans and products in a narrative format that incorporates a series of sketches, drawings, pictures, and words to tell a story (Gruen, 2000). In this iteration, I plan to create storyboards that specify how the user interface will be changing in reaction to the user’s actions as well as to show the external elements to the system. I plan to use as few details as possible to get the key points on board regarding the big picture because the storyboard is supposed to present clear and precise information of the user interface.
In the procedure for storyboard design, there are three major activities that I plan to carry out including deciding what to incorporate, building the storyboard, and lastly feedback and iteration. In deciding what to do, I plan to interact with some users in the company to understand their needs, goals, and background. This analysis will also aid in understanding the system and the features. I will also get to brainstorm with the design team, identify people and artifacts in this storyboard and then develop the storyboard scenarios. During the time for building the storyboard, I will put the gathered information concerning the storyboard features into practice and illustrate the user actions on the storyboard. During the last step in my procedure; feedback and iteration, I plan to gather feedback from the internal and external stakeholders and then iterate the storyboard design.
Action
The documenting of the iteration’s objectives was the first activity that was carried out before commencing the main activities of the session. I then began with the first step of my procedure that is, deciding what to include. To accomplish that, I had to interact with the users with the aim of understanding their backgrounds and goals, and to understand the system better in terms of the desired features. I also brainstormed with the design team about the storyboard before developing the storyboard scenarios.
In the second step, I broke the story into smaller sections known as frames; I identified the key frames from the scenarios as I focus on each frame’s individual features. In each frame, I had to draw the user, the product as well as other fundamental objects for each frame. I used tests for the users’ thoughts or reactions and made sure to use as minimum detail as possible in communicating the user interface features. I then wrote short descriptions for each frame to ...
UX BASIS is a process and a set of tools to help your organization engage with your users through the online products that you develop. By building an experience around the user, it will enable you to answer their needs whilst ensuring the needs of your business are also fulfilled.
Evidence based design creates a greater value for your business and also encourages collaboration between your teams and results in knowledge sharing between individuals.
This talk was given at a meeting of web project managers (organised by J.Boye) in May 2010.
How to Use Engineers in a UX DepartmentStephen James
Barbarians at the Gates How to Bring Engineers into Your UX Department in order to Lower Coordination and Transaction Costs and Accelerate Product Development
This is a modified version of a presentation given at an internal UX department offsite meeting for a large technology company back in 2014
UX and UI design. Differences, good practices, and useful tools in building dedicated software that meets customer needs and expectations. It covers many important aspects of UX like personas, scenarios, canvas, measuring and measuring tools, the whole development process and gathering feedback.
It was created by Dominik Goss, CEO at Inwedo
Have more questions about UX/UI? Contact us at contact@inwedo.com for additional information or questions and we will get back to you shortly.
When Austin teaches how to run great workshops, designers worry most about facilitation. What if participants won’t join the discussions? What if attendees won’t participate? What if you can’t manage the room?
But facilitation skills are rarely the problem. Regardless of the type of workshop you want to run, good workshops depend almost entirely on how you structure the activities.
In this presentation, we’ll look at two strategies that maximize participation and guarantee clear outcomes and decisions. Attendees walk away with two checklists: one for guiding facilitation and another for structuring workshop activities.
Architect Taxonomy Systems to Support Organizational ChangeAustin Govella
A global Fortune 500 company needed an experience marketing platform that would support any number of business units marketing any number of products to any number of customers across multiple channels with an unknown mix of static and dynamic content and complex personalization yet to be determined—because the company knew it was in transition, the platform would need to evolve without any new development. How do you design a sustainable information architecture when organization, labels, navigation, and metadata are guaranteed to change? Hear lessons from designing this and other flexible organizational systems, and learn approaches to use when architecting sustainable, complex, enterprise platforms.
User Experience Architecture in a Cross-Channel WorldAustin Govella
One of the dirty secrets about cross-channel user experience is that we've always worked cross-channel. What's changed is how much—and how well—we can impact the experience across these channels.
In this presentation, we’ll examine three guiding principles for working cross-channel. With those principles in mind, we’ll look at four tools you can use to help guide and improve cross-channel user experiences at your organization.
The problem isn't waterfall. It's not deliverables. And, big upfront design is a big, straw bogey man trotted out to scare young UXers.
Agile and lean promise fundamental changes to your process, so you can improve your outcomes. Like other approaches, agile and lean bring their own sets of problems and barriers. Oddly, for bringing such fundamental change, they often bring the same problems and barriers your teams faced before they were agile and lean.
This is because agile and lean don't really change your process. They change your focus. I'll say that again because I think it's important: agile and lean don't change your process; they change your focus.
And the problems inherent with your process don't have to do with focus. You won't fix your problems by becoming agile or lean. You fix your problems by understanding when to be agile, when to be lean, and when to focus on the experience.
In this presentation, we'll tear agile and lean and UX apart to see what makes them work, and what makes them fail. We'll explore the universal activities teams use to get products out the door. And we'll understand the constraints that drive the effectiveness of those activities.
Once we're done, you'll go back to work knowing how to adjust what your team does. But more important, you'll know when to make what adjustment when. You'll be able to create better teams, better products, and better experiences.
A Guide to Farming Miracles (for UX teams in tough environments)Austin Govella
Designers don't really design anything. Organizations design everything. So, what if your organization sucks? Seriously. What do you do then? And then -- while you're at it -- do it "agile". Do it "lean".
Organizations face seven barriers when trying to design create better products and services: value, focus, time, memory, quality, understanding, and improvement.
We'll look at seven approaches you'll be able to use on Monday to help your company overcome these seven barriers. Instead of changing what you do, you'll learn to change how you do it. It's changing the how that enables better design. You'll be able to build better, more balanced teams, better interfaces, and better experiences.
Presented at the Big Design conference in Dallas, TX on Friday, July 15th, 2011 at 1:00pm.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
1. Hacking UX
A young designer’s
illustrated primer
Austin Govella
@austingovella
www.austingovella.com
slideshare.net/austingovella/hacking-uxv1ag
2. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 2
there’s a dirty secret in the turf war between agile,
lean, and waterfall: they each use the same product
development process. What’s different isn’t their
process, but how they apply design activities in
different ways to eke out different design value.
so how can you alter the design process? even
better, how can you customize the process to
provide more value for the way your organization
works? How should you change the design process
from sprint to sprint to get the most value out of
your design activities?
How do you hack user experience?
3. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 3
Design is all about value. it transfers value from
one person to another. design insures you have an
experience: at the end, you’re different than when
you started. design makes this difference. specific
knobs and levers control how you can create value
with design.
in this presentation, we’ll learn how five levers —
models, fidelity, annotation, communication, and
audience — work together. We’ll see how agile, lean,
and waterfall teams apply these levers differently at
different times to create different value from design.
We’ll learn UX’s component parts, so we can start to
hack the user experience.
4. Three Teams (a story)
one sprint, three teams, lots of differences
5. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 5
2. tHree teAms
team one, daily scrums, and a two
week sprint.
We were adding functionality for
accessing auto-generated data quality
reports. because similar functionality
existed elsewhere in the app, the team
got together, discussed the scenarios
and agreed to use an existing design
pattern on the new screen.
We sketched a few screens on the
whiteboard. We essentially designed the
feature through conversation.
Team 1, quality conversations
We handled follow-up questions around
how users would access the new screen
with a couple of hallway conversations.
We pushed the change, and it was good
enough to get out the door.
6. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 6
2. tHree teAms
We were redesigning our user groups
interface: create and edit groups; add,
edit, and remove members; and adjust
group permissions. it was a key piece
of functionality.
i put together a full spec. 20-30 pages
of flows, wireframes, component details
and variations, and lots and lots of
annotation.
the specification described changes to
labels, changes to navigation, changes
to flows, a couple of new totally
screens, a couple of new components,
and a couple of screens with some
small changes.
to be honest, none of the changes were
complex enough to require a full spec.
And it wasn’t for QA. the tester was on
the scrum team, testing code as it was
written.
but... the product manager worked on
the West coast, and i was in Austin.
Team 2, group specifications
And, the changes had potential political
fallout and needed to be sold to the rest
of the organization.
the specification allowed the team to
have more concrete discussions with
the distant product manager, and it also
showed how the changes affected the
product’s overall, holistic experience.
However, the spec was probably most
likely created because i needed a
more visual, comprehensive way to
walk through the problems, see the
changes, and understand how they
affected the whole. I got down into the
weeds because it was the weeds that
mattered.
7. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 7
2. tHree teAms
For the third team, i had two explicit
duties:
1. i was not assigned to the team.
2. i was not designing an interface.
i was there for crazy checks and to
make sure the team didn’t engineer
themselves into a corner we couldn’t
design out of later.
We were delivering Facebook apps that
allowed our customers to embed our
application functionality into Facebook.
no one on the team had ever done a
Facebook app, and no one had even
touched pHp in ages.
i came in a few days after planning
to consult on best practices and the
broader information architecture. the
first deliverable was a set of wireframed
list components.
Team 3, three Facebook comps
We used these wireframes in a meeting
to telegraph the design requirements
that were going to emerge in the near
future, so the team could make sure the
new feature would be ready. this was
easy, and the engineering team was
already on top of it.
the second set of deliverables were
three high-fidelity visual designs of the
new components. We didn’t create the
comps just so we could show and sell
them to our customers. We wanted to
be sure we built what we sold.
8. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 8
2. tHree teAms
Have you worked on agile teams at
more than one organization?
For example, i worked on agile teams at
three separate companies: the World
bank, comcast interactive, and convio.
Have you worked on more than one
agile team at the same organization?
For example, i worked on two agile
teams at comcast interactive: one
building comcast.net and another
building xFinity.
If you’ve worked on more than one
agile team, did each team use the
same process? Or was the process
different?
Although i worked on each team at the
same time for the same company on
the same product, each of these three
teams highlight set of differences:
• A different process
• A different deliverable
• A different way to design
When i walked into each planning
meeting, how did we know to make the
process different? How did we know
what deliverables? How did we change
the way we designed?
How did i know what
the team would need
from me?
10. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 10
3. WHAt every teAm needs
OFirst, we concern ourselves with the User.
some suggest all design should be user-centered, but they would be wrong.
11. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 11
3. WHAt every teAm needs
psecond, we concern ourselve with the Interface.
When some talk about big Upfront design, this is usually what they’re talking about. they would also be wrong.
12. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 12
3. WHAt every teAm needs
When we examine how a User uses an interface
through time, we are looking at an Interaction.
When some people say you should only test real code with real users, they’re talking about interactions. they’re also wrong.
13. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 13
3. WHAt every teAm needs
if we examine how interactions feed into, affect,
and relate to others, we are dealing with a System.
sadly, architects are almost the only people who care about systems.
14. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 14
3. WHAt every teAm needs
For every project, everyone on your
team already has an assumption about
the User, the interface, the interaction,
and the system.
your assumptions about these four
models form your mental model about
how the entire system works.
What happens if you have one mental
model about the interface, and your
teammate has another? How will you
build the same thing?
to make sure you build the same thing,
you have to talk to each other. you have
to share your models with one another.
As long as everyone on the team shares
the same understanding, as long as the
team sees the User, the interface, the
interaction, and the system in the same
way, then can you build something
together.
Give everyone the same context,
and they can make complimentary
decisions. Shared vision is what
enables more agile, more lean, and
more balanced teams.
Teams need to share the same vision
15. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 15
3. WHAt every teAm needs
We can take these four models — the
User, the interface, the interaction, and
the system — map them back to our
three teams, and explore how we shared
and discussed these models in each
team.
team User Interface interaction system
Quality conversations Assumed Sketches verbalized Assumed
Group specifications Assumed Wireframes verbalized Assumed
Facebook comps Assumed Comps verbalized Assumed
Although each team shared an
understanding of the Users, interfaces,
interactions, and systems, that
doesn’t mean each team documented
everything.
Having worked together for a while,
each team already possessed a shared
understanding of the Users and the
system. the teams didn;t need to share
and discuss them, so the Users and
systems were assumed.
similarly, while each team shared and
discussed the interface models, we
didn’t need to create explicit models of
the interactions. the teams verbalized
the interactions. We talked about them:
on this screen, when the user clicks
here, they go to this screen.
the real difference in how each team
created a shared understanding lays in
how we chose three different ways to
discuss the interface:
1. sketches
2. Wireframes
3. comps
each team chose a different method to
share the interface model.
16. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 16
3. WHAt every teAm needs
on every single one of your projects,
you’ve been asked to choose how to
communicate the interface.
How do you choose between sketches,
wireframes, and comps?
sketches are quick and lean, but comps
have more detail.
When is a comp better than a
wireframe?
For example, when do you need to
spend extra time hashing out the visual
design?
When is a sketch not enough?
How do you know if you need the extra
finesse you can show in a wireframe?
these three teams in the same
company, on the same product, in the
same sprint, with the same UX lead
chose three different ways to share the
interface:
• A sketch
• A wireframe
• A visual comp
How did each team know what
deliverable would be enough? Why did
some teams stay simple with a sketch
while others got more complex with
wireframes and comps?
How did we know how
complex our models
should be?
18. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 18
1. Fidelity
Fidelity describes how close a model is
to the real thing.
When we discuss how much fidelity a
model has, we’re talking about how
similar it is to the real thing. How
possible is it for someone to confuse it
for the real thing?
When our three teams shared their
models of their interfaces in different
ways — as sketches or wireframes or
comps — we were showing models with
different fidelities.
What is fidelity?
19. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 19
1. Fidelity
sketch wireframe visual comp
As we move from sketches to
wireframes to visual comps, our model
of the interface moves from more
abstract to more concrete. each model
of the interface becomes more like the
real, live product.
lower fidelity higher fidelity
20. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 20
1. Fidelity
When our model looks more like the real
thing, it has visual Fidelity.
it turns out, there are four types of
fidelity we can consider:
1. visual fidelity
2. behavioral fidelity
3. content fidelity
4. contextual fidelity
Four types of fidelity
21. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 21
1. Fidelity
the most obvious difference between
the wireframe and the comp is that the
comp looks more like the real product
than the sketch or the wireframe.
lower visual fidelity uses broad strokes
to envision generalized silhouettes.
models with higher visual fidelity crave
more and more pixel-perfection until
you can’t distinguish them from the real
thing.
When developing prototypes and proofs
of concept, visual fidelity is one of the
questions you ask yourself: how much
fidelity does this prototype need?
wireframe visual comp
Visual fidelity
like all fidelity, the higher the visual
fidelity, the easier it is for someone to
understand. you can see this in action
in your career: some clients just don’t
“get it” when they see a wireframe. they
have to see a comp.
22. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 22
1. Fidelity
behavioral fidelity refers to how
accurate the behavior is. do all the links
work? or just some of them? do the
accordion panels really show/hide, or
are you faking it?
When working with prototypes and
proofs of concept, you often ask
yourself about the behavioral fidelity.
Are you trying to evaluate one specific
interaction? then none of the other
behavior needs to be accurate.
is the prototype your documentation?
then maybe all of the links and
transitions need to be pretty close.
like visual fidelity, the more behavioral
fidelity your model has, the easier it is
to understand the object’s behavior.
Behavioral fidelity
no visible behavior links, search forms, and a dropdown
if you’ve ever wildly gesticulated to
describe a transition to someone, you
understand how much easier that
transition is to communicate when you
can show someone an example.
23. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 23
1. Fidelity
most discussions of fidelity stop at
visual or behavioral fidelity. Usually, this
is because those types of fidelity have
the largest impact to how long it takes
to implement.
but content fidelity can be just as
important. content fidelity describes
how accurate the content is in your
model.
visual designers will often use “greeked
text”, like lorem ipsum, in visual
comps. Greeked text has less content
fidelity than real, sample content.
like visual and behavioral fidelity, the
choice here is usually driven by time. it
takes longer to create realistic content.
like visual and behavioral fidelity,
there’s a trade-off. visual designers who
use greeked text are only concerned
with visual form. Any letters will do.
information architects want to create
clear labels. How can you evaluate your
labels in a design if you use greeked
text?
greeked content
sample content
Content fidelity
24. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 24
1. Fidelity
Contextual fidelity
you won’t usually hear anyone complain
about contextual fidelity, but you’ve
seen it in action.
contextual fidelity refers to the accuracy
of the context when you share your
model.
When you print out the entire comp
for the review, instead of showing it in
a browser window, the comp has less
contextual fidelity.
When you push code to production to
see how users respond in real time, you
have more contextual fidelity than if you
recruited 5-7 users for a usability test
in a lab.
the entire comp
the comp in a browser window
25. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 25
1. Fidelity
measuring is an optimistic idea.
Although you can’t measure fidelity in
real units, you can quantify fidelity with
fuzzy units.
i like to use t-shirt sizes:
• small
• medium
• large
you can combine the four types of
fidelity with t-shirt sizes to describe how
much fidelity an object has.
Measuring fidelity
type of Fidelity s m l
visual
behavioral
content
contextual
26. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 26
1. Fidelity
often, when you talk about fidelity,
you end up thinking about visual
and behavioral fidelity, so it’s easy
to imagine fidelity only applying to
interface models.
With our three teams, the primary
difference between the sketches, the
wireframes, and the comps was the
visual and behavioral fidelity.
However, it’s important to consider the
fidelity of your User, interaction, and
system models. your team’s shared
vision will reflect the fidelity of these
models, and different levels of fidelity
provide different advantages and
disadvantages to the team when you’re
building something.
Fidelity applies to all four models
27. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 27
1. Fidelity
if you recall, none of our three teams
really discussed their users. We had a
shared understanding of who they were
born out of many months and years of
working on the product.
instead of sharing and discussing our
shared vision of who the User was, we
had an assumed understanding. our
User model was based on anecdotes,
ancient evidence, and feature requests.
Fidelity for User models
often, User fidelity becomes an issue
when creating personas. the user
experience community debates how
much and what kind of research you
need to craft “real” personas.
And at the other end, 37signals designs
products for people like themselves.
Here are a few examples of how fidelity
affects your User model.
type of Fidelity lower fidelity Higher fidelity
visual abstract, iconic user pic nice photograph
behavioral what you think they User does analytics
content random description demographic data
contextual testing in a lab testing at the user’s home
image continuum from scott mccloud: http://www.scottmccloud.com/4-inventions/triangle/04.html
28. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 28
1. Fidelity
type of Fidelity lower fidelity Higher fidelity
visual boxes and arrows storyboard
behavioral storyboard prototype
content boxes page archetypes
contextual prototype production
not sure you recall, but on the first
team where we were working on adding
data quality reports, we had some
questions come up about how Users
would navigate to the new feature:
where would they come from and where
would they go.
We handled this with conversation, a
really low-fidelity way to discuss the
interaction.
Fidelity for Interaction models
Whether you discuss the flow, sketch it
out, or craft a prototype, the fidelity of
your model affects how accurately you
can evaluate the interaction.
screen
name
description
screen
name
description
screen
name
description
screen
name
description
n
y
see Flow:
Flow name
shorthand for Ui flows from 37signals: http://37signals.com/svn/posts/1926-a-shorthand-for-designing-ui-flows
29. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 29
1. Fidelity
type of Fidelity lower fidelity Higher fidelity
visual words page archetypes
behavioral concept map site map
content screen archetypes specific screens
contextual site map production
in the user experience world, a site map
is one of the most common system
models you will encounter.
Fidelity for System models
site maps are actually a type of concept
model and occasionally enterprising
designers will crank out a concept map
to communicate or evaluate non-screen
aspects of a system.
shorthand for Ui flows from 37signals: http://37signals.com/svn/posts/1926-a-shorthand-for-designing-ui-flows
30. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 30
1. Fidelity
Just as everyone on the team will always
have an assumption about the User,
interface, interaction, and system
models, your vision of those models
always has a certain level of fidelity.
How do we choose between high or low
fidelity?
How do we know when we need the
extra detail?
How do we know when the models we
have don’t have enough fidelity?
After we’ve chosen between high and
low fidelity, how do we discover if we
were right or wrong?
each of the three teams chose interface
models with a different fidelity, from
sketches to wireframes to comps.
Adjusting fidelity is the easiest way to
adffect the required length of the design
process.
How do we know how
much fidelity we need?
32. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 32
1. AUdience
do you remember the three teams?
team one was adding data quality
reports, team two was redesigning user
group management, and team three
was building Facebook apps.
With each of the teams, we assumed
the User and system models and
managed the interaction models via
conversation.
the result was three different interface
models. team one went with sketches.
team two used wireframes. team three
decided to do full comps.
but it wasn’t just the deliverables
that were different. each team had a
different audience.
33. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 33
1. AUdience
if we compare the audience for each
team’s interface model, it’s clear
that each team was working with a
drastically different audience.
team interface model Audience
Quality conversations sketches the team
Group specifications Wireframes product council
Facebook comps comps customers
34. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 34
1. AUdience
While your team needs to share a vision
to build something great, design is
always about your hypothesis. your
team’s vision is your shared hypothesis.
the team believes the User with
this interface will accomplish this
interaction within this system.
However, because design always
concerns itself with a User, our
hypotheses must always have an
audience.
Who will validate the hypothesis? Who
will evaluate whether or not the design
will work?
A hypothesis requires an audience
35. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 35
1. AUdience
the key question really is: Who will
evaluate whether the design will work?
there are four possible answers to that
question:
1. yourself
2. your team
3. your organization
4. your customers
the audience that will evaluate your
User, interface, interaction, and system
models determines the highest fidelity
you need and the lowest fidelity you can
get away with.
in general, the farther away your
audience is, the higher fidelity your
models should be.
Four audiences customersorganizationteamself
Fidelity is all about the distance to your audience.
36. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 36
1. AUdience
We can see distance at work with our
three teams.
team interface model Audience evaluation
Quality conversations sketches the team
needed enough detail
to build
Group specifications Wireframes product council
needed more detail
to sell internally
Facebook comps comps customers
needed to see the
real thing
your distance from your audience helps
describe how much shared vision you
have with the audience.
if i want to sketch a screen and then
evaluate it myself, i understand what i
was thinking.
if i want my teammate to look at my
sketch, i might need to enhance its
fidelity by explaining what this or that
squiggle is.
if i walk over to the ceo and show him
my sketch, i will likely have to explain a
greater amount of the sketch.
Audience and shared vision
the reason for this discrepancy is that i
share more vision with my teammates
than i do with the ceo.
Whatever vision you do not share with
the audience means they can’t interpret
what you mean. you have to explain it to
them. that means more fidelity.
37. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 37
1. AUdience
it’s not just distance that affects the
fidelity of your models. each audience
is also disposed towards answering
questions in different ways.
team interface model Audience Question
Quality conversations sketches the team can we build this?
Group specifications Wireframes product council
can we make this
change that impacts
the entire product?
Facebook comps comps customers Would buy this?
For example, let’s say we wanted to
know whether an interface was usable.
you could priobably sketch an interface
and show it to another user experience
practioner. With only the sketch, they
could offer you advice on how usable
the interface would be.
Alternately, if you wanted your
customers to evaluate how usable the
interface is, you couldn’t use a sketch.
to test usability, you at least need a
prototype with some degree of visual,
behavioral, and content fidelity.
Audience and hypothesis
similarly, if you want the ceo to sign
off on the redesign, they’ll probably
require high, visual fidelity comps. they
simply can’t tell whether or not the logo
is big enough from your sketch.
the hypothesis you are trying to test
has a lot to do with the fidelity your
audience will need.
38. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 38
1. AUdience
based on your audience and the
hypothesis you want to test, you will
need to share your models at higher or
lower fidelities.
Although your distance from the
audience — the amount of vision you
share — and the question you’re asking
drive fidelity, other aspects of the
audience also have an impact.
How does team location
impact fidelity?
Are we co-located, or do we have remote
team members?
How do time zones and schedules
change how we share models?
Just as each of our three teams
had a different audience, how we
communicated with the audience was
different, too.
our audiences context is just as
important as their distance and the
hypothesis we want to test.
How does how we
communicate affect
fidelity?
40. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 40
1. commUnicAtion
it’s easy to understand how we
need different fidelity based on our
Audience’s distance and the type of
hypothesis we’re trying to test, but
we’re missing the obvious things about
our audience:
• time
• place
• reach
these three facets of our audience
can have as much impact on fidelity as
anything else.
41. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 41
1. commUnicAtion
When we communicate with our
audience can have an important impact
on fidelity.
Are we communicating in real time,
synchronously, like a back-and-forth
conversation?
or, are we communicating
asynchronously, like an email
correspondence?
or, is it a combination of both same
time and shifted time, like an im
conversation we share and then both
leave and come back to?
Time
our three teams demonstrate how a
time shift requires more fidelity.
the data quality team that used
sketches did all of its communication
synchronously.
in contrast, team 2 sent the new group
specifications to the product countil
and didn’t hear back for a couple of
days. that gap was enough to require
wireframes.
team interface model Audience time
Quality conversations sketches the team synchronous
Group specifications Wireframes product council asynchronous
Facebook comps comps customers asynchronous
42. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 42
1. commUnicAtion
When you speak synchronously, you
can share and discuss large volumnes
of information as part of the back-and-
forth of normal conversation.
Any gaps between your understanding
and your audience’s — any gaps in
the vision you share can be managed
through conversation.
but when communication is
asynchronous, the only way to manage
that gap is by writing things down,
drawing things, coding things.
Anything you can do to make the model
more real, to make something you can
give to someone else to check.
And it’s important to note that
asynchrous communication doesn’t just
happen when you’re talking with other
people, with outsiders.
one of the biggest uses of
documentation is so the team can
remember their decisions. three
months from now, you might not
remember whether that link went to a
new page or opened a lightbox.
the documented design allows you to
have a tinme-shifted conversation with
yourself.
43. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 43
1. commUnicAtion
Place
location has a similar impact on fidelity
as time does.
Are we communicating to someone who
is next to us? someone in the same
room?
or, are we communicating with
someone far away?
Are working with a variety team mates
who work from different locations?
if you remember, one of the reasons i
created user group wireframes for team
2 was that the product manager lived in
california while the rest of the team was
in Austin.
the additional fidelity in the wireframes
helped supplement the gesturing and
body language we couldnt share over a
conference call.
team interface model Audience place
Quality conversations sketches the team co-located
Group specifications Wireframes
product manager,
product council
co-located and
remote
Facebook comps comps customers remote
if you’re co-located, you can stick
sketches on a wall. if everyone is
remote, you have to snap and upload
them somewhere.
if you’re remote, quick questions have
to come through im or email. if you’re
co-located, you can pop your head over
the cube wall.
44. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 44
1. commUnicAtion
Reach
reach describes how far your audience
may share your model.
i like to call this the ceo effect. this
is what happens when your boss asks
for that whiteboard sketch from last
meeting. your boss sends it to their
boss who shows it to someone else,
who doesn’t understand or like what
they see, who sends the sketch and the
complaint to the ceo who promptly
emails you an edict vetoing the design.
reach is governed by the same logic
that surrounds time and place. if you
don’t know whether you will be around
to explain your model to whoever ends
up with it, then you need to put your
explanation into the model.
your model needs more fidelity.
For team two, we knew the wireframes
would be shared with the product
council, and who knows who they would
share them with. so, we made sure to
annotate the wireframes, so people who
saw them could deciper what was going
on.
similarly, the Facebook comps were
going out to the sales team to show
customers, so we made sure they had
as much visual fidelity as was possible..
team interface model Audience reach
Quality conversations sketches the team team
Group specifications Wireframes
product manager,
product council
organization
Facebook comps comps customers anyone
45. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 45
1. commUnicAtion
Just like we can measure fidelity, we can
use t-shirt sizes to measure how much
communication we need:
• small
• medium
• large
you can combine the four types of
fidelity with t-shirt sizes to describe how
much communication a model needs.
Measuring communication
type of
communication
s m l
time
place
reach
46. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 46
1. commUnicAtion
so far, we’ve discussed factors like the
audience, time, place, and reach that
are prime factors driving how much
fidelity we need.
We’ve also seen examples of high and
low fidelity for each of the types of
models — the User, the interface, the
interaction, and the system.
but we haven’t discussed how to adjust
our fidelity up or down.
How can we compensate for audience
distance?
How do we communicate clearly
with asynchronous and remote
teammembers?
We can’t just hack the user experience
process willy-nilly. We have to provide
our audience with the information they
need in order to help us evaluate our
hypothesis.
How do we control
fidelity in our models?
48. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 48
1. inFormAtion
once you understand you need to
change the fidelity of one of your
models, there are four types of
information you can adjust to raise or
lower the fidelity:
1. Tacit information
tacit information deals with what the
audience already knows about the
model.
2. Explicit information
sometimes, you include instructions on
a form. this is an example of explicit
information.
3. Implicit information
implicit information refers to what the
audience can intuit about the model.
For example, the affordance of a
skeuomorphic button provides implicit
infomation.
4. Annotation
When all else fails, if you adjusting tacit,
explicit, or implicit information isn’t
enough to adjust the fidelity, you can
always add annotation.
Just like fidelity and communication, we
can have a go at measuring information.
type of information s m l
tacit
explicit
implicit
Annotation
controlling the amount of information
in our models is the critical step in
controlling fidelity.
Four types of information
49. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 49
1. inFormAtion
tacit information is what allowed team
one to work off a few sketches we threw
together during the planning meeting.
everyone on the team shared a vision of
the User and the system. shared vision
is tacit understanding.
sometimes your interface will assume
the User will have certain tacit
understandings. For example, many
apps use red as a warning color. this
relies on Western culture’s association
of red with danger.
Tacit information
tacit information leverages the
audience’s culture. this could be
culture-at-large, or it could be team
culture. or organizational culture.
the magnifying glass icon used to
post a search is an example of tacit
information.
if you’re able to identify critical tacit
information about a model that your
audience doesn’t have, then you can try
and augment the model with explicit or
implicit information or add annotation.
50. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 50
1. inFormAtion
explicit information refers to what your
audience percieves in your model before
they begin to perceive the implicit
information.
instructions and calls-to-action like,
“view my profile page” are examples of
explicit information.
explicit and implicit information go
hand-in-hand with visual and content
fidelity. the higher your visual and
content fidelity, the more explicit
information you have in your model.
Explicit information
sometimes if your interface isn’t clear,
you can add explicit information. With
team one, we added a line of situational
text at the top of the screen that
explained the reports we listed on the
page.
51. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 51
1. inFormAtion
implicit information covers all the things
that are learnable about your model.
For example, Users learn twitter’s blue
post button. the first time you visit the
site, you don’t k ow what that button
does, if anything.
Fortunately, your implicit knowledge
tells you that contrasting colors
sometimes indicate interactive triggers,
so you know to click the button. And
posting a status is such a core activity
to the experience, you very quickly learn
how to post your status.
Implicit information
many usability and other
communication problems occur
because important information isn’t
learnable or discoverable. What you
hope will be implicit to the audience,
isn’t.
like explicit information, the higher your
visual and content fidelity, the more
implicit information is possible.
52. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 52
1. inFormAtion
you can’t really annotate production
code. i mean, you can. i suppose that’s
what happens when you open a new
app and they walk you through a feature
tour.
but that’s not really annotation.
Annotation is a special kind of
additional information you can add to
a model to fill in any gaps that aren’t
covered by tacit, explicit, or implicit
information.
Annotation is the special tool you use
to bridge the gaps created by different
audiences in different contexts.
Annotation
53. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 53
1. inFormAtion
55. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 55
1. inFormAtion
Model:
What type of model do we want to evaluate? User, interface,
interaction, or system?
Audience:
Who do we want to evaluate our model with? yourself, team,
organization, or customers?
Fidelity
How realistic must our models be in
order to be validated?
Information
What does our audience need to know
to validate our models?
Communication
How will we communicate the models?
Content
How accurate is the model’s content?
Visual
How visually accurate is the model?
Behavior
How accurate is the model’s behavior?
Context
How accurate is the model’s context?
Tacit
What does the audience already know
about the model? (culture)
Explicit
What can the audience learn from the
model? (instructions)
Implicit
What can the audience intuit about the
model? (affordances)
Annotation
What needs to be annotated to
understand the model?
Time
Are you communicating in real time or
asynchronously?
Place
is the audience remote or co-located
with you?
Reach
Will your audience share the model or
keep it private?
s s s
content
visUAl
beHAvior
conteXt
tAcit
eXplicit
implicit
AnnotAtion
time
plAce
reAcH
m m m
l l l
s s s
m m m
l l l
s s s
m m m
l l l
s s
m m
l l
Title
56. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 56
1. inFormAtion
Model:
What type of model do we want to evaluate? User, interface,
interaction, or system?
Audience:
Who do we want to evaluate our model with? yourself, team,
organization, or customers?
Fidelity
How realistic must our models be in
order to be validated?
Information
What does our audience need to know
to validate our models?
Communication
How will we communicate the models?
Content
How accurate is the model’s content?
Visual
How visually accurate is the model?
Behavior
How accurate is the model’s behavior?
Context
How accurate is the model’s context?
Tacit
What does the audience already know
about the model? (culture)
Explicit
What can the audience learn from the
model? (instructions)
Implicit
What can the audience intuit about the
model? (affordances)
Annotation
What needs to be annotated to
understand the model?
Time
Are you communicating in real time or
asynchronously?
Place
is the audience remote or co-located
with you?
Reach
Will your audience share the model or
keep it private?
s s s
content
visUAl
beHAvior
conteXt
tAcit
eXplicit
implicit
AnnotAtion
time
plAce
reAcH
m m m
l l l
s s s
m m m
l l l
s s s
m m m
l l l
s s
m m
l l
Title
Data conversations
Interface - sketches Team
X X X X X X X X X
57. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 57
1. inFormAtion
Model:
What type of model do we want to evaluate? User, interface,
interaction, or system?
Audience:
Who do we want to evaluate our model with? yourself, team,
organization, or customers?
Fidelity
How realistic must our models be in
order to be validated?
Information
What does our audience need to know
to validate our models?
Communication
How will we communicate the models?
Content
How accurate is the model’s content?
Visual
How visually accurate is the model?
Behavior
How accurate is the model’s behavior?
Context
How accurate is the model’s context?
Tacit
What does the audience already know
about the model? (culture)
Explicit
What can the audience learn from the
model? (instructions)
Implicit
What can the audience intuit about the
model? (affordances)
Annotation
What needs to be annotated to
understand the model?
Time
Are you communicating in real time or
asynchronously?
Place
is the audience remote or co-located
with you?
Reach
Will your audience share the model or
keep it private?
s s s
content
visUAl
beHAvior
conteXt
tAcit
eXplicit
implicit
AnnotAtion
time
plAce
reAcH
m m m
l l l
s s s
m m m
l l l
s s s
m m m
l l l
s s
m m
l l
Title
Interface - wireframes product mgr/council
X X X X X X X X X
X X X X
X X
X XX X
X
X X X
X X X
58. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 58
1. inFormAtion
Model:
What type of model do we want to evaluate? User, interface,
interaction, or system?
Audience:
Who do we want to evaluate our model with? yourself, team,
organization, or customers?
Fidelity
How realistic must our models be in
order to be validated?
Information
What does our audience need to know
to validate our models?
Communication
How will we communicate the models?
Content
How accurate is the model’s content?
Visual
How visually accurate is the model?
Behavior
How accurate is the model’s behavior?
Context
How accurate is the model’s context?
Tacit
What does the audience already know
about the model? (culture)
Explicit
What can the audience learn from the
model? (instructions)
Implicit
What can the audience intuit about the
model? (affordances)
Annotation
What needs to be annotated to
understand the model?
Time
Are you communicating in real time or
asynchronously?
Place
is the audience remote or co-located
with you?
Reach
Will your audience share the model or
keep it private?
s s s
content
visUAl
beHAvior
conteXt
tAcit
eXplicit
implicit
AnnotAtion
time
plAce
reAcH
m m m
l l l
s s s
m m m
l l l
s s s
m m m
l l l
s s
m m
l l
Title
facebook comps
Interface - comps product mgr/council
X X X X X X X X X
X X X X
X
X XX X X X
X X XX X X X X
59. HAckinG UX: An illUstrAted primer, by AUstin GovellA – @AUstinGovellA 59
1. inFormAtion
Thank You