veyepar: User-Story Driven Docs

Author(s):	Joao Fernandes
Location	Crystal Ballroom
Date	may Mon 18	Days Raw Files
Start	15:45	First Raw Start	15:44
Duration	00:15:00	Offset	0:00:28
End	16:00	Last Raw End	16:02
Chapters	00:00 0:00:05 0:00:25
Total cuts_time	16 min.

http://lanyrd.com/2015/writethedocs/sdmwyd/
raw-playlist raw-mp4-playlist encoded-files-playlist host public tweet mp4 svg png

assets release.pdf UserStory_Driven_Docs.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

At OutSystems we make an awesome development platform, but our documentation wasn&#39;t that awesome. We focused on describing each button available on the user interface, and not the user intentions and goals.
A clear example of this, was that we had a full documentation page for the find text feature (CTRL+F). It described in excruciating detail every option available on the UI, but didn&#39;t told our users how they could actually find what they needed!
For us it was a nightmare to maintain the docs. Our development environment was constantly changing and we couldn&#39;t keep up with the changes.
More importantly, we weren&#39;t meeting the user needs. And that was clear from pages with a single-digit page view, and from the feedback we got from our customers.
Due to this approach, we also ended up having page titles that were feature-oriented, which is not the best for SEO. For instance, the doc page for the find text feature was called &quot;Find Tool&quot;. Who in their right mind would search for that on Google?
In this talk I&#39;ll tell you the story of how we stopped trying to document the UI, and started creating user-story driven docs. We now focus on what the user wants to achieve and how to achieve it, independently of how many windows or buttons they need to go through.
I&#39;ll cover:
How you can check if you&#39;re documenting the UI, and why you should avoid doing it
Why users stories work better for our users
How focusing on user stories changed the culture of our team and allowed us to work on what really matters.
I&#39;ll also share some unexpected outcomes, like how this lead us to work closer than ever with the development teams. Now our users get twice the cake: better features and better docs!

Comment:

production notes