Developer Experience (DX) for UX Professionals
•Als PPTX, PDF herunterladen•
3 gefällt mir•160 views
Ian Jennings presents at the Austin UXPA meetup on November 12, 2019 at Visa. Developer Experience (DX) is the equivalent to User Experience (UX) when the user of the software or system is a developer. Sure, the science is the same, but this talk will teach you why developer experience is gaining traction as a new field. Between APIs, SDKs, code, documentation, demos, CLIs, tutorials, and developer portals, DX is a whole new beast. Learn about the emergence of Developer Experience, the similarities and differences between UX an DX, and the tools you need to apply your UX experience toward the field of DX. Speaker Bio: Ian Jennings is the founder of Haxor, a developer experience testing platform based in Austin TX. Haxor tests and measures APIs, SDKs, and developer products with on-demand feedback from real developers. Previously Ian co-founded developer meetup platform Hacker League (acquired by Mashery and Intel) before spending 6 years at PubNub establishing their developer experience strategy. He also operates DevPort, a developer portfolio site populated by thousands of developers.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Developer Experience (DX) for UX Professionals
Ähnlich wie Developer Experience (DX) for UX Professionals (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Developer Experience (DX) for UX Professionals
- 1. Developers are Different What UX Professionals need to know about DX
- 2. Hey, I’m Ian Jennings
- 11. UX Research for DX
- 13. What is DX?
- 14. Developer Experience (DX) is the equivalent to User Experience (UX) when the user of the software or system is a developer.
- 15. DX describes the experience developers have when they use your product, be it client libraries, SDKs, frameworks, open source code, tools, API, technology or service.
- 16. What is an API?
- 20. In computing, an interface is a shared boundary across which two or more separate components of a computer system exchange information. The exchange can be between software, computer hardware, peripheral devices, humans, and combinations of these
- 21. Human Computer
- 25. UX DX
- 26. User Developer Interface UI API Study UX DX
- 27. Why does DX matter?
- 28. Jeff Bezos Memo, 2002 1. All teams will henceforth expose their data and functionality through service interfaces. 2. Teams must communicate with each other through these interfaces. 3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network. 4. It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. 5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. 6. Anyone who doesn’t do this will be fired.
- 29. Every service must have an API.
- 35. DX
- 42. Developers use a variety of applications to engage with your product.
- 46. Browser Extensions Developer Tools and Other Add-ons
- 47. API Testing and Sandbox Postman, Insomnia
- 49. Developer Portal
- 50. Documentation
- 51. Developers will use any resource at hand to accomplish the task.
- 52. Even if you didn’t create it.
- 53. The developer experience is not isolated to what your company builds.
- 56. Developers will actually help you create your product.
- 57. Developer community is active and vocal.
- 58. They’ll create their own content.
- 60. Search for “stripe vue” Stripe is not responsible for any of this content.
- 61. Paywalls
- 62. Engage developers where they are.
- 63. Every developer has a unique and custom environment.
- 65. Each developer’s machine is unique.
- 66. This is actually a huge problem for developers themselves.
- 68. Developers use a variety of languages.
- 70. Story Time
- 71. 5/5 developers could not sign up for an account...
- 72. …AdBlock!
- 73. Frameworks
- 79. Pre Purchase • Open source projects • Blogs • Tutorials • Examples Purchase • Developer portal • Docs • Support • Developer tools Post Purchase • Support • Uptime • Performance • Reliability • Analytics
- 80. DX - It’s a thing
- 81. Large companies have dedicated DX teams.
- 82. Sometimes the UX team is the DX team
- 83. DX people are transitioning from these roles:
- 84. • User Experience • Product Design • Product Management • Developer Relations
- 85. Small companies aren’t there yet.
- 86. APIs are documented by the engineers that build them.
- 87. “The code is the documentation”
- 88. Outdated information is left to rot online.
- 89. Product feedback comes from users…sometimes.
- 90. Disconnection between marketing, support, product, and engineering.
- 92. Small teams don't have enough resources to maintain the massive products and support customers.
- 93. Starting to see investment in DX startups.
- 96. http://haxor.sh
- 97. Test and measure Developer Experience (DX) with on-demand feedback from real developers.
- 98. UX Research for DX
- 100. • We study developers as they build apps on your API • Developers think-aloud as they build. • Developers submit a survey rating
- 102. and tutorials • See where developers struggle • Learn what developers expect from you • How do developers feel about your
- 104. We're building a DX research product.
- 107. • Track all coding changes • Track open applications • Record desktop and webcam video • Transcriptions of speak-aloud text
- 108. • What system and environment does the developer use? • How much time is spent in each application? • How long does it take until the developer starts coding? • How many errors does the developer
- 109. Thanks!
- 110. Questions?
Hinweis der Redaktion
- It’s the same as a UI
- It’s a competitive advantage.
- # Function Function is absolutely paramount. A developer tool is only as good as the functionality it delivers. You cannot mask subpar functionality with beautiful aesthetics or clever marketing. If it doesn’t work well, then it just doesn’t work. # Stability Stability is a cornerstone of trust. A critical component of DX is to ensure uptime and dependable performance. Stability also manifests in the ability to rectify errors to avoid critical failure. Without stability, your product becomes unreliable, making your ‘amazing’ functionality irrelevant. # Ease of Use Developers hate to take their hands off the keyboard. Every movement to a mouse or trackpad feels like a Herculean task. *Ease of use* does not just mean the tool is easy to navigate, but it means that you can access things quickly and efficiently. Keyboard shortcuts, tabular navigation, saved preferences, and intuitive searching/filtering should all increase the speed with which developers can interact with your application. However, *ease of use* is also about performance. User interfaces that take seconds to load instead of milliseconds can be the difference between usable and debilitatingly frustrating. # Clarity This category is the closest to aesthetics. DX is about delivering an intuitive interface that surfaces critical information, mitigates user error (ex. confirmation dialogues on critical tasks), and provides visibility into your orientation (ex. navigation through affordance). Clarity is about the developer having full visibility into the potential consequences of an action and into the history of their actions (ex. auditing and analytics).
- # Function Function is absolutely paramount. A developer tool is only as good as the functionality it delivers. You cannot mask subpar functionality with beautiful aesthetics or clever marketing. If it doesn’t work well, then it just doesn’t work. # Stability Stability is a cornerstone of trust. A critical component of DX is to ensure uptime and dependable performance. Stability also manifests in the ability to rectify errors to avoid critical failure. Without stability, your product becomes unreliable, making your ‘amazing’ functionality irrelevant. # Ease of Use Developers hate to take their hands off the keyboard. Every movement to a mouse or trackpad feels like a Herculean task. *Ease of use* does not just mean the tool is easy to navigate, but it means that you can access things quickly and efficiently. Keyboard shortcuts, tabular navigation, saved preferences, and intuitive searching/filtering should all increase the speed with which developers can interact with your application. However, *ease of use* is also about performance. User interfaces that take seconds to load instead of milliseconds can be the difference between usable and debilitatingly frustrating. # Clarity This category is the closest to aesthetics. DX is about delivering an intuitive interface that surfaces critical information, mitigates user error (ex. confirmation dialogues on critical tasks), and provides visibility into your orientation (ex. navigation through affordance). Clarity is about the developer having full visibility into the potential consequences of an action and into the history of their actions (ex. auditing and analytics).
- DEx (term used by Fagerholm and Münch) consists of experiences relating to all kinds of artifacts and activities that a developer may encounter as part of their involvement in software development. These could roughly be divided into experiences regarding i) development infrastructure (e.g. development and management tools, programming languages, libraries, platforms, frameworks, processes, and methods, ii) feelings about work (e.g.respect, attachment belonging), and iii) the value of one’s own contribution (e.g. alignment of one’s own goals with those of the project, plans, intentions, and commitment). (Source: Fabian Fagerholm and Jürgen Münch)
- DEx (term used by Fagerholm and Münch) consists of experiences relating to all kinds of artifacts and activities that a developer may encounter as part of their involvement in software development. These could roughly be divided into experiences regarding i) development infrastructure (e.g. development and management tools, programming languages, libraries, platforms, frameworks, processes, and methods, ii) feelings about work (e.g.respect, attachment belonging), and iii) the value of one’s own contribution (e.g. alignment of one’s own goals with those of the project, plans, intentions, and commitment). (Source: Fabian Fagerholm and Jürgen Münch)
- UX is typically looking at an application, website, etc. DX takes a wider approach. How developers work with the pieces.
- Fancy text editor.
- Like a chatbot with your computer. How you start and stop programs.
- Google docs for developers. You upload your code, someone else can edit it, and another person can complain about it.
- You have these in your browser already!
- This lets people play around before they code.
- Like Yahoo! Answers for developers.
- Like Yahoo! Answers for developers.
- Like Yahoo! Answers for developers.
- Companies believe developers hang out in the portal and use additional services.
- In reality, developers could care less about your portal. They’re thinking about their own app. They mostly use your portal to get their credentials and find out why things don’t work.
- 500 user created packages for Stripe API
- Vue and stripe are both incredibly popular tools, but Stripe owns none of this content.
- Those tools we saw, there are multiple options for each one.
- PubNub had 70+ SDKs. Each of these is a product. Not to mention that with mature APIs, people are operating at many different versions.
- Let’s bring it back. We can use traditional UX tools to understand developers.
- We can use what we know about UX to develop DX frameworks.
- This is a typical UX journey.
- Here’s our DX journey.
- I actually really like the CX graph about touchpoints.
- These are not hard rules.
- These engineers have never been “new” so they don’t know how to explain them.
- Often uttered by engineers who are too busy.
- Maintenance is a nightmare. This is a new problem as the API space has matured.
- Except developers don’t like submitting feedback.
- Engineering moves fast.
- Anyone who actually understands the API is tasked with supporting customers over improving the product.
- Join mailing list, etc
- That’s where this video came from
- How much time is spent in each application? How long until developer starts coding?