Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (8)
Semelhante a Cl 03
Semelhante a Cl 03 (20)
Mais de Atlassian
Mais de Atlassian (20)
Último
Último (20)
Cl 03
- 2. Design + Development 2 Relationship Status: It’s complicated.
- 3. Designing for user experience (UX) with Atlassian Tools 3 Tools you already have, repurposed. Hai! Samantha Thebridge UX Designer, Atlassian
- 4. Integrating Design and Dev What is User Experience Design? What are our challenges? 5 simple steps to solve them Profit, or, what have we learned? 4
- 5. 5 User Experience is SRS BSNS
- 6. I need it to do all this What is User Experience? 6 UX is making things simple, easy and pleasurable to use. But I want it to feel like this Or even this?
- 7. UX Disciplines 7 Information Architect HCI & Cognitive Psychology User Research & Validation Interaction Design Visual Design
- 8. Interaction design Interaction components comprising atomic elements A vast mental library of interaction patterns Anticipating user behavior and expectation Empower the user to hit [submit] and help them recover if they did something they didn’t mean to do If it’s complex make it discoverable, learnable 8 Interaction Design
- 9. Visual design Visual perception: alignment, spacing, dynamics Color, fonts, judicious use of iconography Gradients, rounded corners and drop shadows –stuff developers hate Invisible design helps make software intuitive, learnable, simple 9 Visual Design
- 10. What are our challenges? 10 Hmmm… Comic Sans or WingDings today?
- 12. Aiming for visual parity while remaining faithfulto the unique aims of each product
- 13. Rolling visual changes out from one product to the next
- 14. Ensuring that pattern use is communicated != Page Chrome - JIRA Page Chrome - Confluence Tabs - JIRA Tabs - Confluence
- 15. Practical Challenges Working within product teams In different floors of different buildings Working across time-zones Working across continents 12 SYD: Breakfast SFO: Beer o’clock
- 16. 13
- 19. 5 Steps to #Winning 16 Braindump to Brief Brief to Wireframes Wireframes to Design Design to implementation Implementation to validation
- 20. 17 1. From Braindump to Brief
- 21. The JIRA Ignite Story What is Ignite? The problem The challenge 18
- 22. JIRA permissions schemes should support the specific mapping of version and component related permissions so that a project can allow a product owner to update versions without having to be an admin of the project. “We would like to be able to set the priority of outgoing e-mails. This way we can have the priority of e-mails generated by JIRA set to high when the issue has a priority of Critical or Blocker.” 19
- 23. 20
- 24. 21
- 25. 22
- 26. 23
- 27. 24
- 28. Don’t forget to share 25
- 29. 1. From Braindump to Brief JIRA.com issue Blog post Customer Interviews Whiteboard scrawl 26
- 30. 27 2. Brief to Wireframes
- 31. 28
- 32. 29
- 33. 2. From Brief to Wireframes Wireframe straight intoConfluence using Balsamiq Living, breathing documents Everyone can edit them 30
- 34. 31 3. Wireframes to Design
- 35. 32
- 36. Atlassian Style Guide 33
- 37. 34
- 38. 35
- 39. 3. From Wireframes to Design Bring different states of static designs to life using Confluence Check in interactive prototypes Browse to files & link html in Confluence Store version-controlled raw artwork files in central repository 36
- 40. 37 4. Design to Implementation
- 41. 38
- 42. Design during implementation 39
- 44. More latitude to change your mind
- 46. Design Resource Management Using Greenhopper Use cards to manage the design backlog Separate “Design” Project in JIRA Design Sub-tasks within Development project Filters isolate Design from Dev stream Don’t pollute the burndown chart and scare your team lead 42
- 47. 43
- 48. 4. From Design to Implementation JIRA as Design ticketing system Design as part of development triage system Project management – design in Agile 44
- 49. 45 5. Implementation to Validation
- 50. 5. Validate! Internal testing – select random people in the elevator Design blitz testing – prepare for a comment deluge External Testing and documentation 46
- 51. User Validation 47 Tons of unused white space all over. we need to break up the space with colors or blocks or backgrounds - something so that its not a whole lot of white +1 Too much whitespace Internal and external feedback
- 52. 5 Steps to #Winning Braindump to Brief Brief to Wireframes Wireframes to Design Design to implementation Implementation to validation 48
- 53. What have we learned? You can’t plan for everything User feedback can often lead to to changes Shifting priorities, and scope creep Did we miss something? What parts are technically unfeasible? 49
- 56. Resources http://confluence.atlassian.com/display/AUI/ http://ux.stackexchange.com/ http://programmers.stackexchange.com/questions/tagged/design http://www.faceyourmanga.com/ 52
- 58. Resources http://confluence.atlassian.com/display/AUI/ http://ux.stackexchange.com/ http://programmers.stackexchange.com/questions/tagged/design http://www.faceyourmanga.com/ 54
Notas do Editor
- Communication ProblemsDesign + Development. We have a weird relationship. I don’t know why it’s so weird. Software engineers are the new black, and designers are the old black. I think we’re the new biege. But in an ideal world it would be perfectly symbiotic, based on a mutual appreciation for each others discipline. It would be continually leveraging each others domain knowledge and expertise to create beautiful and powerful software. But the break-neck pace we work at means that we are often working in parallel, with less overlap than is optimal. Before we talk about the challenges we have, let’s first talk about User Experience.
- Hi, I’m Samantha, I work for the Atlassian UX team in Sydney.So I’ve been a designer for about 30 years. I’ve been making a living from it for 15 of those years. Before that I was just winning colouring-in competitions. I was gonna go pro but the bottom fell out of the circuit back in Australia, so I turned to Graphic Design. Graphic Design led me to Web Design. I started my web career back in 98 and I worked on sites such as QANTAS.com and Telstra.com – Telstra is I suppose a little like our colonial version of AOL back when it was good. I was lucky enough to work on global e-commerce sites such as the oneworld alliance website, where I got my first glimpse into immersive, embedded media, and then I formed my own multimedia company which I am proud to say survived the dotcom crash and lives on in 2011, minus me, who wanted to move back into interaction design. So since then I worked on rich internet apps like hotel bookings systems, itinerary planners, I spent a few years working on the front end of a major ISP, and in the last few years I’ve worked on an online music shop and a movie downloads site which is a bit like Australia’s Netflix, before landing at Atlassian.While I was working on these movie and music download sites I was using a couple of different bug tracking and job ticketing systems – both open source and subscription-based. Oh and we also then used to log into our client’s tracker of choice. I won’t mention names because they weren’t inherently bad, it’s just that I didn’t understand why we needed so many apps to do it all. So then one day I was brought into first round discussions to make this music site into more of a SOCIAL MEDIA PORTAL, (yay) but they said this time we couldn’t use our own tracking tools – we had to use theirs – and they were using JIRA. So I took a look at JIRA and it was love at first sight and here I am. We have a pre-nup, it’s OK. If JIRA and I split, I’m taking the dog.
- So If you’ve been using our products for more than a couple of years, you’ll have seen some big changes taking place in the way our interfaces look over the last 18 months to two years. CLICKToday I’m going to talk to you a little bit about the way we use our own tools within Atlassian Design in the pursuit of excellent user experience and beautiful user interface design. CLICK I want to talk first about the misconceptions between what constitutes UX and UI design and where they overlap; CLICKI want to talk to you about the practical challenges we face; and I especially want to discuss the methodological we all face when executing design in a software development environment, CLICKand I want to talk about a combination of our tools we use in concert to support our feedback loop – things that you could also do but may not have considered yet, CLICKAnd lastly I’ll tell you which bits we’re still refining.
- User Experience or UX is a fairly new term that’s been thrown around for a couple of years, and it’s a little confusing because it seems to have just popped up as though it’s a whole new field. There is still a lot of confusion about what this term “UX” means, and so there are a few misconceptions about what it means in practical terms. CLICKThe easiest way to understand it is to know that User Experience is a collection of disciplines concerned with making a product or service simple, easy and pleasurable to use. For a piece of software this usually means making the interface clean and the interactivity both intuitive and learnable. CLICKAt the moment there is a tendency to use the term UX designer as an umbrella job description – this helps no one and cheapens the granular processes within UX – it’s as if we’ve tossed into the air the job titles of everyone in software and web development who is NOT a programmer or a manager and we’ve simply called everyone else a UX designer. The truth is that visual interface design, interaction design, user research and validation, information architecture – these are all component disciplines within the field of User Experience. There is plenty of overlap in the skillsets of most (but not all) UX practitioners, but they are still specialised fields. CLICKCognitive psychology is the study of internal mental processes and about how people perceive, remember, think, speak, and solve problems. CLICKAnother misconception about UX is that it is a step in a process which can be ticked off and completed. This is not true – the improvement of the user experience in your software product is ongoing. It should never, ever end. Another big misconception about UX is that it is solely the responsibility of a User Experience designer or practitioner. This is not the case. A pleasurable user experience is YOUR concern as well, even if you do not define yourself in that role. Each of these component disciplines are key players in the usability of the software for the end user, but the distinctions between the disciplines are important to note, because they are executed at different times during the software development cycle. For the purposes of this talk, I’m going to refer to the component disciplines by their specific names.
- Today I’m mostly going to focus more interaction design and visual interface design – these are the nuts and bolts of what the design team at Atlassian deals with on a day to day basis. We also perform User research and validation, information architecture, but I’m going to focus on the first two as later on I’m going to show you some cool ways these disciplines can rely Atlassian tools for feedback and implementation. CLICKInteraction Design is concerned with enabling user behaviour within a specific context: for example: a screen – or a set of subtasks within a screen. Interaction design isn’t just about form controls or giant submit buttons, It’s about providing the easiest and most logical way for a user to complete a task. Think about the form control element, the radio button or the checkbox as an atomic element of a component, such a log-in module. Then think about that component being part of a greater choreography – a framework such as a shopping cart. Getting your user to decide to buy is marketing’s concern. Getting the user to complete their purchase as painlessly as possible is the realm of the interaction designer. CLICKTo do this we employ a whole box of tricks based on what we know about human computer interaction – we practice visual linguistics, we use consistency and common placement of elements, we create a visual vocabulary – sometimes limited, to make sure no one ever has to do too much thinking. CLICKWe use common interaction patterns and frameworks people are already familiar with in order to enable and empower the user to navigate through an application and get their job done. It’s about maintaining a vast mental library of these interaction patterns. It’s not about reinventing the wheel. CLICKIt’s about anticipating how the user expects things to work. It’s about getting them to not be scared to hit submit and it’s about making sure there’s a safety net and error recovery if they do something they didn’t mean to do. CLICKThe less new stuff the user is faced with the better: they expect things to behave in a certain way and the interaction design should almost be invisible. But sometimes the task is pretty complex, and despite our best efforts we can only simplify it so much – so then we have to make the interface discoverable and learnable.
- Of course, how those patterns look is completely up to the visual interface designer. The visual design is about colour, spacing, alignment, proximity and visual hierarchy. How a drop-down menu in a form is styled is a completely separate issue from the decision to use a drop-down menu in the first place. Again, good visual design should almost be invisible. People expect things to look slick and machine-tooled and of course they don’t notice when they ARE slick and machine-tooled. They DO notice when something is jarring. Make both elements of the experience practically invisible and your user can focus more on completing their task. CLICK
- We’ve got a few challenges at Atlassian. We’ve got the obvious day to day design challenges – this is our day job – our trade. These are the granular decisions we make about icons, font sizes, prototyping, user research and so on. CLICKThen we have the practical challenges which relate to the physical way we do our job. CLICKWe have methodological challenges which pertain to the shifting project management styles that both design and development are affected by. CLICKFinally we have communication challenges which are as much about the different mindsets of the groups that play within Atlassian as it is about note-taking, descriptive emails and record keeping. CLICK
- The very nature of the users we are designing for is our first major challenge, but that's the exciting one. Our users are so much more tech savvy than the average user of a consumer application – our users appreciate complexity and aren’t afraid to read documentation. Because our users are supersmart, sometimes it’s a little easy let unnecessary complexity slip in because we know our users are fairly capable of dealing with it. CLICKOur next biggest design challenge is that we are pulling 5 products into line visually, products that have their own visual heritage and their own technical considerations that need to be documented so that new members of the design team can get up to speed really quickly. CLICKThe next major difficulty for us is that we’re shooting for consistency and visual parity across products. It’s not that simple when you have something like JIRA over here which is so fully featured and complex and has a whole range of interaction systems that simply aren’t needed at the other end of the spectrum with something like Confluence. We can’t shoehorn the features of one product into the others, but they still need to look like they are part of a happy and harmonious family. CLICKAnother challenge for us is getting the development bandwidth to roll features across into other projects. If we change a style in JIRA for a really good reason, we need to then have buy-in from the Product Manager of another product so we can have those changes scheduled into development. CLICKThe last key challenge that concerns design is ensuring that pattern use is communicated so that we avoid reinventing the wheel. We sometimes see that what is being done in Bamboo could apply to something in development for FishEye, and we need to make sure that we use the same pattern for both rather than coming up with two slightly different ones. CLICK
- Yet we have other more practical challenges that we've run into over the years, and we've developed a set of internal processes using our own tools to help overcome those challenges. CLICK The first challenge is geography. Our design team is split across three floors and two buildings - with a very busy city street separating us. We have chosen to work individually within our product teams. Instead of design working in a central location we get together several times a week to discuss designs we’re working on and cross-product consistency. CLICKAdditionally, we work across continents. Not only do we work separately from the rest of the design team, but we also sometimes work separately from our product team members. As an example, the Studio and Integration teams are based both here and in Sydney. My Product Manager is here in San Francisco, while most of our development happens in Sydney. CLICKThe other obvious one is that we operate in different time-zones and different days of the week. This again is not unique, but we still have know when to filter communication to just Sydney, just San Francisco, just Amsterdam – or when something needs everyone’s eyes on it. CLICK
- Every day I cross Sussex Street Sydney – which is a one-way street leading into Chinatown and part of an on-ramp to a major western distributor road – to attend meetings. But also because they have better coffee under their building. Our Studio PM crossed continents to get good coffee. No lie.
- The Methodological challenge is my favourite – and it’s the one currently being faced by design and developers all over the world. CLICKWhere does Design fit into Development these days? This has changed a LOT. Back in the glory days of Web 1.0, the discovery, scoping and conceptual phases of a software or web project could take months or up to a year. Developers could start working on the software engineering fairly early on, but not until they had a signed-off functional specification document in their hands. After site schematic diagrams, card sorting exercises, and wireframing, visual designs were done and approved and then finally the front end coding could start and the front and back ends could start to be sewn together. CLICKThanks to Agile methodology, with the idea being that coding starts as soon as possible and you iterate early and often, the relationship between Design and Development has been flipped on its head. Developers can start working on features and throw together a functional – if somewhat clumsy – interface to just get started. CLICK The biggest hurdle we face in is that we used to have so much more scope for “thinking time” at the beginning of the project. We could explore scenarios, use cases, multiple visual solutions and several design iterations. The idea of “design concepts” is not analogous to Agile, as the idea of hours of conceptualizing for days for days just cannot work during tight iteration periods. CLICKDesign has two choices: it can hang onto the legacy of the Waterfall method, and the luxury of endless planning and design phases - and be left behind, or design can to step it up somehow in order to have involvement in each iteration.
- So we’ve spent some time working despite these challenges, and I thought the best way to walk you through how we’ve overcome some of them is to look at them through the lens of our most recent major overhaul in JIRA. JIRA Ignite is undertaking a massive simplification of our JIRA Admin UI.I’ll quickly talk you through Ignite: The problem: We knew that the majority of you weren’t spending their days in and around the JIRA admin UI. You told us that most of you were configuring parts of JIRA once and then not coming back into the admin for weeks or even months and having to relearn the steps to change the same settings. This was a particularly noticeable problem in the way Schemes were set up. Not everyone was reconfiguring schemes all the time, but they were still a first class UI element in the project management interface. If you wanted to add an issue type, you had to remember to go into Schemes and then add from there. It wasn’t confusing if you spent a lot of time tinkering with the JIRA admin, but it was scaring off a large enough segment of our users that we knew we had to do something to simplify it.The challenge: Ignite is a perfect case study to describe what I referred to earlier when I was talking about the tendency to allow UI complexity to slip through because of the expertise of you guys. It’s also a perfect case study to describe revising the user experience through evolutionary design and constant iteration. We had an Admin UI that was doing the job, but we knew we could fix it incrementally and make it awesome.JIRA is a highly configurable and flexible tool, but the more we talk to people and watch how it’s used, the more we realise which parts we can smooth off and which parts we can bury just for the proper sysadmins. OMG those guys.
- Most of our work starts out as a braindump in Confluence, or are born out of a comment from a customer, or a JIRA.com issue. That leads to customer interviews, then we start scribbling ideas and then we move to Gliffy.
- This is when people start to see real work happening, and see their vision start to come to life - when we begin to wireframe – it may be nowhere near final but the idea begins to take shape. We use the Balsamiq plug-in for this. As a designer and a human, I am allergic to Comic Sans, so I have to work on my gag reflex when I'm working on these. The great thing about Balsamiq is that every single person in the company can put together a mock-up of an idea that they've had. It's not restricted to just the design team. Here's a quick overview of how we came up with the JIRA Ignite Interface layout.[Recorded Demo of creating a wireframe and deploying to Confluence] The greatest part of this process is that the Balsamiq file is a living document. Anyone can edit it. My product manager in San Francisco can log in when it's still 3am in Sydney and change ALL my work. FOR THE BETTER, of course. It saves us a great deal of time.
- This is when people start to see real work happening, and see their vision start to come to life - when we begin to wireframe – it may be nowhere near final but the idea begins to take shape. We use the Balsamiq plug-in for this. As a designer and a human, I am allergic to Comic Sans, so I have to work on my gag reflex when I'm working on these. The great thing about Balsamiq is that every single person in the company can put together a mock-up of an idea that they've had. It's not restricted to just the design team. Here's a quick overview of how we came up with the JIRA Ignite Interface layout.[Recorded Demo of creating a wireframe and deploying to Confluence] The greatest part of this process is that the Balsamiq file is a living document. Anyone can edit it. My product manager in San Francisco can log in when it's still 3am in Sydney and change ALL my work. FOR THE BETTER, of course. It saves us a great deal of time.
- One of the beautiful things about Confluence is the array of plugins and macros. This is the Composition macro and it allows us to bring static page layouts to life to demonstrate interactivity. When we click between these tabs we can simulate the responses to clicks, or open menus. This way we don’t have to put 18 images in a row and end up with a 20km scrolling page. These pages are where people provide a lot of feedback as comments so it makes it easy if we don’t have to read a comment associated with the 12th layout and scroll back up for days to see what the commenter is describing.
- Here is an example of how we browse to a working prototype using FishEye in JIRA Studio.
- This is an example of how we store our raw files, like Photoshop or Illustrator. This enables our developers to find assets really quickly.
- Another thing we do at Atlassian is check in interactive prototypes in the same way our devs check in their code. We use subversion so we retain version control. CLICKOnce our files are checked in we can browse to the raw file using FishEye and link to that file in our Confluence page. CLICK And even better – we can store version-controlled raw and editable artwork files in a central repository. The design team can each have the repository checked out onto their local machine so that we can access large files when we are on the move.
- So here is the creation of a
- Let me start with project management. While there are huge advantages to be gained by developing in an Agile environment – ASSUMING that you’re doing it properly – there seems to be obvious disadvantages to design in Agile, such as losing the luxury of endless planning periods before making any investment in code, but you know what? There are a few arguments in favour of moulding your design process to the Agile method. CLICK The most obvious one is that you have more time to refine your vision. You don’t have to lock down every single decision into a functional or design requirement and run into prohibitive expense if you need to change things later. You work in bite sized pieces and you can observe those pieces in play while you are planning the next attack. You can see if something is not working before it’s too late to refine. Iterative design means you can afford to deviate from decisions if you can see room for improvement after implementation. Plus, you have less emotional attachment to certain decisions and you can react to change quickly. Designers must use their own experience to recognise and identify potential complexity and adjust their own schedule in advance. This avoids any surprises during the design and implementation phase. It’s not strictly Agile but you need to weigh up the benefit for the final product and set realistic deadlines.As far as synchronising your design sprints with your dev team, “Best practice” supports doing research and wireframing during iteration n+2, designing concepts during iteration n+1, supporting development during iteration n and doing UI design review iteration n-1. This is a solid and fairly accepted practice as long as everyone recognises that you can’t afford to be inflexible and take this too literally. Your planning should reflect the scope of work rather than the deadline imposed by a sprint.
- The other critical part of using JIRA as a design ticketing system is the inherent capabilities Greenhopper provides for resource management, planning and tracking design time. There is a minor danger that the design components of a project can muddy the burndown chart by adding bloat to the scope of work. For example, a design task might take more than one iteration and therefore will remain “in progress” for a lot longer than the scrum master feels comfortable with. This can be mitigated by using filters to separate the design tasks from the dev tasks.
- Once design has been approved and is being rolled into the product, that's when we start to use JIRA. CLICKWe use it like a design agency ticketing system, so artwork requests are made inside a project and assigned to a designer. CLICK Design becomes part of the development triage system. The designer can locate and report UI bugs and then collaborate with a developer to iron these out. The developer can submit requests back to the designer for information or assets which can then be rolled back into the development issue.
- We test the success of our interaction design by doing User Validation. This usually starts with internal testing – grabbing a few random coworkers and putting them in front of a UI we’re working on and asking them to interact with it. We can then respond to their feedback and iterate again. Then we put our design in front of external customers and observe them using the software.We interview customers to discover any issues they have with the current UI, to work out how we can improve them taskflow for them and come up with better interaction frameworks.The results of all these sessions end up on Confluence so that members of the other design teams can steal insights from everyone else.
- While it’s great to have requirements, time to ideate, refine, plan and eventually get stakeholder approval, there is no point being inflexible once things are agreed upon. You need to understand that the process is fluid and you have to bend in the wind – both as a designer AND a developer and treat the whole process as something malleable. CLICKThe first thing to understand is that even though you can plan, design and document, there is a point where you reach the law of diminishing returns and it is now more viable to simply stop planning and start building. CLICKOnce you start building you need to be prepared to revisit those requirements and edit, discard and amend while you’re on the move. CLICKAs you progress through the implementation phase it’s often discovered that something hasn’t been fully considered and is missing from the spec. This is often where design in Agile falls down as you need to move some objectives out of the current iteration and into the next in order to accommodate the missing piece. CLICKIf you’re a designer, don’t be dogmatic about certain elements you’ve grown attached to that are technically unfeasible. You can always park these ideas until later when they do become viable.Sometimes user feedback can change everything. You might be absolutely certain that you’ve made a series of correct assumptions that turn out to be wrong. I’m talking generally, here. Obviously this never happens at Atlassian. CLICKYou might find that something you thought was technically unfeasible is now suddenly impossible – we’re seeing a lot of this now that CSS3 and HTML5 are here. Ideas we had a couple of years ago are being rebooted. CLICK.From the top down, priorities can shift. A competitor might launch something that forces you to change tack to compete or stay in the game. If you can’t pivot rapidly you can end up playing catch-up for the next couple of years. The best example I have been privy to was an online music store which was in development for a year, to only offer DRM Windows Media Audio files. This was right at the same time Apple chose MP3. LOL CLICKThe most difficult one to deal with, for both design and development is meandering requirements. Sometimes features are pulled out of, or reintroduced into scope or deadlines change. We can’t always be in the room when these decisions are made, and this can mean some reshuffling.
- You can, of course have communication snags during implementation. You can have them in planning, but they have a lot more impact close to a release. Developers and designers have fundamental differences in the way their brains work, as well as what they are passionate about. Devs get excited about code. The devote a lot of their attention to the fine detail of getting something working or trying out a new technology or framework. Designers care about the presentation layer and how it will be used - they want to see their vision executed with pixel-perfect precision. Developers don’t always see the difference between a 5-pixel margin and an 8-pixel margin and think the designer is being pedantic when they log an issue to fix it. Management doesn’t care about either of these things and just wants the product to ship on time. And the user expects flawless, machine-tooled, bug-free, frictionless software.Each stakeholder has a different set of trade-offs. If you can learn a bit more about the other’s domain, you can figure out when you might be able to get a concession that works in favour of your vision.
- If we are great at documenting, posting on Confluence, keeping open and transparent written communication, we can mostly avoid communication problems. Our iteration periods are fairly tight, so we don’t have time for any communication issues – especially ones that linger. The most obvious thing to remember is this: UI bugs are not personal, and that you are there to enhance each others work, not make each other miserable. My personal tips are that you should be direct and personal – don’t write passive aggressive blog posts or tweets directed at the person or the issue in question.Be honest with your communication. You’ll get more respect by admitting when you’re at fault instead of trying to deflect blame.But above all: flattery will get you EVERYWHERE. You both have different skillsets – allow yourself to be amazed at what the other is capable of, and don’t be afraid to tell them when you are genuinely impressed.