Design Workflows for Rails

Transcript

1. Design Workflows Rails John W. Long Twitter: @johnwlong for

2. None
3. None
4. None

5. Rails + Ruby I

6. Designer / Developer

7. @thesassway Latest news on Sass + Compass

8. Feedback & Support

9. Design Workflows Rails for

10. 1. Passionate Users 2. Fewer Support Issues 3. Easier to

    Program 4. Competitive 5. Conversions 6. It’s fun! Why Design?

11. 1. Users First 2. Guides Users 3. Avoids Surprises 4.

    Delights 5. Lightweight 6. Compromises Good Design

12. Business Design Development Product Design .

13. 1. No Design 2. Prettify This 3. Big Upfront Design

    4. Iterative Design Approaches

14. Development Iterative Design +

15. Think Big Build Small

16. Build the smallest thing possible that will validate or invalidate

    your idea.

17. Core Idea

18. Get Feedback (End Users + $$ People)

19. What do you think about this? Would you actually pay

    money for this? How much? How can we make this better? Should we remove anything?

20. Iterate

21. Maximize Learning

22. 1. An Idea 2. An Assertion 3. An Experiment 4.

    Customer Feedback Customer Development

23. User Stories Iterative Workflow Customer Feedback Design/Prototyping Development

24. User Stories

25. Allow a [type of user] to do [action] Example 1

26. Allow a regular user to do [action] Example 1

27. Allow a regular user to post a status update Example

    1

28. Allow a regular user to post a status update when

    they are signed in. Example 1

29. Allow a user to view details about another user Example

    2

30. Allow a regular user to view an activity stream generated

    from other users interactions across the system Example 3

31. Allow a regular user to keep track of what his

    friends are doing on our site Example 3

32. User Stories 1. Start here 2. Loose definitions / big

    picture 3. Keep team focused on end user 4. Wonderful with clients 5. Single most important tool

33. http://cukes.info/

34. Like a Pirate Prototyping

35. Whiteboards

36. USERNAME PASSWORD SIGN

37. Whiteboards • Great for brainstorming with customers • Great for

    illustrating flow • Lightweight • Hard to take with you

38. Wireframes

39. Paper Prototypes

40. What

41. Balsamiq Mockups http://balsamiq.com/

42. None
43. None

44. Wireframes • Moderately lightweight • Capture more detail • Easy

    to showoff to customers and stakeholders • Anyone can build them

45. Hi-Fi Mockups

46. None
47. None
48. None

49. Hi-Fi Mockups • One step from HTML • Help establish

    look & feel (also tone) • Typically require professional help • Most potential for error

50. HTML Prototypes

51. None
52. None
53. None

54. HTML Prototypes • Allow you to test flow • Can

    be improved over time • Great for client and customer conversations • Can leveraged for actual application (1/4 effort; makes estimating a cinch)

55. Functional Prototypes

56. Functional Prototypes • Great for refining algorithms, user interactions, gestures,

    anything that is complex • Also great for client and customer conversations • Don’t need to be written in/for target language or platform • May also be leveraged for the actual application

57. Designers Rails Tools for

58. http://get-serve.com

59. Demo

60. Serve • Made for designers • Rails newbies are right

    at home • Keeps designers out of the app • Can become unwieldy with iterative design/dev cycles http://get-serve.com

61. Showoff http://github.com/adamlogic/showoff

62. • Rails Plugin (direct integration) • Creates a “/mockups” route

    • Use app layouts/partials/etc • Great for iterative development http://github.com/adamlogic/showoff Showoff

63. Other Options • Nesta • Middleman • StaticMatic? • Brochure

64. Rails❤ Designers?

65. The Challenge What can we do to make it easier

    for designers to get started with Rails?