4 Steps for Less Heartache in Your Design Development

Before I came to eLearning Brothers I learned something that I have tried implement since. I worked as a Professional Services Manager & Design Manager for an eLearning Software company. My role was to help customers customize different features about the software. I would meet with the client to talk about what they were wanting, I would then talk with my team of developers about what it would take to do the customization and then I would see the customization through the development process.

What I Learned…

One thing I learned from this process is that what the customer wants versus what the developer understands is often very different. Even if I tried explaining the same thing to both the customer and the developer. This would often lead to frustration or confusion when I would show the customer what we did and them coming back with “That was not all what I expected.” I would shake my head wondering where I went wrong, was this not what they wanted? How did I misunderstand? I have even felt this frustration as an eLearning Developer when I was handed a storyboard with just text and what I envision in my head ends up being completely different than what the instructional designer had in mind—including the client.

I came to the realization that often what is talked about on the phone is imagined somewhat differently in both parties minds. I learned to avoid this miscommunication during development can even speed up development time by following these four simple steps for less heartache in your design development:

1. Wireframe your eLearning Courses – It sounds like a simple concept but it is so often overlooked (I am talking to you random reader!). If the Instructional Designer took the time to wireframe each page and I mean visually creating the pages with just box frames, here are the benefits.

– The Instructional Designer is instantly able to see what they are imagining in their heads as they outline it. So if they type in a bunch of text for one of the answers to a question then they can see instantly that may be too much text and they need to shorten it. I guarantee if a developer gets all the text they assume should be in there.

– The client (or whoever you are building the training for) can instantly see what you are going to build before you build it. It does not take that long to draw some boxes to show what you were thinking compared to having a developer create it all and then have the client say it was all wrong.

– The developer can visually see how this interaction is suppose to layout. They should be more focused on how the interaction should work rather than trying to interpret how this page was suppose to be laid out.

– It gives the designer a frame a reference to start from. I have found you get better designs if you give your designer a frame of reference. The designer knows what and where you want things so they just focus on making it all look good.

– It gives you a frame of reference if during development some question or concern comes up about what should have been done.

2. Explain your outlines – This step I found to be the most useful. When I was designing a game, I would place the buttons on the screen and create a document with arrows pointing to each button with a short description on what this button did. I cannot even tell you what time it saved. If I did not do that I would have the developer asking me a lot of questions and them doing what they think you or playing that guessing game.

3. Prototype – Now you don’t have to do this on every page but the pages that call for interactions it is best to prototype how these interactions should before you even hand it off to the developer. There are a lot of prototyping tools out there that are fairly easy to use. One of my favorite is Balsamiq. It allows you to link buttons to different pages. This shows the developer how an interaction should but more importantly it shows the client how the interaction will work. I know that I have developed something for a client only to have them come back and have me rework it completely different many times.

4. Test and test again – Instead of spending development money on rebuilding/designing everything from scratch every-time the client doesn’t like it. Work out how it will work in the design phase before it gets over to development. Also, once you have prototyped your interactions, have the client test and give you feedback.

If these 4 steps are followed it will save you a whole bunch of time and money during development. Sounds easy? It is, but it is also easy to not easy to do.