Published on <a href="https://blog.prototypr.io/can-design-be-agile-d708f03e3671?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Andreea Ardelean 
I started writing this post a couple of times at various times, mostly as a rant. But today, today is the day! Today I won’t rant. I’ll just tell it how I see it, how it is.
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*v03kZaAMDo2AVJePKWRuKQ.jpeg">
<h3>Yes it can.</h3>
There are no two companies the same so there are no two team problems the same. But if you boil them down to the essence of the problem — they are. And their solutions are more or less tackling the same core issues. And so, some patterns arise. Patterns of problems 🙂
And to get to the best solution… you have to have the right tool for the problem. Just like with anything, you have various tools to use when you need to solve a particular problem in an optimal way. A hammer for a nail, not for a screw. “This is an illustrator joby, but use sketch for the other bit!’ type of thing. You could use sketch or illustrator or whatever, but a bit of good process can go a long way.
So what are these tools? They are particular ways of going about doing things. They have worked for me, at various times on various teams, products and services, no matter how much I heard “this one is different”.
So here is my toolbox of agile processes that can work in design. Take a look and use responsibility.
<blockquote>You’re new in a team or been there for a long time and know all the ins and outs, still, have a go and:</blockquote>
<h4>Put to-dos on cards and have a board</h4>
<blockquote>I don’t know what I’m supposed to work on.</blockquote>
<blockquote>I don’t know what’s next.</blockquote>
<blockquote>I don’t know the progress on things, when are they going to be delivered?</blockquote>
Maybe a ‘duh’ one, but write down what you need to do and what people ask of you do to, change or add last minute. These are your to dos. I wouldn’t add answering emails and small admins tasks, unless they are not small and take up a big chunk of your time.
Then use a board, either on a wall or digitally (using <a href="https://trello.com/">Trello</a> or <a href="https://www.atlassian.com/software/jira">Jira</a>). Have 3 main columns: To-do, Doing and Done. Soon you’ll need a Blocked column too. I’ve used columns for In Review and Needs Content too, but it depends on what your project needs.
Update the board as you go, moving cards from one column to the other. Sometimes you’ll have a few cards in Doing at the same time, but try not to have too many. Realistically you only work on one thing at one time. Everything else is either waiting to be started, blocked or waiting on other things like feedback, content, etc. So reflect that on the board. It will really help to be accurate, trust me. For your peace of mind, your Product Manager and colleagues can see progress without disturbing you.
For extra points: assign people to-dos, especially if something is blocked. Flag it to the person who can fix it for you. If a to-do is in review, waiting for content etc. flag it as someone else’s to-do.
<h4>Prioritise them</h4>
<blockquote>Which one should I do now? And which one after that?</blockquote>
<blockquote>They are both super urgent. Which one needs doing right now?</blockquote>
Prioritisation should be done with a Product Manager (PM) or Product Owner (PO). There can be other team members involved like Business Analysts (BA), Researchers, Content Designers or developers. I honestly find it very useful for a developer to be present. They know how they will build things, so they could positively influence the delivery order of designs.
There are a few levels of prioritising things, from top level (inspired by the roadmap, commercial objectives etc) to day to day. It might seem daunting, but let’s start from the beginning. Book a meeting room and write each to do on a Postit note.
Top level: Make 3 columns, time-boxed: things to do now (next month or 3 months), things to do next (3 months), things to do later. When you get to the end of the first month/3months, do another prioritisation to bring the work forward.
Things to do now: Take all the Postits in the first column and put them in the order that you’ll tackle them. Don’t forget to take consider what makes sense for developers and other stakeholders. You don’t want a blocked to-do that you can’t move because it has a dependency on something to be delivered in 3 months time by another team.
<h4>Split your to-dos into bits</h4>
<blockquote>I have no idea how long this will take to do</blockquote>
<blockquote>This will take a while…</blockquote>
<blockquote>How do I even tackle this?</blockquote>
Super important! Split your to-dos in deliverable independent chunks that can be delivered. For example, you are redesigning a homepage. How do you even start? Your Product Manager is asking how long will it take to do something like that. You puff and raise your shoulders. Then you start working on it, but it’s so much to do that you feel overwhelmed. People start giving you feedback on various bits and you don’t know what to fix first. Stop!
Split your to-do! Then split it again. One page or feature can have quite a few to-dos. How do I know when it’s the right size: usually I work per component, for example a pricing table is one, the main menu is another, then you have the featured articles, filter, contact box etc. I think how would a user interact with this component no matter where it could be in the service/website/app, so independently of what’s around it. That is the right amount of information to focus on at one time. Also think about how you’ll test it, get feedback and iterate. Can you do it independently of other elements? Right size 🙂
Of course, it depends on your project and it’s components. Try it and see what works for you.
<h4>Size them</h4>
<blockquote>So how long will this take?</blockquote>
It’s a difficult question to answer, isn’t it? The key to answer this is splitting the to-do into bits that you can wrap your head around how long they’ll take to do. So how do you do it?
There are various ways to size work, from top level to super grainy. Top level would be t-shirt sizes to grains of complexity points. Start with the top level and work your way down — stop where it makes sense for you and your team.
T-shirt sizes: Can be done while you’re doing the prioritisation as size can influence order. You have 3 sizes of t-shirts: small, medium, large. Quite intuitive what it means, but don’t forget when you have dependencies, big questions unanswered they add to the ‘size’. So on each thing you plan, try to add a size to it. Right now you don’t know how long it takes, but you have an idea of how complex it is to solve it. This comes from experience as well. Don’t be afraid to approximate or overestimate, just give it a go and amend as you work your way through your to-dos.
Complexity points: A lot of people roll their eyes at complexity points in design (even in development too sometimes). For me and the teams where I’ve worked like this, it really really worked! At a super high delivery speed too. This should be done on the small split to-dos. The complexity points are usually the numbers 1, 2, 3, 5, 8, 13 (Fibonacci’s sequence — i won’t go now into details why this makes sense instead of 1,2,3,4,5,6. maybe in a future post).
Give each task a number: 1 is obviously something super easy (for me this would be a content change in a sentence or a small styling fix) to 5 (for me is I kinda know how to solve it) to 13 (I need to do some digging and explore a bit on how this can be solved). It takes time and a few go’s to get it to reflect the time you spend on each complexity level. I find this way is a better way of working, by sizing the ‘complexity of creativity’ instead of putting time on it.
I find sizing super helpful when prioritising and planning as this is the only way I found works to set expectations of what will be delivered and when. Also getting overwhelmed becomes a from-time-to-time occurrence rather than routine.
<h4>Planning</h4>
<blockquote>And when will it be done?</blockquote>
Planning comes shortly after prioritisation and sizing. You plan what you’re going to do in an arbitrary time frame. That may be a week, 2 weeks, a month. I would recommend shorter time period. I prefer 2 weeks as it’s easier to wrap your head around, but find what works for you and your team.
Look at the prioritised list of sized Postits. Start grouping Postits in your planned time frame. How much complexity you feel you can tackle in that time frame? Just have a go, trust your instincts and see how it goes. If it was too much, next time plan less, same if the opposite happened. With time, you’ll find your number. I’m usually around 30 points every 2 weeks. Ish.
Planning is important, again, for giving a clear idea of when designs will be ready to PM/POs and other people depending on you — researchers testing your designs, BAs planning the next development sprints etc. Also important, to set an expectation that if something ‘urgent’ comes in it will push things. “I can deliver this today, but something else might be late”. Another thing, if people come to you asking for various things you can always say: that wasn’t planned, talk to our PO to establish the priority for that. You’ll be surprised how things start falling into place and that overwhelmed feeling stops occurring.
<h4>Stand-ups</h4>
<blockquote>I don’t know what others are working on.</blockquote>
<blockquote>I don’t know if we’re on track.</blockquote>
<blockquote>I’m taking longer than it should. I hope people will be ok with that.</blockquote>
A stand-up is a quick meeting where its attendees typically participate standing. Therefore it can’t (shouldn’t) last long. It’s usually in the morning and everybody should give a quick update of to-dos on the board.
I personally prefer the format: “Yesterday I did this and today I’m planning to do this. I am/was blocked on this but now all good. etc”. But there are variations on it. See the tips for extra points below.
You need stand-ups for transparency of everyone’s progress. You get to know what others are doing, if they are interacting with what you are working on, if you have some insight on their issue etc. Stand-ups also help you to see how the project is moving, on time or late, you can help unblock things, spot issues early on and better understand how long things take.
It’s a bit daunting maybe to talk about what you’ve done yesterday and what you are you doing today. Especially if you feel it’s not much progress. But that helps set expectations to the people (PMs) that give updates and establish deadlines to people higher than you. Also, it’s ok to say you are struggling. People can help or facilitate help. And when it happens, it’s so satisfying to move cards to done 🙂
For extra points: as stand-ups shouldn’t take longer than 10mins ish, if the team is too big, go around the cards on the board and ask for updates on them instead from people. The downside of this is that you don’t hear from people who don’t have cards on the board (like PMs, BAs, etc).
<h4>Show work in progress</h4>
<blockquote>Why aren’t they backing me up?</blockquote>
<blockquote>Why don’t they believe in UX?</blockquote>
This is a difficult one. As a designer, you might not want to show work in progress. You only want to show it when you’re happy with it, to show the shiny things. But other people need to understand how you got to a solution.
Designers or not, people like to see process and understand thinking. And if you ask for feedback early on, they feel invested in the product and they also back you up, because you both reached an agreement on how to solve the problem best.
Be confident and a bit less precious about your work and show it to people as early as possible. Think of it as early usability testing. Get a sense check now, so it’s easier to change things and experiment. By showing the process of designing, you’re an advocate for UX. So please do — we are trying to change the world after all 🙂
<h4>Design reviews</h4>
<blockquote>I’m dreading showing my work.</blockquote>
I still do sometimes. But if I show solutions early on, and more or less in each stage of designing it, when it comes to a ‘proper’ design review it’s easier because you’ve already taken people through the solution’s journey.
You need to tell the story of the solution. Start with the problem you were trying to solve, how you came about solving it, issues that occurred and then show your proposed solution. Also, be open to feedback. Yes, it might sound like critique sometimes, but you should have all the answers and reasons why you did what you did. If you don’t, maybe take a few seconds and admit that might be a point of view you hadn’t thought of before?
<h4>Test it!</h4>
<blockquote>I’m sure this is right…right?</blockquote>
<blockquote>Can’t you just press that button? How can you not see that?</blockquote>
I know usability testing is often a commodity for companies. I’m not going to go into details why testing with real users is important and invaluable. Convincing your team or company to invest in testing is a whole subject for another post, but there are bits you can do in the meantime.
Testing is not just lab usability testing with one-hour sessions. Testing is showing early progress to your team or other designers, or grabbing a few people in your building to use your work. Look out for reactions and interactions, not opinions and solutions on how you can do it better. Trust those observations and they can take you a long way.
Remember to try and include people with various needs, not just your digital know-it-all young colleagues.
<h4>Iterate! And again!</h4>
You want to make it better. This means admitting you didn’t get it right the first time, or the second, or the tenth. And hey, that’s ok.
With strict deadlines and huge workload, it’s sometimes difficult to push for iteration. You have to arm yourself with results from usability testing, feedback gathered, data from analytics etc. into an analysis of how much impact this unfixed problem has and pitch it. Sometimes you win, sometimes you have to choose your battles and add it in the backlog.
<h4>Retrospectives (retros)</h4>
<blockquote>I have an issue, but I don’t know what to do about it.</blockquote>
<blockquote>I can’t really tell that person that… or tell anyone.</blockquote>
I truly believe regular retros are necessary. Sometimes it is difficult to voice problems and a good facilitator should help with this during a retro. Regular time-boxed ones are important — that’s when you voice problems, otherwise you only talk about generic problems. Ask someone outside the team with retro facilitating experience to help you.
<h3>Now, do this all together</h3>
… in a cycle of 2 weeks and there you go — agile. It’s happening!
But it’s just a label after all and in the end it doesn’t matter. What matters is transparency, expectancy, not being overwhelmed, feeling listened to, trusted and in a happy team. And yes, I truly believe processes like this can help with all of that.
It’s difficult to implement change in a team and I think that’s one of the hardest things to do especially when you see those patterns of problems. But there are lots of ways to give one of the processes a go (you don’t even have to call them processes or fancy names). Try a process once and then amend it to fit your team better, add another one etc. Prove it works and try some more. For example, if the team doesn’t want to do sizing, I still do it for myself because the “How long will it take” question always comes up. Always.
Some people may say this isn’t true agile and maybe it’s not. It has worked for me and my teams, it has brought us to the goal that agile wants to get to. So please, if you have more experience in how design can be agile, do tell and share with others.
After all, we all want to feel empowered, trusted and in a happy team.
Andreea
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=d708f03e3671" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="https://blog.prototypr.io/can-design-be-agile-d708f03e3671">Can design be agile?</a> was originally published in <a href="https://blog.prototypr.io">Prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Can design be agile?

Top Stories