Profile picture
, 4 tweets, 1 min read
My Authors
Read all threads
Stories DO NOT describe “an experience.” That’s UX thinking, but not Agile thinking. Stories describe your users work (in the domain). They do not describe computer programs. Their “experience” when using the program is an implementation detail. It is NOT part of the story. 1/
Work out those implementation details with a conversation you have just before building. Hours before, not days or weeks. Doing UX work surrounding “experience” in advance of implementation is waterfall thinking. Don’t get caught in that trap. 2/
For the most part, design as you implement. Design iterations are also implementation iterations. Think, build, get feedback, modify. Designers and devs must work collaboratively to do this, not in silos. 3/
Up-front design is waterfall, even if there are iterations in your up-front-design process. Start thinking about experience as you start thinking about the code. Build both simultaneously and iteratively. 4/4
Missing some Tweet in this thread? You can try to force a refresh.

Keep Current with Allen Holub

Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

More from @allenholub see all

Profile picture
Allen Holub
@allenholub
The Ariane 5 Failure provides one of the most interesting examples of software failing because of reuse. 1/

(The report is at sunnyday.mit.edu/nasa-class/Ari…) 2/
In a nutshell, the problem was that they strapped a component from the Ariane 4 onto the more-powerful 5. Because of that extra power, censors started sending out numbers that were unexpectedly large. The resulting overflow cause caused the explosion. 3/
Read 6 tweets
Profile picture
Allen Holub
@allenholub
My notions on testing were largely influenced by my high-school physics teacher. He handed out the exams to everybody a couple weeks before the test. People were shocked. "Don't worry," he said, "it won't make any difference." And indeed, that was true. 1/7
The people who would otherwise have gotten A's, go A's. And the F students failed. His point was that it was unfair for us not to know what he expected us to know, and if we knew enough to be able to do the exam, he was happy. 2/7
You can't learn physics in two weeks, so the screwups, even if they were motivated, couldn't fully catch up. They didn't bother, though. 3/7
Read 7 tweets
Profile picture
Allen Holub
@allenholub
A week or so into my first CTO gig (I was brought in to help rescue a failing startup), a team returned from a trip to the customer where they were demoing something that my predecessor had been working on for months. I asked "how'd it go"? 1/3
They responded "the customer doesn't want it. They say they solved that problem six months ago." All the feedback during development came from an internal PM—an "industry expert," someone with "extensive experience." 2/3
He was in no way a replacement for actual conversations with actual customers. 4 devs working for 6 months—money down a hole. No wonder they were failing. 3/3
Read 3 tweets

Embed code for your website

×
Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!