Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Kill the documentation
1
We spend too much time generating
documentation which stops us 

creating fucking awesome stuff
THE PROBLEM
RWE UI AND VISUAL GUIDELINES
One page
pdfs
Rules,
logic and
guides
I think it was great to have a design reference for
every element being used. But, for example, the
amount of different li...
I think it was great to have a design reference for
every element being used. But, for example, the
amount of different li...
Lastenheft
Anforderungsspezifikation AKA Requirements Specification
ŠKODA LASTENHEFT
Sexy
Excel
shit
Annotate
everything
Guys! 

It will take me too long to document this,
so you can’t design it like that
An actual real life BA we work with
TH...
Guys! 

It will take me too long to document this,
so you can’t design it like that
Patrik Alušík Accenture CZ
THE VOICE O...
CREDIT SUISSE DCP UX FLOWS
UI Elements
The platform contains various interface elements that helps the user to navigate an...
THE VOICE OF REASON
I was not there at the beginning of the
project but I came to learn that the vision
was very strong.
U...
THE VOICE OF REASON
I was not there at the beginning of the
project but I came to learn that the vision
was very strong.
U...
Edible Product Creation
13
RFPC
Customers 

Complete your form BUT
keep this information to
yourselves.
Then meet your…
Brief
Clients

Go and find th...
Presentation time
Made in Berlin
We sketch
ideate and
propose
We create
flows and
examples
We present
and test
We reference
and handover 

to build
Our curr...
We’re moving
towards this
approach…
THINK DESIGN
Code Module
HTML
Application
Craft Atlassian
Sketch Invision Code
Folio B...
Ai
Ps
Ae
and potentially
something like
this…
THINK PROTOTYPE BUILD
MIXED FIDELITY
</>
DESIGN
Design
delightful
interactio...
Need
Technical landscape
Context
Technical definition
Vision
Principles
Context
Technical definition
Vision/approach
Princ...
Owns the user needs
User Experience
Quality Assurance
Defines test protocol
and validation
User Interface/Visual
Owns the b...
Lastenheft
Anforderungsspezifikation AKA Requirements Specification
UNIQUE TO OUR APPROACH
Going to code much earlier
Document design principles
Engineers are equal partners
in the design pr...
GENERAL BENEFITS
Stop wasting time…

put it to better use
Common view of the big
picture for all stakeholders
A language e...
WHAT DOES THIS MEAN FOR LIL’ OL ME?
Future quality more
important than past
decisions
Trust more important
than documentat...
WHAT DOES THIS MEAN FOR LIL’ OL ME?
https://uxriga.typeform.com/to/nhwr0D
Kill the documentation
Upcoming SlideShare
Loading in …5
×

Kill the documentation

110 views

Published on

UX Riga Masterclass by Fjord Berlin: highlighting the pitfalls of unnecessary documentation, and present their workflow, toolset and team set-up for lean digital product creation

Published in: Design
  • Be the first to comment

  • Be the first to like this

