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.

1. Facilitating
holistic product decisions
with information architecture
Johanna Kollmann | @johannakoll | IA Summit 2017, Vancouver

3. CHALLENGES

4. “Multi-context”product
Website
Command-line tool
Integrations & notifications

5. Photo by NASA HQ PHOTO, https://flic.kr/p/cxko4u

6. Mental Model
System Model
Conceptual Model

7. We ended up designing “from the code layer out”
- rather than having product intent drive the system.

8. HOLISTIC PRODUCT THINKING

9. CODE HAS IA

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

17. THINKING IN USER JOURNEYS
IS HARD

18. Objectives + metrics
Epics
User stories
Tasks
Customer Needs Business goals
Feature
Discovery phase Feature plan

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

20. Example credit: https://github.com/guidance-guarantee-programme/pension_guidance/blob/master/features/customer_booking_request.feature
Feature testing
• Written before you start coding
• Expressed in human language
• Facilitates understanding the feature
across the user journey
• Great for clarifying questions, easy to
collaborate on

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

23. TAKE-AWAYS

24. Semantics matter!
The code has IA and drives your engineering
colleagues’conceptual model.

25. Identify process points and tools that
can connect the product and system architecture.

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

27. say hi: @johannakoll
THANKS
MERCI
DANKE