I turned the first part of the talk into a blog post: https://medium.com/@iamtenko/stop-looking-for-designers-become-one-291993a4f195#.40uli95c1 There has been a huge buzz in the last 1-2 years around the topic that "Everyone should learn how to code" and more specifically that "Designers should learn how to code". Why is this not happening the other way around? Can brainstorming, user research, personas and design thinking change the way we write software? Can we adopt the same army-knives used by design agencies and freelancers to speed up the development of Software or to better prioritise some features over others? This talk has been given at ViewSource Conference 2016. Berlin, 14th of September 2016

1. STOP LOOKING FOR
DESIGNERS. BECOME ONE!
On why developers need to learn design.

2. DESIGNERS SHOULD LEARN
HOW TO CODE.
Kids too. And grandparents. And your dog.

3. WHAT ABOUT
DEVELOPERS?

4. DEVELOPERS vs. DESIGNERS

5. AWS IS A PLATFORM TO
HELP DEVELOPERS RUN
THINGS IN THE CLOUD™

8. USABILITY
Yes. Developers need usable tools too.

9. "HEY, WE JUST FINISHED
IMPLEMENTING THIS. LET'S
CALL THE DESIGNERS AND
MAKE IT LOOK NICE!"
cit. "Unknown developer", all the times.

10. NO!

11. USER EXPERIENCE DESIGN
(UX)
Human-Machine interaction

12. DESIGN AS A SERVICE™

13. BUSINESS NEED

14. BUSINESS NEED
DESIGN AGENCY

15. BUSINESS NEED
DESIGN AGENCY
DEVS IMPLEMENTATION

16. BUSINESS NEED
DESIGN AGENCY
DEVS IMPLEMENTATION
???
PROFIT

17. TODAY IS DIFFERENT
Agile methodologies, design thinking.

18. BRAINSTORM
PROTOTYPE
SHIP
TESTING
ITERATE ON PROTOTYPE

19. WE ARE NOT "JUST"
SOLVING A PROBLEM.
WE DELIVER AN EXPERIENCE

20. TASK DRIVEN TEAMS
VS
USER DRIVEN TEAMS

21. TASK DRIVEN TEAMS
They find a solution to a specific business or technological
problem

22. USER DRIVEN TEAMS
They solve a user problem

23. FROM TASK SOLVERS TO
EXPERIENCE CREATORS

24. USER CENTERED DESIGN
Design based on the needs of the user.

25. "[..] simplifying the structure of tasks,
making things visible, getting the mapping
right, exploiting the powers of constraint,
designing for error, explaining affordances
and seven stages of action. [..]"
https://en.wikipedia.org/wiki/Don_Norman#User-centered_design

26. PERSONA
SCENARIO
USE CASE

27. PERSONA: "[..] is fictional character
created to represent the different
user types that might use a site,
brand, or product in a similar way.
[..]"
https://uxthink.wordpress.com/2010/11/30/using_scenarios/

28. SCENARIO: "[..] is a fictional story
about the "daily life of" or a
sequence of events with the
primary stakeholder group as the
main character. Typically, a persona
that was created earlier is used as
the main character of this story. [..]"
https://en.wikipedia.org/wiki/User-centered_design#Analysis_tools

29. USE CASE: "[..] describes the
interaction between an individual
and the rest of the world. [..] may
consist of intricate details and
interactions between the actor
and the world. [..]"
https://en.wikipedia.org/wiki/User-centered_design#Analysis_tools

30. CULTURAL CLASH

31. ILLUSTRATOR
USER RESEARCH
WIREFRAME
You designers are better. That's fine, it's your job.

32. IT'S ABOUT UNDERSTANDING
THE IMPLICATION OF WHAT
WE ARE IMPLEMENTING

33. IT'S ABOUT TESTING
AND KILLING
OVER-ENGINEERING

34. IT'S ABOUT SPEAKING THE
SAME LANGUAGE

35. IT'S ABOUT CREATING
AN EXPERIENCE.

36. NOW: RELEASE YOUR
FRUSTRATION!!

37. DEVS FAULTS:
We are used to talk to machines

38. DEVS FAULTS:
We are used to talk to machines
We have a superiority complex

39. DEVS FAULTS:
We are used to talk to machines
We have a superiority complex
Our users are stupid

40. DEVS FAULTS:
We are used to talk to machines
We have a superiority complex
All users are stupid

41. HOW DO WE FIX THIS?

42. WORK NEXT TO EACH OTHERS

43. PRINT YOUR PERSONAS

44. MAKE THE DEVS PARTICIPATE
TO USER TESTING

45. MAKE THEM DESIGN

46. COMMUNICATE.
AS PEERS

47. SUGGESTIONS?
EXPERIENCES?

48. THANK YOU.
@iamtenko
hi@tenko.it
www.tenko.it