I’m currently in a team of 3 people working on a redesign of a website. To me, this feels like my first “real” design project, one where I’ve initiated without any requirements for software implementation. Instead, we began to ask ourselves who are our users, and what exactly are we trying to communicate to them?
User-Centred Design – Using What Works For Me
I felt that a lot of “formal” usability methods didn’t help me much, here. I felt somewhat trapped by procedure and process, thinking about best practices for wireframes, personas, user journeys, etc. Having been exposed to too much user experience jargon, I realized that user-centered design isn’t necessarily synonymous with visual design. In fact, each stakeholder seems to have a different understanding of who the user is, even if the differences are slight.
What ended up working for me was to put down the questions I felt the users would ask (while using the interface/application) onto little bits of post-its, and looked for patterns like organizing those questions into related categories. I organized this in several ways:
“User Journey”-type Things and “Site Map”-type Things
One way of visualizing the questions was to list them out in the style of a “user journey”, which were lists of questions laid out in a temporal fashion (e.g. question A leading to question B as a user traversed deeper into the application). This helped me understand which questions to address first, and which to address later. It helped me prioritize my workflow, and make decisions on which interfaces to work on first. It was already obvious that we needed to focus on designing the homepage, but there were other pages that weren’t immediately obvious, such as a page to help users to “learn more” about the product – that page only came about after looking at the questions from the user journeys.
Another way was to group the questions that were related to one another, and label them as categories. That helped me to visualize the overall site layout, because I absolutely hate building software in the dark – and that includes building on software requirements without understanding the whys to the point I’m convinced of its business and user needs.
At this point, I hadn’t used any formal methods I had learnt from a class, website, or book. It was good that I understood who I was designing for, and I wouldn’t have been able to do this without classes, websites and books – but the formal methods were pretty useless. I just used what worked for me.
We Used Fireworks, but I can’t Recommend it to You
It’s important to note that two of us jumped onto paper and pencil and did wireframe sketches, and then designed a hi-def visual of the homepage on Fireworks (which I now really love) – only because we were three people and we couldn’t quite picture the outcome in our minds. At the same time, we needed our boss to make a decision and he has a lot of emotional attachment to the look and feel of the site, being the founder and all. So it was important to get those designs out.
I don’t think I can recommend the same process to other designers – it really depends what you’re designing for. Those fireworks designs took up several days and a lot of it was thrown out of the window as we iterated from one design to another. But I think that’s necessary in design, sometimes – because the interface is what users will end up seeing and using, again and again.
Sometimes I read articles from other designers and it all sounds really cool and makes you feel that there’s some kind of order or process in the design of an interface. But I find these things hard to use because it’s the designer that makes a difference, not the method. It’s about knowing what you know that works – a process or method can’t save you. They’re just tools.
