Developing Stages: Part 5 — Make it Work

Chronicles of an interaction design student turned UI engineering intern.

Easy to say, not always easy to do.

Week 5, Day 1: Summer in the Sun

Monday started off slow because, you know, Mondays. I took the opportunity to polish up the mobile examples of the design concepts. The manager alleviated the Monday blues with a coffee break in the (freakishly warm) summer sun. With a fresh slate, it was back to work: presenting the concepts in the weekly project conference with the Americans and adding a few extra notes to the files before sending them across the pond.


  • Remember, when you’re sharing your screen in the video conference, no one can see you gesturing and pointing like a crazy person.

Week 5, Day 2: Aligning Design and Development

With a few final emails, the concepts were off to await feedback. In the meantime, I took the opportunity to begin testing some of the common interactions which appeared in multiple concepts. An interactive logo animation sounds great on paper but how well does it actually work (and does it still look good)?


  • Always, always, ALWAYS check for attachments before sending an email.
  • Listening in on a conference with the rest of the department in America reinforced the challenges that can come in aligning design and development teams within such a large organisation. UIE bridges the gap between the two and it is insightful to see the real challenges (especially when it comes to the design team, because I can see how I could cause some of the same issues).

Week 5: Day 3: One Concept to Rule Them All

We narrowed it down to three concepts each but there can only be one for the final product so now it was time to review ad consolidate. Step 1 began with analysis: picking apart each idea to find not just what we liked but why and identify problem areas. With a much firmer grasp on what we wanted, step 2 was convergence. This left us with two designs and the challenge of how to proceed with the contrast in styling and content structure between the two.

The challenge was solved by my design partner, who suggested we take one at a time to see how they could be improved by focusing on the points we defined during the analysis. Looking at the specifics rather than the differences between the two opened our eyes and soon there was one design to rule them all… well maybe not, but six had been narrowed down to one which we now had a much clearer idea about after talking through each decision.


  • Ah GitHub, so useful and yet so easy to consume a morning fixing merge conflicts. On the bright side, git is slowly becoming second nature.
  • There is no better way to identify problem areas or areas you hand waved without truly considering the details than talking through your design with someone else.
  • Don’t write off a design just because you don’t like it. Stop and think why. While doing so, you might also surprise yourself and find some ideas you do like.

Week 5, Day 4: Okay, Now What?

With the design fleshed out a bit more, we still have to figure out how to actually make the thing. That means more wireframing and pooling our coding knowledge to find solutions. Some question marks still remain but a good start before I have to leave for the intern breakfast (afternoon tea/video conference for us across the pond) with Allstate’s head of technology.


  • It’s okay not to worry about the code while sketching but make sure your designs are as resilient and flexible as possible. Anything relying on gimmicks should be weeded out at an early stage. That way even if the weird stuff isn’t feasible the design still holds up and it makes the next steps (figuring out how to make it work) much less stressful.

Week 5, Day 5: Piecing Together the Puzzle

It’s only the temporary design team (a.k.a me and the placement student) in our corner of the office today but we’re a bit in the dark when it comes to some aspects of the code. Still, looking at yesterday’s leftover problems with fresh eyes brings fresh ideas and it will be a matter of ironing out the particulars (not always simple, but it’s a start). Then it’s splitting up the work to start creating some example prototypes for next week.


  • Figuring out how to make something work isn’t always about being a coding expert, sometimes it’s no different then the same problem solving you use for designs.