Recommended
More Related Content
What's hot
What's hot (13)
Similar to Bridging the gap
Similar to Bridging the gap (20)
More from UXDXConf
More from UXDXConf (20)
Recently uploaded
Recently uploaded (20)
Bridging the gap
- 1. Proprietaryand confidential Bridging the gap 2/25/2020 Anusha Dayananda Software Development Manager
- 2. Proprietaryand confidential Hi, I’m Anusha
- 3. Proprietaryand confidential 1. Stakeholders 2. Identifying the gap 3. Building the bridge 4. Examples 5. Best Practices
- 4. Proprietaryand confidential Who is involved in making a idea into production ready system? Stakeholders Why and what are we building? 1. Product How do I humanize the technology? 2. Design Now build it per specifications / requirements 3. Engineering
- 5. Proprietaryand confidential We take these into considerations: ● Infrastructure ● Performance ● Risks ● Stability ● Reliability ● Consistency ● Edge cases that impacts overall design (both UI and backend) ● Security ● Clean code ● And many more What does engineering do?
- 6. Proprietaryand confidential ● We are problem solvers What does engineering actually do? ● We provide insights on short-term/long-term possibilities ● We are your insurance policy/we can see the future ● We provide multiple options to solve the same problem ● We think about foundations for future work ● Our research and investigations expose us to trends in the market ● We are all about flowcharts and algorithms. Every arrow needs to go somewhere
- 7. Proprietaryand confidential is a gold mine Engineering
- 8. The devil is in the details
- 9. Example
- 10. Proprietaryand confidential Idea Contributor uploads a file Our application validates the file to check if it meets requirements Displays a bunch of nice messages to users User can fix and retry
- 12. Proprietaryand confidential Best practices ● This trio must constantly communicate and communicate from the onset. ● Ask yourself if the feature/product requirements have taken the Engineering aspects into consideration and if not, make that your mission to get answers from the trio. ● Learn to think like Engineers- start with a flowchart. ● Help Engineers to think like you- expose Engineers to the front lines. ● The bridge should be two-way. Be open to ideas/thoughts flowing from Engineers as well. Build the bridge
- 13. Proprietaryand confidential Product Design Engineering
- 14. Proprietaryand confidential Product Design Engineering
- 16. Proprietaryand confidential ● Eliminate duplicate work + Save time and effort ● Consistent UX cross-platform ● Realistic timelines and effort estimation ● Shipping a successful product ● Leverage full stakeholder expertise ● Workplace satisfaction ● We finally speak the same language Benefits We can be truly Agile
Editor's Notes
- I wanted to start out with a brief introduction of myself, my background and my current role. My current role is: xx, at Shutterstock. I know this is last talk of the day and I am going to make this as fun and interesting as possible., Shutterstock is a leading global technology platform At Shutterstock, we make images, video and music available for commercial license and provide tools to help make our customers lives easier. Tech company started 16 years ago with offices across the world. Nearly 1.9 million active customers from 150 countries Over 1 million contributors in 100 countries More than 300 mm images; over 1.5mm images added every week (look at the counter on the site and round down to the nearest million or use over 200,000 added every day) More than 17mm+ video clips; 1.5 mm 4K clips. (Checking these stats: over 90% HD, and over 70,000 videos added every week). In my current role, I lead the back-end engineering Content Pipeline team (for content ingestion) , I also have experience in the healthcare world, i previously spent over seven years working on a software development team in the healthcare technology industry, working to simplify healthcare data collection and reporting for hospitals and government organizations across the country. Over the past xx years, i’ve identified some gaps that exist between product/tech/engineers and came up with potential solutions on how to address them. This is important because with this collaboration products can be built in a more efficient way and keep us Agile….thats what im here to discuss The goal of this talk is to help you get perspective from Engineering to help you think differently - to eliminate weeks and hours of thinking through deisgns and having to rework it
- How many of you are engineers, product, designers How many of you (product and design) talk regularly with your engineering teams Do you feel like you always speak the same language I unlike many of you, am an Engineer, and in my view/perspective i want to paint my picture of the lanscape to you and how I see things. Let’s say we have a new idea brewing... For me: 1. Product Why and what are we building? And who is the audience? 2. Design How to I humanize the technology? They always do their research 3. Engineering Do you want us to build what is asked of us? Im here to talk about the value we do bring rather than being a last step There is a MYTH that we don’t want to be in meetings.
- We think about options, constraints, do we have the infrastructure in place, what's the downsides to building to this, pros and cons Breaking the perception of timelines - realistic timelines is the biggest benefit Here is where the Gap exists Most of you think of us a builders, create beautiful things that you’ve thought about What I want to emphasize is We are also a gold mine of ideas Rarely tapped ….. Well we are not just the builders of the feature.. It’s more than that.. We answer “What does it take to build it in the most logical way given the way things are architected right now””
- We think about options, constraints, do we have the infrastructure in place, what's the downsides to building to this, pros and cons Breaking the perception of timelines - realistic timelines is the biggest benefit Here is where the Gap exists Most of you think of us a builders, create beautiful things that you’ve thought about What I want to emphasize is We are also a gold mine of ideas Rarely tapped ….. Well we are not just the builders of the feature.. It’s more than that.. We answer “What does it take to build it in the most logical way given the way things are architected right now””
- Please come talk to us!
- One small detailed can change the entire Project. Details are considered later, if we have these details earlier on, this can impact design, and product decisions Image - microscope Time lost Re-work Loss of moment - dead end We are all stuck…
- Image of contributor upload Contributor uploads a file→ our application validates the file to check if it meets requirements → displays a bunch of nice messages to users → user can fix and retry :) Web is different from Native Apps. Siloed teams didn’t take that into consideration. FTP is a different source, thousands of files can be submitted at the same time. Problem: THe product came to Engineering with the request and a design first. However during the sync, engineers shared some immediate concerns right away. How to display thousands of error messages on a single screen given FTP was a source of input? Design didn’t take that metrics into consideration? Also how can the same errors display on a smaller screen like a cell phone app? And because we knew how content ingestion occurs (how the pipes and plumbing is), display on native app was just one problem, the other one was the underlying architecture to “send” error messages to these platforms were different. We soon realised we need all stakeholders in one room and take all these concerns into consideration to re-design it. How did we solve it? Trough cross collaboration. Got all the impacted teams involved from the onset Engineers were involved from the beginning who could identify these workflows as it impacts implementation. UX team’s prototype could include all these variations. Native app team’s architecture differed from the Web Contributor’s architecture. One team preferred a “push” model while the other team had a “pull” model already built it and ready to go. Due to this difference, my team responsible to send these errors to relevant teams, had to implement a new “helper service” to make this possible for two different requirement to ensuring consistency across platform and UX. We planned a Phased rollout since the architecture had to change to support. YOu see how a simple project expanded in scope? We agreed, the best path forward= phase it out/iterate it. Had this collaboration not happen from the onset, the false assumptions “oh this is simple” would have lingered on. Such early collaborations prevented false assumptions, false timelines, and eliminated duplicative work. PROBLEM: Product and design in isolation developed this beautiful idea and packaged it and brought it to us. And we had information that they didn’t think of. Therefore we had to start over! And this is what we wnat to vaoid. Solution : communication is the key. COnstant communiation
- How to be “unstuck” and take ownership.. The optimal way to do this is to build a bridge between stakeholders from the onset Constructive discussions earlier on so you can think through what would make most sense for the business and can we expand on it in the future More cross-team collaborations exposes non-engineers to think like engineers and take our thought process into considerations during design/product development The reverse is also true. More engineers are exposed to non-engineers, we get exposed to workflows, real-world scenarios that only adds to our thought process..