From “quick and dirty” to formally reviewed systems and software documentation as the deliverable, different projects require different approaches.
Here I describe my preferred way of working. As always it needs to be adjusted to the situation present in every project and can’t necessarily happen exactly as described here. But it is a starting point to get to know how I “tick”.
Just keep asking the magic word, “why?”.
First, I work with stakeholders and developers to get to know how the problem that needs to be solved is specified. A simple strategy is to keep asking “Why?” until it’s broken down to manageable parts.
A sound strategy needs to be worked out.
From the initial problem, a sound strategy for how to solve it and deliver a reasonable solution within the boundaries of the project needs to be worked out.If it is a new feature or new service that is unprecedented for the client and legacy research data is unavailable the user research would need to be more intense, while in other scenarios some interviews can be enough to get rolling. There can also be cases where user research is required to come later, where we need to make assumptions about usage. If so, these assumptions need to be clearly verified and possible altered later on in the process. This is of course not the ideal situation as it can change the scope of the problem and require refactoring depending on in which stage the assumptions are verified.
The research data that is gathered and/or preexisting then needs to be worked over to find patterns and to see that the definition of the problem is still valid. A method I’ve found effective is to use the method for impact mapping as described by inUse (in Swedish they call it Effektkarta®). This helps in driving the work forward by keeping the focus on what problems needs to be solved and the map can be effectively communicated to various stakeholders, project managers and other interested parties.
A fast, iterative approach with emphasis on critiquing and early testing.
For the actual designing, I advocate a fast, iterative approach where the designers involved can generate ideas, write them out, critique them and build upon them until solutions emerge. When there exists a sketch, wireframe or any presentable artifact it will need to get more eyes on it, and not just from other designers, so involving stakeholders, developers and project managers are essential. If this is made through a meeting it is important to keep to a tight agenda and not let it turn into design-by-commitee. When the design has matured it needs to be tested. This can be of the “quick and dirty” variety and involve innocent bystanders that happen to share a corridor with you or actual users. Here a minimum workable prototype is sufficient, just so that the user can get a feel for the finished product. Often this leads to new insights that requires the design to again be iterated.
A mature design can be prototyped hi-fi and tested further.
When the design has matured even more, it can be prototyped in a more hi-fi system and be made into a clickable prototype, and more rigorous user testing can be conducted. How this is done varies greatly from project to project but some user testing of a more polished version of the design can yield important findings. The prototype can be enriched with brand identity and consistent visual design. This helps to get higher level feedback from user testing. And as before a few iterations can be necessary to improve the experience.
At this stage the project can move forward and build the designed solution and have confidence that it will solve the problem and make the world a better, more user friendly place!
Want to discuss design, totally disagree with me or have interest in collaborating? Send me a note or get in touch through social media!