�ݺ�ߣ

Editor's Notes

1. I’ve been at TUG for about year and I’ve been so impressed how they accomplish so much in a conversation – goal alignment, relationship building- the end of a meeting is just always so positive. Not the pangs of regret and frustration due to conversation derailment I was used to from previous jobs.
2. When I say abstraction, I’m talking about it in terms of the intentional filtering of information in a model to focus on the core goal of a conversation. Restructuring the information to focus the conversation. Abstraction is not about making things simpler, but making them clearer.
3. Richard Saul Wurman’s diagram of the Tokyo subway is a great example of the power of abstraction. He stripped away the geography layer and focused only on what people riding around underground would need to know. How the rails connect matters to the passengers. This diagram makes it clear that if you get on at Osaki, you can switch trains in Shinjuku and reach the Imperial Palace. Obviously this map wouldn’t work for the subway maintenance crew – but it serves its purpose by focusing the viewer on what’s important in this circumstance.
4. What the subway system would look like with geography…
5. Work in progress…
6. We often don’t have the luxury of time. We are asked things like “Make a thing that does this and we’ll discuss it in the meeting Tuesday”And then what happens? The whole meeting is spent on nit-picky things like “Can we change the font?” or “There is a typo in the word ‘example’”Or worst, there this is a re-design of an existing product that people are attached to and the status quo bias sets in – I liked the old formatting better.Then 2 months later it becomes clear through analytics and user feedback that the thing wasn’t the right thing to make in the first place. And you’re left wishing that discussions could have focused on what the product needed to accomplish instead of silly details.
7. When we rush ahead it often causes more work in the end. Thoughtfully producing an abstraction to guide a conversation at the beginning of a project can help avoid a lot of this pain: aligning your team, focusing the project, and resulting in better outcomes.
8. We get different conversations from depending on the medium we present things in. For instance we talk about different facets of a city if we discuss this
9. Picture of Baltimore or if we
10. Discuss this hand-dawn city map that abstracts the city to focus on major buildings and rivers
11. Or we have a very experience giving directions like this
12. Or like this
13. We certainly discuss different elements looking at something like this-Actually the wireframe discussion started with the client from this concrete point, instead of from the sketch. And you know what feedback I got? “The content is too dense” – so I had to go back and add bullet points in the loremipsum. There was never discussion around larger, experience type targets.
14. Or this
15. Now I’d like to dig deeper using 2 examples.First, let’s discuss the value of a customer journey as an abstraction of user tests.
16. Concrete section: raw data collected from user testingIf you give the all raw data, or even a more condensed version of it, to the stakeholder they are likely to succumb to confirmation bias. People come to the design table with assumptions and naturally attempt to fit data into the boxes based on their beliefs previous to testing. Its simple human nature.
17. Providing them with an abstraction to base a conversation around will help to facilitate conversations that will illuminate key issues and guide the project forwardBy getting past preconception and filtering out all but the most relevant information
18. Picking lanes importantLike WurmanJorge “diagrams so rich that it starts suggesting the solution
19. The desired outcome would be everyone on the project being on the same page
20. So if you do a bunch of stakeholder interviews you hear a lot of information, needs, and wants. All these inputs are important.
21. But what if one of those people is the boss? Maybe only their voice matters once that is revealed. But that gets us so far from the goal of understanding the true goals of this project. It can’t be dictated by one person since everyone’s input adds something important.
22. So if instead of showing the notes in general and saying “should we build to accomplish this?” It is helpful to distill those down into a goal list that is abstracted away from that original data. Now no one is more important than another. Now the realm of possible goals is clear. Taking this list back to the stakeholders and asking “is this right?” – often the priority is re-arranged, but always goals that weren’t on the boss’s radar become salient and are given a voice.
23. Now everyone feels heard. Everyone knows where the project is heading.