• How to Design Experiences the Adaptive Path Way! (Or Not.)

    It’s a conversation I’ve had many times with fellow designers over the years.

    THEM: Hey, Adaptive Path! We use your (insert name of tool or method here) all the time!

    ME: That’s great!

    THEM: Well, I have to confess that we don’t quite use it the way you’d want…

    ME: (frowns)

    Now, that frown you see may not be for the reason you think. I’m not frowning because people don’t follow the methods we share to the letter. I’m frowning because they seem to think that’s a problem.

    It really gets right back to the reason we talk about our methods in the first place.

    In the course of a given year, an experience designer may have the opportunity to take on as many as half a dozen discrete projects—if they’re lucky. Usually it’s fewer than that. That simply doesn’t afford an individual many test cases to try out new ways to do our work. Constrained by our own first-hand experience, the evolution of each designer’s practice would be very slow indeed.

    So we look to each other. We talk to the other designers we work with, if we’re lucky enough to have them. We go to conferences, design jams, and local meetups. We read books and blog posts. And our practice is enriched as a result.

    But! This whole arrangement only works if we feed back what we’ve learned into the larger system. By sharing what we’ve learned, we raise each other up. But we can’t extend and build on the knowledge we’ve received if we aren’t willing to tinker with it. Experiment. Maybe break a few things.

    I’ve often described my point of view on this as, “Take what you can use, leave the rest.” But on reflection, it may be more accurate to say: “Take what you can use now, save the rest for another day.” Tools and methods are created in the context of solving particular problems, and just because something isn’t a good fit now doesn’t mean it won’t be useful later. It’s about increasing the number and diversity of tools at your disposal, not strict adherence to a particular doctrine.

    We don’t share our methods because we’re dogmatic about them. It’s quite the opposite, actually: We share our methods because we want to see them evolve, change, and grow.

    There are 4 thoughts on this idea

    1. Jason Grant

      Excellent little write up. Thank you for sharing. I’m sending this to my (current) team straight away as it hits right at the heart of what I’ve been talking to them about. It should be a relatively basic thing to know and remember, but so often gets forgotten and ignored. At one point I wanted to be a ‘process guy’ and after attempting to shoehorn the universe (purposeful use of small ‘u’) into a linear, predictable flow, I realised it was a stupid exercise. Then I became a ‘talker’, instigating other people around me to chat to me, sketch to me, explain to me, etc. They hate me to start off, but then eventually they cave into what you have written here and see the light. Then they become … designers for the first time in their lives. 🙂

    2. Pingback: UX Links for the week ahead (Week 7) - Foolproof Labs' Blog

    3. Pingback: There’s no Wrong Way to use a Reeses – Marli Mesibov: Content Strategist & Writer

    4. T S S Ganesan

      Very nicely and rightly written. Thanks.

    Add a Thought

    Slide to Submit

  • Close
    Team Profile