Is having no limits a limitation [distilled version]

  • 684 views
Uploaded on

Case study from Euro IA 2013. What if you had time, money and autonomy to do whatever you wanted and build it exactly the way you wanted? Oh and to add, you also have no risk. What do you think would …

Case study from Euro IA 2013. What if you had time, money and autonomy to do whatever you wanted and build it exactly the way you wanted? Oh and to add, you also have no risk. What do you think would be your biggest challenge in building a large scale product this way? Content? Structure? Or is the biggest challenge that there were no boundaries?

More in: Technology , Design
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
684
On Slideshare
0
From Embeds
0
Number of Embeds
5

Actions

Shares
Downloads
1
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Is having no limits a limitation? Ben Brignell @benbrignell
  • 2. Who are you, Ben?
  • 3. benbrignell.com
  • 4. Merchants • Table management tools • Online bookings • Reporting • Optimisation • APIs, aggregators • Marketing • Partners
  • 5. • Websites • Apps • Services • Deals • Offers • Online booking Consumers
  • 6. Transaction
  • 7. Content biggest inventory real-time time-sensitive high-value deals exclusive promotions dynamic merchandising user generated inspirational offers local contextually aware social
  • 8. Technology mobile first responsively designed fast touch-optimised progressively enhanced future-friendly accessible modularised data-driven innovative API centric RESTful invisible easily scalable extendable
  • 9. Experience recommended locally focusedrelevant self-learning smart dynamic predictive personalised joined-up funhuman easy serendipitous trustworthy prepared
  • 10. It sounds kind of okay, so what’s the problem?
  • 11. We want to build this
  • 12. But if we build on what we have now we’ll end up with this
  • 13. Technical debt Why so negative? Limited CMS Legacy code, content, images APIs not up to the job Also, did I mention technical debt?
  • 14. Objective:
  • 15. Build completely from scratch. Objective:
  • 16. 2 months. Just to figure out how to do this.
  • 17. Tools down!
  • 18. We wanted to be in a position where we could innovate like a startup …even though we started up over 10 years ago
  • 19. We had a tried and tested business model that worked. It just wasn’t scalable.
  • 20. In order to go from this…
  • 21. To this.
  • 22. Time We asked for… Money Autonomy The chance to recruit a new team …to build whatever we wanted
  • 23. v2
  • 24. Content Technology Experience
  • 25. This page is intentionally left blank
  • 26. But what do we become without them? We get frustrated by our limitations Did we need to set artificial constraints to help us?
  • 27. We had a lot of decisions to make
  • 28. Decision making isn’t black and white
  • 29. Frameworks Limitless choice Node, .NET, Ruby on Rails, PHP? Automated testing Sass? Less? Building a device lab
  • 30. Frameworks Limitless choice Node, .NET, Ruby on Rails, PHP? Automated testing Sass? Less? Building a device lab
  • 31. Frameworks Limitless choice Node, .NET, Ruby on Rails, PHP? Automated testing Sass? Less? Building a device lab
  • 32. Frameworks Limitless choice Node, .NET, Ruby on Rails, PHP? Automated testing Sass? Less? Building a device lab
  • 33. Frameworks Limitless choice Node, .NET, Ruby on Rails, PHP? Automated testing Sass? Less? Building a device lab Disruption
  • 34. Frameworks Limitless choice Node, .NET, Ruby on Rails, PHP? Automated testing Sass? Less? Building a device lab Disruption Device fatigue
  • 35. Frameworks Limitless choice Node, .NET, Ruby on Rails, PHP? Automated testing Sass? Less? Building a device lab Disruption Device fatigue Dogma
  • 36. Frameworks Limitless choice Node, .NET, Ruby on Rails, PHP? Automated testing Sass? Less? Building a device lab Disruption Device fatigue Dogma Debate
  • 37. Frameworks Limitless choice Node, .NET, Ruby on Rails, PHP? Automated testing Sass? Less? Building a device lab Disruption Device fatigue Dogma Debate Opinions
  • 38. Frameworks Limitless choice Node, .NET, Ruby on Rails, PHP? Automated testing Sass? Less? Building a device lab Disruption Device fatigue Dogma Debate Opinions
  • 39. Frameworks Limitless choice Node, .NET, Ruby on Rails, PHP? Automated testing Sass? Less? Building a device lab Disruption Device fatigue Dogma Debate Opinions
  • 40. Frameworks Limitless choice Node, .NET, Ruby on Rails, PHP? Automated testing Sass? Less? Building a device lab Disruption Device fatigue Dogma Debate Opinions
  • 41. Frameworks Limitless choice Node, .NET, Ruby on Rails, PHP? Automated testing Sass? Less? Building a device lab Disruption Device fatigue Dogma Debate Opinions
  • 42. Frameworks Limitless choice Node, .NET, Ruby on Rails, PHP? Automated testing Sass? Less? Building a device lab Disruption Device fatigue Dogma Debate Opinions
  • 43. Frameworks Limitless choice Node, .NET, Ruby on Rails, PHP? Automated testing Sass? Less? Building a device lab Disruption Device fatigue Dogma Debate Opinions
  • 44. Frameworks Limitless choice Node, .NET, Ruby on Rails, PHP? Automated testing Sass? Less? Building a device lab Disruption Device fatigue Dogma Debate Opinions
  • 45. Frameworks Limitless choice Node, .NET, Ruby on Rails, PHP? Automated testing Sass? Less? Building a device lab Disruption Device fatigue Dogma Debate Opinions
  • 46. Frameworks Limitless choice Node, .NET, Ruby on Rails, PHP? Automated testing Sass? Less? Building a device lab Disruption Device fatigue Dogma Debate Opinions
  • 47. Right Wrong
  • 48. LESS WRONG
  • 49. Just make the decisions
  • 50. Prototyping
  • 51. If a picture is worth 1000 words, a prototype is worth 1000 meetings @markdrasutis
  • 52. Responsive prototypes
  • 53. One of the benefits of paper is its limited scope, its simplicity. Designing on paper Anybody in the team can join in during the design process.
  • 54. Review snippet Opening times Image Name Star rating / Cuisine Location details
  • 55. Thinking with paper
  • 56. Responsive design
  • 57. 85.9MBAnd it took up about half a gig of RAM
  • 58. £500in data roaming charges
  • 59. Responsive design is a content problem. Responsive design is hard.
  • 60. GOAL
  • 61. The goal posts keep moving
  • 62. Cut the mustard
  • 63. Cut the mustard
  • 64. Content Dumb devices Smart devices and search engines
  • 65. Low level pagination To illustrate 1 2 3 4 5 … next »
  • 66. To illustrate Show more High end pagination
  • 67. …when media queries just aren’t enough
  • 68. Mode User interaction Device Viewport Navigation Exploration Resizing Resizing
  • 69. It started to get very complex very quickly
  • 70. Small Large
  • 71. Limit the design
  • 72. Search
  • 73. How did we improve performance by setting limitations? Search Search
  • 74. We could have spent hours on dull documentation, tests and rigid specifications… We were just a team of guys doing stuff
  • 75. What if we communicated the specs for search with a compelling challenge? But that’s kind of boring
  • 76. Search by name or location
  • 77. P Paddington Station Peppe’s Italian Bistroteque Pizza Express Search for “Pizza” Prince Regent Hotel
  • 78. Search by name or location Best score: Around 160 milliseconds per character in between keystroke
  • 79. “Let’s get this to 159 milliseconds per keystroke or less guys…” We could have said:
  • 80. Of course Would 158 milliseconds have met the criteria?
  • 81. Putting it that way seemed more technical and less about the user It would have solved the technicalities… …but maybe something more abstract would have helped the team think about the user
  • 82. P Paddington Station Peppe’s Italian Bistroteque Pizza Express Search for “Pizza” Prince Regent Hotel
  • 83. P Paddington Station Peppe’s Italian Bistroteque Pizza Express Search for “Pizza” Prince Regent Hotel
  • 84. We said we would consider it a failure if the user hit ‘search’ Of course they could still use it But this limitation got everyone thinking about performance and context
  • 85. Great for the user We came in at under 100ms anyway Great for the team
  • 86. Artificial constraint
  • 87. How did we do?
  • 88. We had to change our mentality Stop thinking about the edge cases. Think about the MVP.
  • 89. Our work was the foundation We were preparing ourselves to be able to solve any problem We were considering any problem But we didn’t need to solve them now
  • 90. The MVP
  • 91. No doubts there… Our limitations often frustrate us
  • 92. But even astronauts need limits
  • 93. Limit scope of the design Think with paper Just make the decisions Artificial constraints The MVP has to have limits
  • 94. They weren’t inherited. The important thing is the constraints were put in by us.
  • 95. Take a soon, bookatable.com
  • 96. Take a soon, bookatable.com
  • 97. Thank you for watching