By Ioanis Hristodoulou
Working towards a framework for design
This is Part 2 of our design framework In this post, we aim to introduce the Envato design framework and describe how we apply it.
But before we begin, our goal for defining and formalizing the way we work was so we could use it as a tool to help us work more closely and effectively with teams and stakeholders to create better and more meaningful products, by aiming to:
- Agree and align as a team as to how we work.
- Align with how other teams at Envato work including Product, Engineering and Marketing.
- Break the misconception that design is a “magical and mysterious black box” only accessible to the mysterious “creative” (not our favourite).
- Help people understand how to work with design and be more comfortable getting involved in design activities.
Considerations
Like most design functions, our team consists of people with a variety of roles and specialisations. These include UX & UI Designers, Content Strategists and UX Researchers. Regardless of individual role, we recognise that the typical process that each of us goes through shares similar characteristics. We also had to consider that outcomes are never the same. The work is often a mix of product and marketing which each have unique considerations.
This is the Envato design framework for a reason. It was designed to align with our company goals, mission, and the way we work as a company.
Introducing the framework
There are 2 key parts to the Envato Design framework: 1. the visualisation of a cycle to represent the iterative nature of software design and 2. It consists of four key phases with a central reflection step between each of the phases.
Understand → Reflect → Explore → Reflect → Refine → Reflect → Implement → Reflect → …
The four phases are typical of other design processes but the intermittent reflection stages provide our team with much needed “ah ha” moments.
Reflection
We realised that for our framework to be successful we needed to be able to reflect back on our progress to the rest of the business at regular intervals. We also noted that reflection as a step wasn’t formalised in our day-to-day processes. When we didn’t reflect, our design outcomes became isolated and closed which led to a greater probability that they would include waste.
In the pressure cooker climate of hard deadlines and product feature releases, as designers, we can be so delivery-focused that we forget to question if we are heading in the right direction. Deliberately pausing and reflecting at the end of each phase ensures that we don’t carry on along the wrong course. We will return to how reflection benefits our design framework in more detail once we’ve outlined each of the four phases that make up our framework.
Phase 1: Understand
Research, explore and define
At the start of any given project, we’re typically handed a little bit of background information about the problem at hand and a whole bunch of assumptions. The initial phase is all about getting deeper into the problem space and validating or disproving some of these assumptions. There is no point diving into outcomes if we don’t holistically understand the problem first.
Some of the methods used within this phase may include:
- Quantitative research from internal tools, such as Google Analytics and Tableau
- Qualitative research such as user surveys, interviews and competitor research
- A project kick off with the delivery team and key stakeholders to ensure all knowledge is on the table
By the end of this phase, we should know:
- What the problem is that we are trying to solve
- Who are we solving it for
- What success looks like
- What data we have to challenge our assumptions
- What data we need to gather
- Who the key stakeholders are
Phase 2: Explore
Conceptualise, experiment and learn
Now that we have a better understanding of the problem, we can start to explore the solution. At this point, it isn’t about coming up with the final outcome, it’s about identifying the breadth of possibilities. This may include sketching ideas on paper as well as testing assumptions through lean UX practices.
Some of the methods may include:
- Ideation workshops with delivery team and stakeholders
- Pen and paper sketching
- Design studio workshops
- Developing paper / lo-fi prototypes
- Early user testing prototypes and design
- A/B testing
- Lean UX tests
By the end of this phase, we would expect to know:
- Which ideas and assumptions are not valid
- Have a rough sense of the design direction we want to go in
Phase 3: Refine
Iterate, validate and refine
Hopefully by now we should know the direction we want to go in, and have an understanding of what works and what doesn’t. At this point, it is all about refining our solution. As we were work in an agile environment, we continually refine the designs while validating our thinking throughout each iteration.
Some of the methods may include:
- Mid/High level prototypes/design
- User testing design iterations
- Feedback workshops, stakeholder buy in
By the end of this phase, we should expect to know:
- The various scenarios we should design for
- The level of fidelity that designs need to be at for further validation
- Have high confidence that engineers can implement our proposed solutions
Phase 4: Implement
Review, release and test
At Envato, the design team isn’t finished with the work at the point that it has been completed to ‘pixel perfection’ and handed over to the development team. A big part of our work is to sit alongside the developers as they implement the design – there are many considerations that occur during development that could cause the outcome to shift, like unforeseen technical limitations or new scenarios identified. The job of the designer, at this stage, is to collaborate with the developer to come up with the best possible solution within any limitations.
Often developers have great design ideas too and they should always be considered. Finally, and most importantly, we want to make sure that our outcomes have the impact intended. That means measuring any post release data that can track solving the original problem.
Ultimately, we are in the problem solving space, and we want to make sure that the problem has been adequately resolved.
Some of the methods may include:
- Collaborate and pair with team
- Monitor key success metrics post release
- User testing on final the outcome
By the end of this phase, we would expect to know:
- Whether the outcome has been successful and why
- The next direction for this project
The importance of reflection
As you can see, there are plenty of actions to take during each phase. Sometimes these can be done quickly, while other times a project may take months to go through many rounds of the framework. Because of this, it’s critical that a reflection stage is included at the end of each phase.
Questions to explore during the reflection stage include:
- Are we aligning with the company values?
- Are we aligning with the company vision?
- Are we aligning with the company strategy?
- Are we solving the right problem?
- Will our solution deliver the right outcome?
This may seem straightforward at the start of a project, but can shift once the project begins. You may complete a phase and discover that the solution is misaligned with the company vision. At a critical juncture such as this, the stakeholders need to decide as a group whether to continue or pivot. Pivoting at the earliest possible stage means that you are always designing the right thing for the business and avoiding waste.
The flexibility to go forwards and backwards and repeat
Unlike other design processes, our framework is not linear. Phases can repeat or skip depending on the project. If you finish a phase and still don’t think your knowledge of the problem or potential outcome has increased, it might be worth repeating that phase once you’ve reflected back on where your gaps are.
And if this seems like a long process, it doesn’t have to be. A phase can be done in a half-day depending on the project, or a few weeks if you need to dig deeper. In this way, the process is adaptable to suit small and large projects alike.
Finally, as we work in an agile environment and are often iterating on the same problem, the framework might repeat itself many times throughout the lifecycle of a project. In this way, the framework can be infinite, while using reflection points as guiding lights for pivoting or pausing.
Where to now?
It’s been a huge journey for the design team to get to this stage. You can read more about how we got there Part 1: Designing the Envato design framework. But it’s not over yet. We need to make sure that the rest of the Envato business both understands and supports this framework and that it is aligned to the way they work too. We are not trying to make a dogmatic process that all other teams need to adhere to. Instead, we are trying to focus on how a great design driven framework can incorporate into an existing agile delivery approach, without ignoring the company’s goals and mission.
Because of this, the possibility of tweaking the framework over time is inevitable. Like every great design, we will continue to iterate on it, taking into consideration the way we work and how Envato evolves over time.
We would also love your thoughts on our framework! Does it make sense to you? Do you follow a design process? What would you change? What do you agree / disagree with?
The post Part 2: Introducing the Envato Design Framework appeared first on Envato.
envato.com coupon from Envato https://ift.tt/2wqd08g
envato.com coupon
Tidak ada komentar:
Posting Komentar