Kill the documentation

  1. 1. Kill the documentation 1
  2. 2. We spend too much time generating documentation which stops us 
 creating fucking awesome stuff THE PROBLEM
  3. 3. RWE UI AND VISUAL GUIDELINES One page pdfs Rules, logic and guides
  4. 4. I think it was great to have a design reference for every element being used. But, for example, the amount of different list items made it hard to get an overview of the principles behind it – when I was going over the app with Katrin, these became clear to me. So maybe next time you could add a section (wireframe instead of design?) explaining the general ideas/thoughts and rules/exceptions for an element. THE VOICE OF THE DEVELOPER
  5. 5. I think it was great to have a design reference for every element being used. But, for example, the amount of different list items made it hard to get an overview of the principles behind it – when I was going over the app with Katrin, these became clear to me. So maybe next time you could add a section (wireframe instead of design?) explaining the general ideas/thoughts and rules/exceptions for an element. THE VOICE OF THE DEVELOPER Describe principles
  6. 6. Lastenheft Anforderungsspezifikation AKA Requirements Specification
  7. 7. ŠKODA LASTENHEFT Sexy Excel shit Annotate everything
  8. 8. Guys! 
 It will take me too long to document this, so you can’t design it like that An actual real life BA we work with THE VOICE OF THE BA
  9. 9. Guys! 
 It will take me too long to document this, so you can’t design it like that Patrik Alušík Accenture CZ THE VOICE OF THE BA Designing a document not a product
  10. 10. CREDIT SUISSE DCP UX FLOWS UI Elements The platform contains various interface elements that helps the user to navigate and organize the content. Following we present a collection of the one currently in use. Checkboxe Active SettingsFiltersPre-bookings Account infoBookings Longest label 1515 Tabs 3 Tabs 2 Tabs 30px 30px 15px30px $ $ h # h Arrows Page Arrows Special Case - Back button Table Arrows fill: #00B2AC shadow: x, y: 0px, 2px blur: 4px 55px 55px 55px 55px border: 1px #00B2AC border: 1px #00B2AC cs-icon-font, 30px 36px 36px cs-arrow-right cs-icon-font, 24px cs-flyout-menu-arrow-left cs-icon-font, 24px 24px 24px b # text-color: #4594D1 font-size: 12px font-face: CSW07eT-Boldv4 text-color: #757575 font-size: 12px font-face: CSW07eT-Boldv4 Min width100px 45px 15px 15px NOTE: Always center align labels to the tab.NOTE: The longest label defines the width of the single tab. Each other tab will then use this same width with a the label centered aligned. Unselected opt Label Unselected opt Label 24px 24px 25px text-color: #20252B 10 font-size: 16px font-face: CSW07eP-L With label Label NOTE: ONLY DETAIL VIEWS incorporate a special case (back button), in order to navigate back to the preceding overview. See Header and Navigation.PDF 15px # 30px 15px 15px Multi-page PDFs Rules, logic and guides
  11. 11. THE VOICE OF REASON I was not there at the beginning of the project but I came to learn that the vision was very strong. Unfortunately something got lost during the course of the project. Maybe due to people turnover or by binding the vision to unlikely requests. I don’t think we provided a good feedback, and nobody was challenging the deliveries from a technical point of view up until later, so the designs could not address some specific platform limitations. This, coupled with some missing knowledge about the underlying framework to design upon, sometimes led to less than optimal coding or doubts. Don’t get me wrong, I think a designer might not need this kind of knowledge, but for a project like this it’s absolutely a must given the time constraints. I felt everybody was working very hard, but the time spent in learning and talking has its cost. Of course this might be due to agreements between parties at a contract level. However I sometimes felt the need to explain why some solutions were not complete or due to fail. And even then I was not completely understood having a design tweaked but ultimately being worse than before. In general I think key people turnover must be avoided. And the same level of expertise between designers is required when handing hover material during a turnover. This way the ‘history’ of a specification document, why It came to be is shared, understood could be not lost and the vision would stay intact. So, going back to the specs, the problem is that due to this happening they are sometimes incoherent. This leads to inconsistency in the implementation and ultimately to lower quality work. Again, I don’t mean a design should be monotone and boring but I felt we were missing the fact that a framework was to be built upon these specs and these were not properly addressing the need strong backing idea. Technically speaking when designing on a grid I would expect using the grid all over to exactly show how to apply it  (and write down) any specific deviation from it. Again this came very late and it was not applied consistently. The grid usage was, and is, the biggest problem of the specs. Especially since the regular bootstrap grid was violated. I would also suggest moving to a different kind of delivery, possibly directly with code prototypes. Sketch can do this. And the Invision flows should use full VDs. By doing this, some issues would be directly tackled at design level and no concerns would arise later when the check-ins are done. In general the KISS rule and the DRY rule for software development should apply to design too. It’s better to write clear rules than specify every detail. Our specs are too verbose. This leads to verbose implementation. I would suggest embracing Atomic Design. I do not know which design framework you are using, but I would also suggest embracing Design Thinking. This kind of expertise would guide creativity to solve some real world problems and producing some amazing artifacts.
  12. 12. THE VOICE OF REASON I was not there at the beginning of the project but I came to learn that the vision was very strong. Unfortunately something got lost during the course of the project. Maybe due to people turnover or by binding the vision to unlikely requests. I don’t think we provided a good feedback, and nobody was challenging the deliveries from a technical point of view up until later, so the designs could not address some specific platform limitations. This, coupled with some missing knowledge about the underlying framework to design upon, sometimes led to less than optimal coding or doubts. Don’t get me wrong, I think a designer might not need this kind of knowledge, but for a project like this it’s absolutely a must given the time constraints. I felt everybody was working very hard, but the time spent in learning and talking has its cost. Of course this might be due to agreements between parties at a contract level. However I sometimes felt the need to explain why some solutions were not complete or due to fail. And even then I was not completely understood having a design tweaked but ultimately being worse than before. In general I think key people turnover must be avoided. And the same level of expertise between designers is required when handing hover material during a turnover. This way the ‘history’ of a specification document, why It came to be is shared, understood could be not lost and the vision would stay intact. So, going back to the specs, the problem is that due to this happening they are sometimes incoherent. This leads to inconsistency in the implementation and ultimately to lower quality work. Again, I don’t mean a design should be monotone and boring but I felt we were missing the fact that a framework was to be built upon these specs and these were not properly addressing the need strong backing idea. Technically speaking when designing on a grid I would expect using the grid all over to exactly show how to apply it  (and write down) any specific deviation from it. Again this came very late and it was not applied consistently. The grid usage was, and is, the biggest problem of the specs. Especially since the regular bootstrap grid was violated. I would also suggest moving to a different kind of delivery, possibly directly with code prototypes. Sketch can do this. And the Invision flows should use full VDs. By doing this, some issues would be directly tackled at design level and no concerns would arise later when the check-ins are done. In general the KISS rule and the DRY rule for software development should apply to design too. It’s better to write clear rules than specify every detail. Our specs are too verbose. This leads to verbose implementation. I would suggest embracing Atomic Design. I do not know which design framework you are using, but I would also suggest embracing Design Thinking. This kind of expertise would guide creativity to solve some real world problems and producing some amazing artifacts. Document knowledge, learnings and history Understand the technology Describe principles Document once 
 and with context Design a product not a document
  13. 13. Edible Product Creation 13
  14. 14. RFPC Customers 
 Complete your form BUT keep this information to yourselves. Then meet your… Brief Clients
 Go and find the customer who has the same number as you, interview them using your questionnaire. Once done, return to your table and write the brief. Then meet with your Designer and BA… Design Designers
 Sketch the sandwich based on the brief. Then hand over to… Build Developers
 Build the sandwich based on the designs. Then… Annotate Business Analysts
 Take the sketch from the designer and annotate it making sure all is covered… Then hand over to… Part one / 3 mins Part two / 3 mins x 2 Part three / 3 mins Part four / 3 mins Part five / 3 mins
  15. 15. Presentation time
  16. 16. Made in Berlin
  17. 17. We sketch ideate and propose We create flows and examples We present and test We reference and handover 
 to build Our current flow kinda looks like this THINK PROTOTYPE DEVELOPDESIGN DOCUMENT
  18. 18. We’re moving towards this approach… THINK DESIGN Code Module HTML Application Craft Atlassian Sketch Invision Code Folio Bitbucket Openshift We create flows and examples We sketch ideate and propose PROTOTYPE DEVELOP We develop prototypes as reference
  19. 19. Ai Ps Ae and potentially something like this… THINK PROTOTYPE BUILD MIXED FIDELITY </> DESIGN Design delightful interactions We define Structure+ Content We define Structure + Content + Reference + Module We sketch ideate and propose
  20. 20. Need Technical landscape Context Technical definition Vision Principles Context Technical definition Vision/approach Principles User testing UX design User testing Visual design UI/Animation design Context Technical definition Vision/approach Principles User testing HTML CSS JS Library DISCOVER DESCRIBE DESIGN DEVELOP Context Technical definition Vision/approach Principles User testing HTML CSS JS Library RELEASE User Research User research User research User research User research hello confluence! we build a team consensus ensuring all key roles define objectives and opportunities External documentation, the high-level, micro, view Guidelines ENGAGE in an initial engagement we can identify and define the opportunities for brand development. Sprint 0 Sprints… Tada! Smart documentation
  21. 21. Owns the user needs User Experience Quality Assurance Defines test protocol and validation User Interface/Visual Owns the brand behaviour Content Defines content and strategy Front End Development Defines the technology Research and testing Manages insight gathering and user testing Build a team where everyone owns the product Business Design Defines the business opportunities hello team!
  22. 22. Lastenheft Anforderungsspezifikation AKA Requirements Specification
  23. 23. UNIQUE TO OUR APPROACH Going to code much earlier Document design principles Engineers are equal partners in the design process Building re-usable components Designers encouraged to 
 edit code
  24. 24. GENERAL BENEFITS Stop wasting time…
 put it to better use Common view of the big picture for all stakeholders A language everyone can understand (cognitive load) Respond to change quickly (being agile) Fail fast
  25. 25. WHAT DOES THIS MEAN FOR LIL’ OL ME? Future quality more important than past decisions Trust more important than documentation Freedom in exchange for commitment
  26. 26. WHAT DOES THIS MEAN FOR LIL’ OL ME? https://uxriga.typeform.com/to/nhwr0D

×