This one is for all you developers who work together with designers and also for all you designers who work together with developers.
Never been in a situation where the designer comes to you and says:
”I’m not sure if this works after all… but (!!) we are not doing waterfall! Right? Let’s be agile and change it if it doesn’t work guys!”.
Or maybe the designer comes and gives you a (fair?) warning after sprint review by saying:
”This was not actually how I imagined it but let’s be agile! I’ll do some sketching. Okey!?”
Yes – it’s true. We are doing it agile. But having to face this scenario multiple times during development can really start to eat teams motivation of getting things shipped.
Been in a situation where you have designed a nice little feature that just looks great and works like a charm? After a month it seems like rubbish and you might want to take some actions of redesign? You might think that agile way of working gives you freedom for that? Just a bit of CSS magic and it would be great again!
I’ve noticed that as a designer I used to do this all the time and it really bugged me. Designing agile doesn’t mean doing the same stuff over and over again. Just ship it! Right? Here is my ”learn from mistakes” -list.
My list learned:
A short version of things in my personal Defination of Done list. Things I need to make sure before design and after. What’s your DoD?
1. Write down a design DoD for the project
(Defination of done) Break it down in to a shape of workflow. Make sure everyone can access it explain it to the team. I think it’s easier to follow a workflow format DoD in design process.
2. Write down your own personal design flow and DoD
It’s important to make a promise of high quality just for your self. Have a coffee break and make the list. Don’t change the flow or DoD right away if it doesn’t work. (but if it really doesn’t work please change it!)
3. Remember to include small user tests checkpoints into your workflow
It might be enough to hand your screen plans over to a co-worker. But write the action point down in your workflow.
4. Have a business goal reality check before every sprint
Before you start designing anything make sure you have a reality check. Speak (or write) out load some user scenarios, stories and ”other planning stuff to get you going” like slidesha.re/1innFD2. Make sure you have understood the actual business requirement. If your design is the first touch of a totally new requirement you should really use some time sketching multiple variations of the same feature/screen. The first one is hardly never the best one. Actually, you should always make multiple variations (but there just might not be time for that, I know).
5. Start your design with a really rough wireframe
Don’t try to iterate the whole wireframe in one session (or sprint). Select smaller pieces and focus on details. Wireframing a whole website/application beforehand is not a good idea (really it is not). Let the navigation or a toolbar be a box. Just a box. Nothing but a box. (a ”must read” article by Brad Frost about Atomic Design)
6. Shout out hesitations!
If you have hesitations about your design shout them out! Do rubber ducking with the team. Don’t try to solve everything by your self. Ask developers and be opened about the design issues you find hard to solve. Also get back to the workflow and ask: ”have I followed the DoD and the workflow?” Did you really know what was the business goal or the user scenario? Don’t ship designs you feel uncomfortable with.
7. Work at least one (or two) sprint a head of the development
Some say you should newer have the design done ”sprints a head”. My opinion is that you should. Doing so allows you to do things listed in 1-6. It leaves you time to do user testing with wireframes. But be sure to spare time to help with development design details during sprints. Be ready to make small changes instantly. One joint sprint backlog (design + development) is a good idea but it might be easier to have design tasks tagged.
8. Be one team
Your building the app together. Share the joy and the frustrations and be a team.
Are you struggling with similar issues?
It’s never easy to bring your ways of working in bright daylight (cause you just might be trying to solve stuff people been buzzing around the web five years ago!). This is just my learning story. What’s yours?