By Michael Heraghty on November 14th, 2014
I’ve written previous posts about how I use Balsamiq Mockups to create wireframes and prototypes, and my methods for usability testing. But these are parts of a bigger process — getting from an idea to a finished website, application or software product.
When a new client engages me to work with them on a new design (or redesign) project, they are keen to know “What method did you use?”. While the components / tasks are flexible, the process is consistent:
On website or application projects, participants are usually eager to get stuck in — to start building something — as soon as possible.
Many believe the way to get a “minimal viable product” is to start writing code on day one. Experience has taught me otherwise. The analogy is painting a watercolour — the wise artist knows, of course, that more time arranging the fruit optimally leads to less grappling with their masterpiece weeks later.
Before designing, I will undertake at least one, often several of the following research tasks.
Some of these tasks, like storyboards and card sorting, I undertake only occasionally — it depends on the individual project (card sorting, for example, is useful for sites with large information architecture problems). I am always open to new tasks (or “tools”) that fit in with the general process.
I usually hold a series of workshops on the client site. The participants are a small group of key internal stakeholders, including a development / engineering team leader.
Often the client does not know precisely what they want. Part of my job, at this stage, is to tease out and challenge their loosely-formed ideas.
Throughout the client workshops , and I continue listening, but now I am able to inform the client about what I have discovered based on the research I am undertaking.
During these workshops I will develop some early-stages sketches on a flipchart or whiteboard, and the stakeholders present will all pitch in with their ideas. We effectively develop the initial wireframes — a visual representation of the product requirements — together.
I take a photo of these whiteboard pages on my phone, along with other interesting online artefacts that arise during the meeting. For example, the marketing person might say, “I like the way they do the login on Dropbox”, so we’ll look at the Dropbox login, and I’ll take a photo of that.
After we capture the sketches, it’s time to create a prototype. One of my strong skills is interaction design, yet I am not a graphic designer, so I feel comfortable with Balsamiq Mockups.
I am always relieved switching from the initial sketches to an on-screen prototype partly because my sketching, like my handwriting, is scrawly. I literally think better with Balsamiq’s clean interface.
I always create clickable prototypes. I’ve already written a post about how I create prototypes using Mockups. Clickable prototypes work best for client demos. Plus, I can conduct better usability testing (see below) on clickable prototypes.
By creating the first prototype, and clicking around, I will notice some obvious flaws. I quickly make a second version. I keep all versions, so I can show some design variations to the client. After rapidly moving to version 3 or 4, I return to the next workshop armed with my prototypes for internal stakeholder feedback.
Based on the feedback, I iterate again, making simple changes live in the workshop, and, if needed, more complex ones afterwards. Usually after one more workshop, the prototype is ready for usability testing.
If I can’t get real users (people who match the client’s target audience) to participate in the usability testing, I will get proxy users — preferably someone who loosely matches the demographic, but in the end, anyone with a heartbeat who isn’t closely associated with the project. The client will say, “Can’t we just use the developer/designer/marketing person?”.
This makes sense to managers — in the client’s timesheet system, project staff can mark time against the project. I resist these requests. I prefer to take non-project staff, e.g. people from the accounts or HR department. Those closest to the project are heavily biased. What we’re looking for now is external validation.
I review the results with the project stakeholders and we discuss what needs to be fixed in the prototype.
In the best projects, one or more stakeholders will have directly observed the usability testing. I’ve written another, more extensive blog post about my user testing process.
The design “settles down” after the first or second round of usability testing. first aid vhealthportal.com medicines online. If users seem to be “getting it”, with only minor tweaks required, it’s time to move to visual design.
If the client does not have an in-house visual designer, the client may ask me if I can get the visual design done. Luckily for my clients, I’ve built relationships with a few world-class visual designers, based in Asia. If the client needs to, I try to get one of these designers involved in the project (it depends on their availability).
Part of this task is to identify which wireframes, out of all the pages in the prototype, need to be turned into visual design templates. For example, there may be 40 or 50 pages in the prototype, but many will be only minor variations of a previous page. For time and cost efficiency, I identify only the key templates, with unique UI components, that a developer will need.
I will work with the visual designer to get the look right. Subsequently, the client will request some revisions. Overall, the revisions needed to the visual designs typically tend to be just tweaks (example: “Make the font size a little bigger in this headline”), not large layout changes.
Creating clean and beautiful HTML and CSS from good quality Photoshop files is now a lot easier, especially if you use skilled practitioners.
There are all sorts of tools and frameworks, like Bootstrap, or Adobe Brackets, that can help. Again, many clients ask if I can simply provide the HTML and CSS for them and, again, I have some great Asian partners who supply beautiful, clean code that my clients’ developers always love.
Depending on the number of templates, it usually takes around a week or two to get the HTML and CSS files. This is front-end code, ready to be handed over to the developers.
On some projects, particularly for software companies, it can be useful to create a high-fidelity prototype at this point. I’ve done this for clients where:
Creating the high-fidelity prototype, using the HTML5/CSS files, for example with custom jQuery, is useful in this cases
Once you create a high-fidelity prototype, the next step is to test it with real users and then iterate it. I’ve used this usability testing on a high-fidelity prototype approach several times for one software house client in particular and it ultimately saved a huge amount of back-end coding effort.
Before the client’s development team has written any of the “difficult” code then, they’re getting a beautiful, internally agreed and validated, user-tested front end.
Unfortunately, sometimes my involvement ends at this point. When I say “unfortunately” — I mean unfortunately for the client. I dislike throwing a design over the fence to developers, but I understand that the client sees things in terms of budget: the UX consultant (and his subcontractors) are budgeted for X days.
On every project, however, I try to instill the “user centred design philosophy” in the client’s mind. Because the user’s experience doesn’t end when the product, website or application product is launched. It just begins.
For clients who are more “bought in” to the UX philosophy, what I’ve next is simply…
In fact, most times, my involvement in a project starts at this point — i.e. when a product, website or application is already live. People who already have a website, application or product ask for my help to “make it more user friendly”. I do my best of course, but when I come to an already-existing project, I’m really doing the same things I do in step 1 above…