Potholes on the Journey to Design Transparency

Editor's Notes

• #2: Hi, I’m Jake Causby. I’m an interaction designer, most recently for Atlassian where I was for almost 2 and a half years. \n\nBefore that I was a design consultant, running my own show, where I was pretty much in the business of coming up with solutions to problems all by myself.\n\nToday I wanted to talk about design transparency, how important it is, and how I managed to totally change the way I work. It’s a journey, of sorts, which of course, has potholes...\n
• #3: When I first started at Atlassian I was a novice. Fresh to the mystical ways of Agile software development. I was placed as the only designer on a team that had not previously even had a designer. I was expected to take a loose brief, go away for a while to work some magic in isolation, then return to pitch a solution for a way forward. In addition to this, I had the developers constantly asking me when they were going to receive the final designs.\n\nI’d like to share some the learning experiences that enabled me to gain insight, adapt and become better at what I do. But first, let’s consider a scenario...\n
• #4: You know that moment… You’re show someone (a stakeholder) the designs you’ve been working on for the last day, or the last week. You’ve put a lot of thought into the “real” problem. You’ve explored options and been through the whole decision-making process. \nYou’re sharing your thoughts and opinions on your best solution to this problem. \n\nThey’re looking at the designs and you’re reading their facial expression. It’s not good. They’re not really buying it. You can tell they’re thinking “This isn’t what I had in mind” \n\nIt shouldn’t ever come to this. And this is where design transparency comes in. \n
• #5: What is design transparency? Put simply, it’s insight into the design process.\n\nI believe most designers spend too much time justifying their work and educating stakeholders at the time of some sort of pitch instead of actually *during* the process. I think designers need to involve stakeholders in the decision-making process.\n\nDon’t get me wrong; design transparency is NOT about design by committee. It’s about communicating your intent and getting insightful feedback on the direction of the designs.\n\nSo why is that good?...\n\n
• #6: Making your designs and design process transparent is the best way you can communicate effectively with stakeholders\n\nIn talking about design transparency, I find myself constantly coming back to one of three topics. And each of these three topics, in conjunction with each other, combine to facilitate Design Transparency. They are...\n
• #7: Before I go into each one of these, I have a story, that hopefully corresponds to each\n\nThe first is the story of the rogue label designer...\n
• #8: Atlassian has a strong developer culture. Their CEOs are developers, a lot of their product managers used to be developers, and there are about 20 developers for each designer*\n\nSince Atlassian builds software for software developers, it probably makes at least *some* sense. But when you’re a single designer on a product with that many developers, it’s easy for stuff to get in you haven’t even seen. Atlassian developers are encouraged to “be the change they seek”. Plus they get “20% time” to work on something they feel is important. If something bothers them, they change it. This is great, kinda, but it also makes life difficult for designers.\n\nLike the time a dev redesigned the styles for a particular widget in one of the products while the designers were actually collaborating on a cross-product style for them. Or the time another dev put a second search box on a screen because the first one searched the entire app, and he wanted one that only searched that page. The list of examples like this is long.\n\nSo when you work in an organisation like this, how do you tackle it? By shifting the culture...\n
• #9: I believe there’s 5 key culture traits we, as designers, can facilitate and encourage.\n\nThe first one is..\n
• #10: You work on a team. It should act like a team. The team that works together, wins together. \n\nIf the people on your team can’t be Honest and Supportive then it’s going to be very difficult to produce the sort of culture that can support effective design. We all need to play our part in giving good feedback and encouragement.\n\nEveryone on the team however, will still have their own specialty, and they need to have some sort of authority over that specialty, which leads me to point 2...\n\n\n
• #11: Quote from a colleague of mine Henry Tapia\n\nIt’s great to get everyone’s feedback, but a lot of the time not everyone will agree. When all is said and done, someone needs to make the design decisions: it needs to be the designer. Designers need to feel like they have ownership of the design of their product. They need to feel responsible if an incorrect design decision is made. They need to feel like it’s their own head on the line, no-one else's. Without ownership there is no risk or responsibility, and without these, there is no passion for quality.\n\n
• #12: Kim Goodwin came to UX Australia last year and gave a great talk on Experience Leadership. She talks about HOW to cultural changes through the use of effective leadership skills. The key take-aways from her talk for me were that...\n\nYou can be an effective leader without being a manager. Great leaders inspire and make people want to volunteer. To do this you need to understand change and resistance to change and you need to put a case together to illustrate why your team can’t keep going the way they are. You need to set a clear vision of where you are heading and why it’ll be less painful. You need to be persistent and make sure the new culture sticks.\n\nI can’t do her entire keynote justice in one slide. If you haven’t seen or heard it, look it up on the uxaustralia website. It’s well worth it. \n
• #13: You’ve seen this diagram before, but it needs more than just acknowledgement. If you work on a product that is ongoing, you and your team must understand the fact that there is never going to be a “final” design. Live with it.\n\nProblem is devs: Many resist coding until “designs are final” and get pissed off if they’re asked to change something after they’ve coded it, but you’ll find that if you validate designs with real users and share the insights, most developers will be more than keen to change the code in order to improve the experience\n\nOnce the whole team buys into the process of iterative design, and things are going to change, you’ll find collaboration gets a whole lot easier.\n\nThat said, you still need to release at some point, which leads me to...\n
• #14: As a designer it’s easy to keep perfecting, over and over until it’s just right. It’s crucial for you to understand when you’re going to say “that’s good enough – we can release this to the customer”... and how are you (as a team of course) going to decide when that point is if you haven’t agreed on this up front?\n\nIt comes back to the fact that everything you design and build will bring some sort of value to your customers. You may as well provide that value sooner, get their feedback, and then make it even better, rather than trying to guess what “better” actually is for the customer before releasing it.\n
• #15: To try and illustrate my point I’ve drawn a graph... The left shaded region in indicative of how much time you need to spend to get something working. You then have a section in the middle, where you could possibly release, but you’re ironing out the experience. Then on the right we have another shaded region that shows how you can reach a point where your effort isn’t translating into significant value, and it will never be perfect anyway.\n\nI’m not going to tell you what the best point is for you because it totally depends on your product, and the current market in which it sits. General rule is if you have no competition, your customers will probably put up with a bit of clunkiness and you can probably release around HERE but if you have a lot of competition then maybe HERE is better. Understand your market and define it up front!\n
• #16: To try and illustrate my point I’ve drawn a graph... The left shaded region in indicative of how much time you need to spend to get something working. You then have a section in the middle, where you could possibly release, but you’re ironing out the experience. Then on the right we have another shaded region that shows how you can reach a point where your effort isn’t translating into significant value, and it will never be perfect anyway.\n\nI’m not going to tell you what the best point is for you because it totally depends on your product, and the current market in which it sits. General rule is if you have no competition, your customers will probably put up with a bit of clunkiness and you can probably release around HERE but if you have a lot of competition then maybe HERE is better. Understand your market and define it up front!\n
• #17: \n
• #18: I was working on a new product with a new PM. It was his baby – he wanted the first release to be perfect. Another designer and myself were slogging out screen after screen, putting most of our effort into the 3 or 4 key screens we decided were extremely important.\n\nThe release date was getting closer and closer, and in the end a lot of screens ended up being neglected because we spend way too much time trying to perfect these “key screens”.\n\nWhat I realised later was that: We were sharing our designs, but we were doing it wrong.\n\n\n
• #19: Sharing is obviously important. We have to share our designs with stakeholders at some stage. Better that we do it sooner rather than later to ensure we’re on the right track. \n\nI want to share 5 considerations for effective sharing. The first being...\n
• #20: Email, wiki/intranet, chat, dedicated app, in person, design wall, build a prototype\n\n(Dedicated apps include: NoteableApp, InVision, HalftoneApp, Prevue, CS Review)\n\nUnless you have designers working remotely from your stakeholders, design walls win every time; up until the point where you start to code, where prototypes come in.\n\nDesign walls have good exposure: It’s easy to give plenty of context, stakeholders can see progress, and it’s the most transparent way of sharing not just the latest design, but also the journey you’ve taken to get there!\n
• #21: Email, wiki/intranet, chat, dedicated app, in person, design wall, build a prototype\n\n(Dedicated apps include: NoteableApp, InVision, HalftoneApp, Prevue, CS Review)\n\nUnless you have designers working remotely from your stakeholders, design walls win every time; up until the point where you start to code, where prototypes come in.\n\nDesign walls have good exposure: It’s easy to give plenty of context, stakeholders can see progress, and it’s the most transparent way of sharing not just the latest design, but also the journey you’ve taken to get there!\n
• #22: Email, wiki/intranet, chat, dedicated app, in person, design wall, build a prototype\n\n(Dedicated apps include: NoteableApp, InVision, HalftoneApp, Prevue, CS Review)\n\nUnless you have designers working remotely from your stakeholders, design walls win every time; up until the point where you start to code, where prototypes come in.\n\nDesign walls have good exposure: It’s easy to give plenty of context, stakeholders can see progress, and it’s the most transparent way of sharing not just the latest design, but also the journey you’ve taken to get there!\n
• #23: Email, wiki/intranet, chat, dedicated app, in person, design wall, build a prototype\n\n(Dedicated apps include: NoteableApp, InVision, HalftoneApp, Prevue, CS Review)\n\nUnless you have designers working remotely from your stakeholders, design walls win every time; up until the point where you start to code, where prototypes come in.\n\nDesign walls have good exposure: It’s easy to give plenty of context, stakeholders can see progress, and it’s the most transparent way of sharing not just the latest design, but also the journey you’ve taken to get there!\n
• #24: Email, wiki/intranet, chat, dedicated app, in person, design wall, build a prototype\n\n(Dedicated apps include: NoteableApp, InVision, HalftoneApp, Prevue, CS Review)\n\nUnless you have designers working remotely from your stakeholders, design walls win every time; up until the point where you start to code, where prototypes come in.\n\nDesign walls have good exposure: It’s easy to give plenty of context, stakeholders can see progress, and it’s the most transparent way of sharing not just the latest design, but also the journey you’ve taken to get there!\n
• #25: Email, wiki/intranet, chat, dedicated app, in person, design wall, build a prototype\n\n(Dedicated apps include: NoteableApp, InVision, HalftoneApp, Prevue, CS Review)\n\nUnless you have designers working remotely from your stakeholders, design walls win every time; up until the point where you start to code, where prototypes come in.\n\nDesign walls have good exposure: It’s easy to give plenty of context, stakeholders can see progress, and it’s the most transparent way of sharing not just the latest design, but also the journey you’ve taken to get there!\n
• #26: Email, wiki/intranet, chat, dedicated app, in person, design wall, build a prototype\n\n(Dedicated apps include: NoteableApp, InVision, HalftoneApp, Prevue, CS Review)\n\nUnless you have designers working remotely from your stakeholders, design walls win every time; up until the point where you start to code, where prototypes come in.\n\nDesign walls have good exposure: It’s easy to give plenty of context, stakeholders can see progress, and it’s the most transparent way of sharing not just the latest design, but also the journey you’ve taken to get there!\n
• #27: Trying to balance needs:\n— Indication of of progress (in progress, in review, or moved to code)\n— User journey/context (best at communicating what’s important from an experience point of view)\n\nHave sessions and take photos and upload to a wiki\n
• #28: Make sure they’re not commenting on the header (for example) when you need feedback on a particular feature only.\n\nFidelity: Not everyone agrees on this, but I believe rough ideas should be displayed with rough sketches, and as the design becomes more thought-through and solid, it should be indicated through higher fidelity.\n\nEducate/explain: Rather than say things like “trust me”. Once they understand just how many objectives you’re try to meet they will have a new respect. \n\nEntertain ideas: We don’t have all the answers. Sketch and clarify what you think they mean. This is an exercise in obtaining a shared understanding – make sure you both understand exactly what each other means. The best that could happen is that the discussion will improve your design. The worst that can happen is that you create a situation where they will be uncomfortable giving feedback in the future.\n
• #29: During the early stages of the design process it’s important not to involve too many people, lest it become design by committee and the signal to noise ratio is too high. Keep it to a small multi-disciplinary team that has authority to make the calls at the level you’re working at.\n\nWhen you *do* get to the stage of sharing designs with a wider audience, it’s important to give ample context. There will always be some people that question every decisions you’ve made so you’ll need to make sure you can back up your designs with sketches, discussions etc when it comes time to share with people that haven’t been involved from the start. \n\nRemember: It’s impossible to please everyone!\n
• #30: We as designers need to make sure our clients and colleagues are critiquing our work in a way that’s constructive and provides a way forward.\n\nRespect the hard work, never castigate. Subjective personal opinions are worth nothing unless they can be backed up with reasoning as to how it affects the experience for the user. Don’t look at a single design in isolation. Consider the larger context of where and how the product will be used. Smile and enjoy the team work. It’s all about the journey.\n
• #31: \n
• #32: Not long after I started at Atlassian I designed the search experience FishEye. I worked with the PM to produce a number of different mockups that we iterated on, discussing the pros and cons until we felt it was ready, then I handed it to the dev that was assigned to build it. So this dev took the designs and implemented about 80% of what was in them. When I asked him where the rest of it was he said he didn’t like those bits. \n\nIt’s obvious that the process we were using was flawed. The dev had no trust, no buy-in and did not share our understanding. \n
• #33: It’s not enough to share your work. Collaborating on your work gives you constant feedback from a multi-disciplinary team. And they can’t give good, solid feedback if they’re not in the loop. So how do we keep them in the loop? We collaborate.\n\nHere I’ve compiled 6 suggestions for ways to collaborate. I use all 6 and swear by them.\n
• #34: Sketches, Charts, Diagrams, Personas, Screen grabs of competitor UI etc\n\nThings that assist your mockups, user journeys and wireframes. Anything that gives other people insight into what you’re thinking, and how you see the situation/problem/solution etc\n\nGet feedback from your team. Ask them how they interpret them and whether they make sense. It’s even more powerful if you can involve other members of the team to create these visual artefacts\n
• #35: Like workshops, but usually less formal. And there’s lots of different things you can do, ranging from 1 hour, to a half or full-day. \n\nMy favs: — Design studio — Paper prototyping — The KJ-Technique\n\nThese sorts of exercises can be tricky to facilitate at first. The first time I conducted a paper prototyping session I didn’t time box things properly, as a result the session became unstructured and we didn’t end up getting enough answers out of the session. You might think this would damage your chances of holding another one, but all people involved still felt it was a worthwhile exercise. And it was! It get devs away from their computers and get’s them thinking about the quality of the product rather than the quality of the code. And as you do more of them, you learn how to get more out of them. You just need to start doing them.\n
• #36: On your own, complex interactive features can be difficult to design fully, without seeing how things are going to feel when in code. Encourage devs to build prototypes and make sure you’re available to answer any questions as they arise.\n\n\n
• #37: One such example is the FishEye commit graph. This is what it ended up looking like. Each of those dots is a commit in a repository. Each one has a whole bunch of metadata associated with it. We were unsure how to display all this information, so I started sketching and a developer started prototyping. Sitting next to each other we were able to quickly work through all sorts of problems; both user-related, and technical limitations. \n
• #38: I also started an “interaction matrix” which you may (or may not) be able to see here.\n\nDown the left we have all the different elements on the screen and across the top we have ways each of these elements might change depending on the state: on load, hover, click, focus, drag, release, etc\n\nThen we fill in all the gaps. Some were irrelevant so we greyed them out, but we were able to quickly see where the gaps in our thinking were. And it helped us reach a solid shared understanding. Another way to achieve this is through impromptu discussions...\n
• #39: Non-designers will happily contribute 15-20 mins of their time here and there if it leads to a decision, even if it’s on the smallest thing. \n\nSketch to reach a common understanding and make a decision on something. Even if you decide on something that’s different to their ideas, they will still be able to see the decision-making process and that gives them buy-in.\n\nIf your PM or devs don’t like being interrupted, try specifying some times when it’s ok to do these. Perhaps mornings are out, but afternoons are fine. Keep them impromptu though. They are not meetings, they are designed to speed your process by making quick decisions, not to slow you down.\n\nAnother thing you can try is involving non-designers in usability testing sessions...\n
• #40: \n
• #41: In real code, that’s maintained by a pair of design and dev custodians.\n\nThis is a hell of a lot of work, especially if you have multiple products, \nbut once it’s in place you’ll find it actually increases velocity. \n— Less discussion about “style” – more about “purpose”\n— Designers have access to a versioned flat file they can build prototypes from \n— Developers have an established set of approved patterns they can use and reuse without having to write and rewrite\n
• #42: \n
• #43: We have discussed a number of ways you can use design transparency to your advantage\n\nBeneficial side effects\n— Non-designers become more UX-aware\n— You won’t need to write as much documentation\n— Increased design velocity\n— Bring value to you customers sooner\n\nWith practice, you and your team will improve\n
• #44: \n