Once upon a time, we designed websites that were sitting on a limited stack of technology that you could get your head around easily. In 2017+, we are designing products consisting of increasingly complex, scalable systems.
Architecting those systems are often engineers, using a variety of technologies. As information architects, we face the challenge to take part in this process, to shape these systems, to make sure that technology decisions are driven by product design and user needs.
In this short talk, given at the 2017 Information Architecture Summit in Vancouver, I shared how you can bridge the gap between UX and system architecture, and what I’ve learned about collaborating effectively with engineers. I’m basing this on my experience as Head of Product at a startup, so it's a case study with take-aways that will be useful for anyone working in a cross-functional team.
10. 1) Concepts and language in the code beat the best diagrams.
Lessons learned
11. From an IA’s point-of-view:
• How will user journeys change?
• What’s the new hierarchy?
• Does our taxonomy still work?
• What do we call features and product concepts?
• Which words will make sense to users,
what have we learned from research?
Scenario: scaling the product
12. From an engineer’s point-of-view:
• How does the data model need to change to support this?
• How do existing code structures need to change?
• What do we call things in the code?
• What new services and capabilities will be required?
Scenario: scaling the product
13. 1) Concepts and language in the code beat the best diagrams.
2)Collaborate with system architects and engineers to ensure that
concepts in the code match the product intent.
Lessons learned
14. • Re-architect the code to match the conceptual model
• Can you use the terms that are user-facing in the code?
• It is what’s in the code that will be used and remembered
Build from the product layer in
- not from the code layer out
15. 1) Concepts and language in the code beat the best diagrams.
2) Collaborate with system architects and engineers to ensure that concepts in the
code match the product intent.
3) Engage with, and inform, the IA of your system architecture.
Lessons learned
16. 1) Concepts and language in the code beat the best diagrams.
2) Collaborate with system architects and engineers to ensure that concepts in the
code match the product intent.
3) Engage with, and inform, the IA of your system architecture.
Lessons learned
19. 1) Concepts and language in the code beat the best diagrams.
2) Collaborate with system architects and engineers to ensure that concepts in the
code match the product intent.
3) Engage with, and inform, the IA of your system architecture.
4)Feature testing can create a shared understanding of high-priority
features.
Lessons learned
21. 1) Concepts and language in the code beat the best diagrams.
2) Collaborate with system architects and engineers to ensure that concepts in the
code match the product intent.
3) Engage with, and inform, the IA of your system architecture.
4) Feature testing can create a shared understanding of high-priority features.
5)Feature inventories that include engineering capabilities can provide a
holistic overview across product and system architecture.
Lessons learned
22. Feature inventory
• High-value core features
• Map against channels, integrations,
whatever your context requires
• Map system architecture (services,
capabilities)against features
• Will inform API development
26. 1) Concepts and language in the code beat the best diagrams.
2) Collaborate with system architects and engineers to ensure that concepts in the
code match the product intent.
3) Engage with, and inform, the IA of your system architecture.
4) Feature testing can create a shared understanding of high-priority features.
5) Feature inventories that include engineering capabilities can provide a holistic
overview across product and system architecture.
Lessons learned