Today I’m going to share my design process.
While every project is different and often requires it’s own tailored approach, many of the problems I have worked on have gone through roughly the same stages. I’ve worked on a lot of projects over the years, and while most of them had different timelines and different resources, my approach was similar.
My Design Process
Everyone has their own process, and I’m sure you have yours. Today, I’d like to share mine.
1. Understand the Problem
In order to solve the problem, you need to understand the problem. Get the facts. What data are you working with? What platforms will you be deploying to? Are there any special dependencies, such as ‘user must be logged in’ etc?
What are the timelines? If the timeline is short, is there anyone you could ask to help out? Do you need to collaborate with other departments, and if so, how can they support you?
What are the goals and expectations of this project or feature? What would success look like? This sort of information will guide you through the design process and help you propose a solution that will suit everyone.
Asking these questions will also ensure that the project is well thought out. Sometimes it’s possible that a stakeholder has a great idea for a feature, but the details haven’t been fully realised. Asking these questions will save time in the long run by making sure that the project has been considered fully by management before arriving on your desk.
Sometimes it can save time if you can clarify the goals of the project by doing some rough sketching on the whiteboard – just to get a basic understanding of the project goals. But if you’re happy with the facts, it’s time for step 2.
2. Time to Sketch
Take your requirements and get a few blank sheets of A3 paper, get your favourite pen and (if you’re like me) put the headphones on. I like to spend about 20 minutes thinking about the requirements clearly, and writing down as many different ways to solve it as possible.
At this point it can also be helpful to look at other examples of websites or apps that have implemented a similar solution, and evaluate their effectiveness.
Either way, 20 minutes of brainstorming the most solutions as possible, and if you’re like me, 1 will start to stand out as the most optimal.
Try not to get too attached to your favourite idea, give everything a fair chance. If you’re interested, I’ve written before about using sketching in my design process. Take all of the ideas into step 3.
3. Zero In On The Best Solution
Normally, one of the sketches will stand out. I like to keep sketching other ideas just to try out other things, and not get too stuck on 1 solution from the start.
When you have an approach that you think will satisfy all of the requirements and also be user friendly, take this idea and run it by the stakeholders. It’s still just a sketch, but it doesn’t need to be any higher than this just yet. The next step is to take it back to the stakeholders to (hopefully) get sign-off.
4. Communicate and Clarify with Stakeholders
So it’s time to show your sketch to the stakeholders. It also might be a good idea to verify technical feasibility – ask developers if they foresee any issues with your approach. That way, you don’t waste time on a design that will never be possible.
The other thing that you need to verify is whether the content and existing data will support your solution. With real data, you can start creating a prototype.
5. Refine Solution with Real Content
Take the sketch and create a layout in your design tool of choice – these days I use Sketch. Create a wireframe and add it to the Jira story (if that’s how you roll) to make sure everyone is up to date on the progress. If the project will include an interaction pattern, now is a great time to make a simple animation to show this. I use Principle.
Personally, it drives me crazy when a designer creates a mockup and doesn’t use real data. When I worked in ecommerce, I would go on Dribbble for inspiration, and most of the checkouts on there wouldn’t support product names on a 2nd line and stuff like that.
The only way to test a layout is to use real data. It used to be a time consuming and tedious part of the process, but now the Craft plugin for Sketch is a pretty cool way to pull in real data.
Depending on the timelines, you might need to create a quick wireframe. If you have more time, it would be a really great idea to test your solution.
6. Test, Refine and Iterate
It is time to build a prototype and test it. Not all companies will have a huge testing budget, and sometimes time isn’t on your side – but that’s ok! In the past, I’ve taken designs to the legal department just to test out an idea. Get creative, head down to the local Starbucks.
I wouldn’t advice you test your idea with people in your team, because everyone on your team will have their own bias towards a solution, whether they are aware of it or not. Office management, HR, finance or recruiting would also make ideal candidates for testing.
It’s possible that you will go back and forth between step 5 and step 6 if you find your design confused users. That’s ok though, part of iteration. The finished product will be all the better for it.
The final stage will be the handover.
This is something that I feel a lot of designers overlook, but it’s a very important step – the handover. If you’re working with a developer, sometimes pairing is a great way to make sure the designs that are signed off are the ones that are implemented. It’s also cool if you can be there when they need you to answer questions. I always request if I can sit next to the front-end developers, and I’ve built some great working relationships with them in the past.
Handover processes can vary too, and there are a lot of new tools coming out to try and bridge the gap between design and development.
In a world of Sketch, Invision, Marvel, Zeplin and Photoshop, your best bet is to have a single point of truth, that way you only need to keep 1 account up to date with the most recent designs.