Selasa, 28 Agustus 2018
Kamis, 23 Agustus 2018
Part 2: Introducing the Envato Design Framework - envato.com coupon
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
Part 1: Designing The Envato Design Framework - envato.com coupon
By Jess Ng
A distributed team with a common goal
Here at Envato, the Design team consists of Designers, Content Strategists and Researchers, all embedded in different product teams under the same Envato brand. As the company has grown, the Design Team has also expanded quickly, with new people regularly joining the team as new roles are created.
As a team, we aim to deliver a consistent experience across all of our products, while also providing space for each team to innovate. Over time, however, it’s become increasingly difficult for us to follow and keep track of each other’s work, and ultimately come together as a team.
We set out to tackle this challenge by designing a collaborative and unified approach that could be shared by the whole team. In this post, we focus on the method we used to arrive at the current Envato design framework rather than describing the framework itself.
Collaborative process mapping
To move towards a shared future, we started out by getting the whole team together to talk about how we work. We had an honest and transparent discussion about the pain points we faced in the various areas we worked in and the teams we worked in, as well as the things we wanted to change.
Once we had a clear idea of each individual’s working style, we paired up to ideate around an ideal way that design work could be done at Envato. To help us visualise our thinking, we applied a standard process map format, based on commonly understood definitions and symbols.
A typical process was mapped out on a whiteboard, with discussion at every step.
Some of our discussion points included:
- What should happen in each phase?
- What’s the sequence of the steps? (e.g. should the team kick-off come before or after establishing a problem or goal?)
- How do we make sure we’re solving the right problem / implementing the right solution?
At the end of the session, we had visibility on how each of the different teams and individuals worked, as well as a high level idea of where we thought we wanted to be.
Gathering feedback and iterating
Over the next couple of months, different designers would pair up to expand on the high level process with more detail in each step. We used our daily feedback sessions to gather ideas and continue iterating on the concepts.
A turning point
A few months down the track, as the process map was really coming together, we found ourselves looking at what we’d come up with and feeling a sense of accomplishment. Then came our design offsite, a major checkpoint in our journey, where we reviewed the process and identified some major flaws with the map.
It turned out that we’d been too focused on mapping out the events that happen in a generic design process, viewed from a single perspective of applying it to a ‘typical’ project. One of our designers pointed out that the process felt too linear and didn’t reflect her day-to-day work.
The process we’d designed lacked the flexibility and validation checkpoints to represent some of our real world scenarios. For example, a smaller design task such as a creating a Marketing landing page wouldn’t require the same amount of resource or scrutiny as a large project or initiative.
Back to the drawing board
After taking on board what we had learnt from the offsite, we knew that we needed to move away from the process map. As a team, we collaborated further and agreed that instead of a linear flow, taking a circular approach would make a lot more sense.
Moving away from the flow chart
We also had another major discovery, which as around putting ‘Reflection’ at the heart of our process. The design team reflects and gathers feedback often – from each other, as well as the rest of the company. It felt right to have reflection at the centre point of our approach to solving problems.
Some ideas sketched out by the team
Iterating towards the right solution
Just as we would tackle any other design problem, we took an iterative approach to designing the process, moving from low- to high-fidelity ways of visualising our process.
Fast forward to the present day
We are now happy that the representation of the process clearly explains how we work and by sharing it will encourage a consistent approach to projects and more cross-team collaboration, while also allowing for flexibility, nuances, and tight deadlines! We also decided at this point that the word process did not convey a sense of flexibility so decided that framework was a more accurate description of how we worked.
What started out as a design task to explain our way of working has now become a larger conversation that involves the whole company. The conversation has only just begun, and we’ve got a lot more work to do. Watch this space.
If you’d like to learn more about how the Envato design framework works, take a look at Part 2: Introducing the Envato Design Framework.
The post Part 1: Designing The Envato Design Framework appeared first on Envato.
envato.com coupon from Envato https://ift.tt/2PAn8nA
envato.com coupon