How

A very general guide to my ways of working😄

01.

Discovery

The goal of untangling customer problems in the discovery phase is to get insight into who, what and why. But as I see it, there are two levels of problems: The ones your organisation are aware of and are wanting to solve: May it be user, business or technical. Then there is another entirely different level which the company may not know about at all. Often derived from user needs that are unmet and expressed in terms of a problem. But a problem may have many different causes, as a need has many different ways of expressing itself. As a designer it is my job to understand those needs from various user groups, and create an experience with the product where they are better fulfilled. The empathetic viewpoint into someone elses life I belive is achieved through listening to the people who use the product qualitatively, compare it to qualitative data and make hypothesises based on the insights. Those hypothesises will serve as the foundation for the continious product development.


Methods:

Workshops, surveys, semi-structured interviews, focus groups, data aggregation, insight analysis


Tools:

ClikView, Grafana, Capturi, Looker Studio, Google Analytics, FigJam




Problem to solve

Synthesising user insights into user journeys and comprehensive data visuals is a way to present various user needs in the discovery process. I actually tend to avoid personas, as I belive they may cause bias. Rather, there may be a target group or a achetype that I'd present.

Having the stakeholder team involved in these steps and engaged in the research is key to reaching alingment and a shared understanding 💡.

Running workshops, interviews, observation studies, and listen-ins are a crucial part in that process.


02.

Ideation

Next step would be to bring insights to ideas of how we might help those underlying needs. I typically run workshops in FigJam or with post-its with relevant stakeholders if there is a larget bet, and with the team for smaller intiatives.



Methods:

Brainstorming, dot-voting, oportunity solution tree


Tools:

FigJam, post-its, whiteboard



Sketch

Once the ideation has been carried out, what I'd typically do is start sketching out wireframes for how the idea might work. If we're doing a design sprint, everyone in the group participates.

When I have a rough visual, I'll share it with the team who was part of the ideation for initial feedback. I might also verify it with the target users, depending on the size of the project.

Refine

As the experience is refined, the design will start to get more and more test-worthy. The way I see it is that the concept should get more and more "pixel perfect" with every feedback loop, keeping people involved and engaged throughout the journey. For a small scope this might be done within a day, for a large intiative this might take weeks.

A rule of thumb is that design is never done, as customer problems are endless and ever changing. At some point though the design will be "good enough for now, safe enough to try" for a MVP. Demoing the progress to everyone with stake will help determine when this point has been reached and what the MVP scope should entail.


03.

Verify

Give the actual users a chance to provide feedback on the product you're building for them and if it fulfills their needs. It perhaps goes without saying that it's more expensive to change the design after you've built it in code, than in a prototype 😊




Methods:

Concept testing, Usability testing, Surveys, Internal presentations


Tools:

Figma, Useberry, Invision



Concept & usability test

Every initiative has a different scope, but a rule of thumb is to test at least with 5-10 users per initiative. Within a smaller company it might be hard to get the buy-in for this to start, but with time my experience is that it proves its value if you share the insights thouroughtly and invite stakeholders to participate. The more mature organisation, the better they typically are at makting this part of the way of working in my experience.

I typically prepare the tests with a set of research questions based on our hypothesis, and eventually turn them into interview quiestions. Depending on the outcome of the tests, I might tweak the design for another iteration.

04.

Delivery

The product team divides the scope of development with refinement, sprint planning and story mapping, ensuring we build it with the most essential functionality first - test - and continue. In this way we can learn as we go. As we get to production, we aim to release a first version which we can get feedback on for iteration.



Methods:

Story mapping, Sprint planning, Refinement, Design Guidelines, Iteration plan.


Tools:

Figma, Jira, Test-server, Grafana, Google Analytics



Design delivery

I typically present the design in scenario flows in Figma, allowing the developers and other stakeholders to follow the customer through a happy path, error path etc. There might be a need for a protoype for interactivity, and some new guidelines in our design system if we build new components.

Following up on the release through closely monitoring KPIs, customer feedback and interactions helps us determine whether we've successfully solved the problem in a valuable way.