Jess Eddy
Jess Eddy
Jul 20, 2017 · 2 min read

Hi Kevin Lappe! Thank you for your questions. I’ll answer as best I can — turned out to be some long answers!

  1. “In this framework, where are the tradeoffs made to design related execution.”
    Ideally there are none but that’s rarely the case. You might want to check out this post I wrote about designers and developers working together to implement great UI’s: https://medium.com/@jesseddy/tips-for-designers-developers-working-together-to-implement-great-uis-e93ef179bf13. To answer your question, as a designer (and developer) working against deadlines — time almost always produces a tradeoff with the quality of work that can be done. Designers need time to go through the design process and iterate until they feel a design can’t get better. Good design takes time. That time is not always built into the Sprint — or sometimes orgs and or product managers don’t understand the amount of time that things take. Another tradeoff might be focus. As a designer, the goal is to stay one to two steps ahead of development in order to create enough definition for the next Sprint. If you have one designer in your company and they’re working with a small dev team — the designer may also have to address current tasks part of the current Sprint; this may take their focus away from using design to define the next Sprint. This results in context switching and can make it harder to focus and achieve flow.
  2. “Does the product team drive delivery timelines, while development and design negotiate on what experience is possible to create, test and deliver given time as constraint.”
    Basically, yes. Ultimately the product manager drives delivery timelines (sometimes the business may institute their own deadlines for certain things). Either way, ideally there is some flexibility timelines, specifically, adjusting timelines and moving things around based on the actual design work that gets done — i.e. the real scope of work. Really, everyone should be chiming in on delivery timelines — as designers and developers have a pretty good understanding of how long things take.
  3. “What role do you see the design taking related to testing the code developed specifically? Should design also lead the testing and delivery of the experience?”
    This is a good one! In that post I referenced earlier in this storybook of a reply — I mention that designer/developer pairing should take place before QA. So when items reach QA they’ve gone through design review (a sort of design QA). This gives the designer a chance to make sure the UI is implemented as intended, which may also include animations and generally clicking around on things and seeing what happens — QA of sorts. So, I do think design should lead QA a little bit in that QA should not be tasked with making design decisions — they should be able to focus on finding and reporting bugs, etc. A design-led process should cut down on the amount of QA tickets.

I hope this answered your questions! Feel free to get in touch with me if you have more. :)

)
    Jess Eddy

    Written by

    Jess Eddy

    Digital product designer. I write about design, teamwork and exercise. Currently in Sydney, AUS.

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade