Hi Lewis
Welcome to the community. I feel like you’re in the position that I was in 10 years ago when I was lead designer on a new project and didn’t know the best place to start. Good on you for reaching out! It’s exactly what I did, and resulted in my process improving immensely.
We’ve written quite a bit about process on the site that should be useful for you. In particular, you should go read the article on UX process and have a look through our [URL=“http://uxmastery.com/resources/techniques/”]Techniques Bank.
You’ve got the right idea in terms of wanting to get the lay of the land. Conducting interviews and analysing competitors are both good techniques to employ early on. Looking for conventions and finding existing solutions that are leading the way can be useful, but be careful not to get stuck into saying “they do THAT—we should do that too!”
There are a bunch of questions you should ask, and (in my opinion) some crucial steps missing in your process. Here are a few thoughts:
[LIST]
[]What’s the end goal here—what’s the company’s [B]strategy[/B]? Why is this project happening in the first place, and how does it fit into the bigger picture? Make sure that this has been clearly communicated, and that you and your team are on the same page about what the success criteria is here. If it’s not clear, be sure to get to the bottom of this when you interview your stakeholders
[]It’s great that you’re interviewing stakeholders, but what about [B]user interviews[/B]? If this is a new project, you may be thinking “we don’t have any users yet!” Fine, but you should have at least a vague idea of who you’re targeting here. You should find some people who fall into this user group and talk to them—ideally in the environment that they would use your product. Yes, that may mean going into people’s places of work or their home (often call [B]contextual inquiry[/B]). Sometimes that can be tricky to organise, but it’s worth making the effort (call in family members if they fall into your user group, or friends of friends, and offer them movie tickets in exchange for their time). Get to know what’s important to them, what their motivations are, and what their needs are, to make sure that whatever you’re building will resonate with them (hint: you could even run some usability tests using competitor’s sites, to see what confuses them and what your competitors are doing well/badly).
[]Before you dive into wireframes, you need to make some sense of all of that research data, and find a way to model it. Otherwise it will just be a bunch of subjective learnings that exist in your head. You should strive to be more transparent in communicating what you’ve learned from your research activities. For example, a common technique is to create [B]personas[/B] and [B]scenarios[/B] (or [B]storyboards[/B]) that capture the world that your users live in, and demonstrate how your product will address their needs and help them. This is important for a bunch of reasons: 1) it can help clarify your findings, 2) it is a great way to communicate the findings to others, so they don’t have to wade through the research data, and 3) it takes people (e.g. managers) on the journey. Otherwise you’re just asking them to trust your decisions, without any clear rationale behind them.
[]You should also try and capture how users will flow through your product before you start creating wireframes, using something like a [B]workflow diagram[/B] or [B]user flow diagram[/B]. The reason this is important is because otherwise you’ll be “flying blind” and designing wireframes without knowing where they fit in the customer’s journey through your product.
[]When it comes to wireframes, I’d ease up on the annotations. Wireframes covered in annotations can be much more difficult to follow than a clickable prototype, and are harder to update when things change (actually, it can be an arms race to even bother trying to keep them up to date, as things [B]will[/B] change—you can count on it). By all means, sketch out a bunch of ideas. I always create a ton of sketches with pen and paper as part of the creative process. But once you’ve found a direction you like, a tool like [B]Powerpoint[/B], [B]Keynote[/B], [B]POP Prototyping[/B], [B]Axure[/B], or [B]Balsamiq Mockups[/B] will let you create a digital prototype without writing any code. All of these tools will allow you to specify “hot spots” on screen, which you can use to simulate a user moving through checkout. Some tools will also let you simulate transitions, pull in data, or group common components (e.g. menu bars) to speed up the prototyping process. Then you not only have a prototype that demonstrates ideas, but if it contains enough realistic data, could also be used for usability testing before any code has been written. Being able to find big usability issues and validate your direction before engaging any developers is a way of saving a truckload of money as it prevents the possibility that a developer may build something that needs to change later.
[]Finally, I’d recommend that you be as transparent and inclusive about your workings and deliverables as possible, if you weren’t planning on it already. That means doing stuff like having a [B]design wall[/B] where you post your personas, storyboards, workflows and wireframes for other team members to see, comment on, and contribute to. If there are some strong personalities then you will definitely need to run some workshops that take these people along for the ride. Exercises like a team “design the checkout page” workshop, or a “let’s review competitor sites and vote on the best features of each” can be fun, will position you as a leader, and will get buy-in on the direction you’re heading. Communicating design is as important as doing good design, and as designers we [B]must[/B] become facilitators in order to be effective at getting design approved by the folks who are paying for it. Including them in the journey is the best way I know for that to happen. Making a mess with sticky notes and large sheets of paper may be a new way of working, but it has huge benefits over doing everything digitally (and therefore hidden from view).
[/LIST] This is a bit of a crash course in what I’d consider to be a best practice UX process. Feel free to ask about any aspects of the process and I’m happy to elaborate (although those two links I included above should cover most of it!). I hope it’s helpful.
Cheers
Matt
