Tailored design thinking and process for at scale engagements.
A real world process about what has been my professional activity for the past year and a half.
You become a consultant once you get off your chair, jump out of your joggers and t-shirt into that sharp business casual outfit of yours. Or, if you’re Alberto into your ripped dark jeans and Yeezys.
Just like that you become client facing and all of a sudden you need to explain what is it that you do and why do you board your flight through the priority line hovering your gold member card but cut past business and first class straight to your economy class seat.
Is what comes out of your mouth to most people. But to those who are truly interested, while pouring a mug of coffee, you say that it starts with:
Before jumping into the kick off meeting it’s always a good idea to go online and familiarize yourself with the business and history.
In most cases, documentation detailing the need behind the product is available beforehand in some form or another.
If it’s a pre-existing app, regardless if it needs a redesign or just a new version, some screenshots, documents and or a video demoing the functionality should be provided by the client. If these are missing a simple request must be made to make them available.
Having gathered all the necessary information you are now ready and prepared for a proper discussion.
First thing that will happen is the introductory round. This is key because you will be able to extract all the actors and their roles.
It’s very important at this stage to state who you are, what is your expertise and how you can help the client achieve his goals. Of equal importance is extracting all the missing info, concerns and all things unclear to you. Walking out of this call should be made with no assumptions or unclear facts.
Regardless if you travel to the client or vice-versa, your team should be composed of UI Designer, UX Designer (also the main facilitator), Business Analyst and a Dev Lead.
The client’s team should always include the product owners and final users, if possible.
Before starting with the workshop begin with a quick round of introductions. No longer than 10 minutes. This way you will have a clear image of who’s who.
After this suggest to the product owner to detail a bit the business needs. There are times when clients come already prepared with presentations detailing this.
Just before starting ask everyone to write on a post-it note their expectations from the workshop. And at the end ask everybody if their expectation has been met. Continue explaining how the workshop will function with the As-Is and To-Be processes.
A very important note to make to everybody in the room is that titles no longer apply. It should not matter if it’s a CEO or a front-end developer. All are equal in ideating and expressing themselves out loud.
Now is the part where we jump straight to the AS-IS step of the DT workshop. Explain to everybody that this is an interactive process.
Well this is where the “tailored” part of the title comes in. In this kind of half a day workshops your personas and empathy maps shook hands with you 10 minutes ago. Your end users.
Every thought in that room has been written down in the BA’s notes. So your only worry should be extracting those wow ideas.
Post a row of sticky notes on a wall representing the steps of a user’s as-is workflow.
Explain that beneath each step, you will create a column of color-coded sticky notes representing questions and comments relating to that step. For comments, consider the technologies and context. Once questions are answered, post comments over them.
Identify pain points for users and opportunities to improve the design.
Use a second sticky note color to identify opportunities for the design. Each pain point should have a corresponding opportunity, though some opportunities might not relate to pain points — for example those that respond to market trends or anticipate future pain points.
Encourage everybody participating to think out loud, add pain points, opportunities and questions.
Guide this process from the UX point of view to curate what makes sense from the product’s perspective.
If an AS-IS process does not exist, a “day in a life” should be done. In the concept of the product, the “day in a life” concept explains what a typical day for a user looks like.
This scenario lets teams rapidly ideate on future workflows.
Post a row of sticky notes on a wall representing the steps of a user’s to-be workflow. Beneath each step, create a column of color-coded sticky notes representing questions, comments, and ideas relating to that step. Most ideas can be imported from the opportunities generated in the AS-IS. Once questions are answered, post comments over them. Use this artifact as a springboard for ideation on particular steps. Each to-be scenario should be documented in the Release.
Once this step is done quick rough sketches on extracted ideas could be done to depict how the product might look like.
Note: This is not a necessary step. And should be done only if there’s a very clear image of the product.
With all the gathered information from the workshop you are now safe to lock yourself into a meeting room alongside your team and disseminate everything. Make use of your whiteboards and start drawing each main screen and actions.
This way you will have a clear idea on the whole UX flow. Based on this you can create a UX map that you can safely send the client to validate.
The UX map is a must before starting designing the wireframes. It’s the first thing that you will agree on with the client. Make sure each page is displayed as a category featuring all the features and actions.
If the product has multiple users use the horizontal plane to show the path for each role.
Next logical step would be to jump into wireframing, but in an at scale environment efficacy will come from what we came to call PoC advanced wireframing. Which means designing the main or key screens (5–7) and be ready to quickly test main functionality. This means that everything else must be assumed. For instance: the user is already logged in and has gone through the registration process.
With the key screens in place we can quickly create an interactive prototype. Invision has proven to be the quickest way to create and deploy one.
Having an interactive prototype can save a lot of back and forth emails or design reviews. The client will have an easier time understanding how everything works if he tests it himself.
Once you have these key screens validated it means that direction is approved and you can move on to design the rest of the screens.
This step is written by Alberto, my partner in crime. His visual designs are next level. Keep in mind that the process differs based on every designers routine, experience and level of creativity.
Take your time for this step as this is what’ll shape an idea in your mind, take a look for inspiration through different platforms like Dribbble, Behance, Abduzeedo or Competition.
Don’t be afraid to experiment at this stage, draw multiple versions of the UI, don’t spend time with the details, you’re gonna have enough time to refine later on. Try to find the right visual hierarchy, color palette, typography and spacing; The sky is the limit. By the way, don’t go too far with the number of screens, focus on the main four or five.
Let your design bake for a night and the next morning you’ll be amazed about what you crafted a day before. It might be the worst design you ever made or the most amazing. Most cases it’ll probably be the worst. But you’ll have a fresh view on things to transform it into what you wanted it to be in the first place.
Let’s close the playground, you had enough time for the that. Start designing the interface properly, good enough to share with some real human beings. You are backed up by strong wireframes, a few days of exploring and research; stop crying.
Share a few screens (4–5) with everybody (PM’s, BA’s, designers, devs) involved in the project, start asking friendly questions like “Hey mate, what’s your impression about this piece of artwork?”. Get prepared for answers like: “It’s too red” “It’s too blue” or “I don’t like it”. Write down all the feedback you get. Ask follow up questions like “which part is red, blue or what is it that you don’t like; everything or just a piece. Most people say “I don’t like it” but don’t necessarily mean the whole thing.
Once you get back to your desk, recap and split all the feedback you’ve got in the previous step, accommodate all the changes if needed and reiterate the process until you feel confident about what you crafted so far. Be mindful of the feedback you get, keep in mind the business needs.
This is the most important part out of all the process. Because here actual users will give you priceless feedback and new ideas. Users think differently, and you’ll be surprised how often that obvious thing isn’t.
This is a repeating process. You can use it whenever you need end-user feedback. It can be done as soon as you have a prototype or even test with hand drawn sketches. Use as needed.
Each session should’t take longer than 30 minutes.
When testing set the stage as follows:
Based on the outcome of the user tests, this step will keep the timeline intact and your decisions covered.
It is at this step that the business requirements are set into place and discussed.
A few meetings should be held together with the BA, Client and Dev Lead to lock everything in. This way everything that was left out or missed can come to light and addressed.
Except it isn’t.
You accomplished all the steps, the design is ready. You have the product and now you need the distribution. If “Narcos” thought anything is how to get your product to the users. You still have assets to share with the developers. No matter if you used Sketch, Figma or Photoshop: Zeplin will be your friend. If you are old school, manually exporting assets might be your thing. We don’t judge.
Estimations are not deadlines. Always prepare for things to take less time or more.
For the various projects I’ve applied this to, I have created a time guideline for each step.
In at scale engagements your role will have you heavily involved for about two weeks. You will stop being key right after the business requirements are set in. You have already set the tone, have done the tests and can move on to the next engagement.
The rest of the screens will be in the safe hands of your UX/UI team.You will only need to keep an eye on how things evolve and step in only if it’s really important.
If you liked this article, you can also follow us on instagram:
Adrian | Alberto
Tailored design thinking and process for at scale engagements.
Research & References of Tailored design thinking and process for at scale engagements.|A&C Accounting And Tax Services
Source
0 Comments