From a video of the talk of the same name, given by rangle.io founder Nick Van Weedenburg on 4/18/15, link here.
- Do much less upfront UX, which can create something with apocryphal authority (“the spec” to be followed throughout time, even after learning new things)
- Commit to using upfront UX as a hypothesis
- Treat code heavily used by users as the final design authority
- Partition UX for different purposes
- Define UX as a list of core values your product abides by, not as a specific solution
- Consider the initial UX design as a starting point and a hypothesis, not a destination
- Any separation between team conversations/design and software validation risks giving the design with false authority, due to lost context
- Testing lessens the gaps between what the team thinks they’re developing and what the user needs really are
Rangle’s process:
- Rapid conceptual UX to get an initial understanding
- Interactive prototyping
- Lo-res mockup and a few example hi-res mockups
(1-3 should take 1-2 weeks max or you need to break down the project into modules)
4. Style guide
5. Development delivering working software for testing
6. Iterate based on learnings until it’s ready to ship!
7. Document the final UX from experiences of user validation. Outline core values of the design and user experience
Development used to focus on (in order of importance): Functional, Reliable, Usable, Emotional Design but that’s backwards
Lean UX should rely on (in order of importance):
- Likability (relatibility)–making something people actually like and want to use
- Usability–not only do people want to use it, but they can easily use it
- Reliability–users can understand the logic (IA, UI, content strategy) across the site–and over time. They don’t have to learn and relearn how the site works
- Functionality–the features people will actually use
See sample style guides at styleguides.io
