I'm Shad - Head of Design at Metomic, AMA 💪🏽

@xoalexo Great question, Alex - and sorry for the delay. Metomic makes a cookie widget product however it's a very small part of what we do. (as it should be) Though if elaboration is what you're seeking: Cookie consent concerns the UX of your Internet use as a whole, and so while others continue checking 'compliance' boxes - end-user control of data remains non-existent. Where do I control which third-parties Deliveroo shares my data with? Where is my opt-out? As of today, no company out there is achieving transparency or consumer trust around data. Internally we agreed that whilst not the sexiest problem, and given the breadth of bad UX across the Internet, cookie consent was the best place to start building a name for ourselves in privacy. Building the best cookie consent in the world was a good place to start, and now we're working towards much more interesting parts of your end-users 'data journey' through your organisation. If you're interested we just uploaded something that'll explain our thinking on Medium: https://medium.com/metomic-incog... I hope that answers your question 👍🏽

@tela Thanks for the question! The below is with the caveat that your mileage may vary from designer to designer. Handoff can be a pretty contentious thing to talk about in the context of product, but I'm happy to share experiences here. In my opinion handoff isn't a one-off thing, but a word that can be used to describe a process that should be continual - most design work should be intuitive enough to understand within the context of your org, but static screens will rarely cut it for high-quality implementation. You should have clickable prototypes at a bare minimum for qualitative feedback at least. It's for that reason I encourage junior designers I speak to to spend more time with engineers, as technical constraints, etc are incredibly important to bake into their personal workflows. Our handoff process internally looks a little like: 1) A feature is talked about within the product team 2) Designer takes away other stakeholders thoughts/feelings/technical constraints 3) Designer designs something with some ad-hoc collaboration with the person who would be implementing to ensure technical limitations aren't missed or all edge-cases are accounted for 4) Designer reviews after implementation to ensure there aren't any obvious issues in usability 5) 🚀 In terms of design as a motivator: it's always great for a designer to get remit to explore more vision-led ideas, and that's something I've found is great for getting folks excited about what's next or to remind the team that they can test ideas very easily without having to implement. Designers certainly have a bit of a superpower here, and I've seen that be used incredibly well by a handful of great PMs.

@tela I for one definitely begin losing steam if I design something and it's placed on a backlog for a month. I think this may be true of anyone working in a product team, we love shipping stuff, and it's fun to be involved in that process - whether you're a designer or engineer or anyone else on the product team. Generally speaking, the tighter you keep your design -> implementation feedback loops, the happier your designers (and engineers) will be in the long run. Thanks for your thoughtful question!

@jaya_bharath Hey man! Thanks for the question. What I really mean by this is how design should be viewed holistically in a company - i.e brand and product have intrinsic links and should be seen from the get-go as part of the same deliverable. It's important for good design not to be considered a single cog in the machine, but rather a mindset your company considers in all it does.