In our previous entries in the Project Blueprint series, we have taken a look at how a Team Lead, DevOps Engineer, and QA professional view their responsibilities and work throughout a single project.

Making a blueprint can be hard in software development since the factors change a lot depending on the project we work on. I want to share some of those factors we have found to improve ways of work, deliverables, quality, and user experience from the perspective of a designer. Let’s start from the very beginning.

Design Offering

No matter where the prospect of a new project comes from, designers will be part of the sales and estimation phase whenever we have recognized that it can benefit the project or requires some distinct design chops. We build trust and gain meaning straight from the beginning when designers can have an open discussion with a salesperson, another developer, an architect, a quality expert, or whoever is leading the discussion with a potential customer. We sit in the early meetings with customers as we poke them with a flurry of questions. That builds our understanding when we start thinking of the next part, estimating the work, and building a proposal for a full team*.

*at Zure, a full team means it has skilled individuals to deliver a well-designed solution with high-quality implementation, QA, and security.

Estimating design work

When we have received requirements and information from the customer in the form of business goals, technical goals, specifications, or research materials, we can create initial estimations. We estimate the amount and type of design work needed and how many designers with different skills are a good fit for the project. A fitting designer can be already experienced or one with the will to learn and contribute without prior context or specific design skills. That’s why we can pair designers to a project too if we have the capacity available! Give each other support, share the workload, and learn something new.

We lack details, what now?

When we are missing a lot of information and estimating the work becomes too uncertain with open-ended questions, we will propose a design and planning period. We build confidence with our customers to create the right things, in the right order, and make sure work scales for the future. Basically prioritizing design, implementation, QA, and the rest.

We can swiftly offer a 1-3 month pre-built yet customizable Discovery package where two of our designers (and other Zure roles when needed) facilitate workshops with stakeholders, research, and create a better understanding together of the actual requirements for a project. As a team, it’s not optimal to jump straight into implementation while being in utter darkness from all previous discussions, agreements, and lacking requirements. This will give us the initial “info package” to set more precise estimations and goals for a project. It even helps all the way to implementation kick-start as we have things in better order of importance and understand the context as a team!

“DISCOVERY” – By recognizing the importance of gaining a deeper understanding of user and business requirements from the start, we have developed a flexible Discovery package. This package not only enables us to effectively communicate our ideas to customers but also facilitates internal buy-in.

The design work

Projects are different in their size and dynamics where the context, goals, and people involved change their shape. I’ll try to talk about the work we do that is most common in today’s Zure projects.

In the early stage of implementation, the designer’s job is often to share all the learned knowledge with the whole team on the context, requirements, and needs of the business and users. At the beginning where development pipelines are set up and access rights are being summoned, we as designers tend to get our design groove on and set it to a high tempo:

• ✍️ PREPARE – With customers, we identify the most important matters to work on first and find key people to build on those matters. We set up our tools of trade (typically Figma and Miro) and agreed on ways of working with the team and customer. We prepare for any observations, research or workshops to be done.
• 🙏 COLLABORATE – In workshops, we further collect user and business information on what is needed to achieve. Dig deep into complex topics, clarify needs, write use cases, and understand as much as we can about the whole flow. As an outcome, we often create different flows, tables, diagrams, and other to organize a large group’s thoughts into something easy to make decisions on.
• 🧠 DESIGN – We specify the fine details as UI specifications, prototypes, wireframes, etc. Perhaps talk to QA already about how we document the UI to make testing and validating later easier.
• 🤸‍♀️ PRESENT – We visualize, explain, and articulate our design choices to everyone in the project and work very closely with developers to create the desired outcome together. One of the top traits for a designer is to be able to clearly show and tell your reasoning on how the user and the project benefits from your design decision without using too much over-the-top design lingo. Be believable.
• 🌟 VALIDATE – Constantly validate. Show and test your designs with your users and team. Ask for input, test your ideas, and filter all the feedback in to even better design decisions and design deliverables.
• 🔁 REPEAT – As always, we do things in iterative way and adjust our time and effort based on the overall needs of users, business, and implementation pace.

As we implement the agreed 1st version of the project, things change along the way. Pretty much always. Designers are at the best place to see the whole picture and adjust the amount of time and effort used on specific new needs or even downscale the feature scope if it is seen as beneficial for the whole project. We help scale the work with the customer and the team. Things start to move around in the prioritization list as we all learn more about what is important to users and business areas. Some things might prove too costly technically or otherwise. We adapt. Designs adapt. We scale the 1st version (Minimum Viable Experience, if you will) and understand which matters will be pushed to the 1.1 version instead.

User testing and validating

In the best scenarios, we have users who are able to dedicate time for testing and validating along the implementation rather than just having a very intense and short UAT (User acceptance testing) at the very end. I’ve had lovely projects where we have different users available and active throughout the project and I am able to validate on a weekly basis the direction we take. When there’s less time or knowledge of the business context on the customer side we can, with the help of QA experts, recommend and guide them towards the right things to look at and consider.

Some common topics when considering testing and validating our design or the implemented version:

• UI quality – usability patterns, layout coherency, UX heuristics, and all basic UI-related interactions are on an excellent level in general and as per brand style of the customer. Requires close work with our development team.
• Accessibility – requires to be implemented to validate. Make sure the targeted WCAG level is covered by the team. Do accessibility test runs with other team members?
• User experience – specifically for THIS project while leveraging the commonly known and verified human behavioral patterns. If the user is in an iron mine or an office space or if there are nested 40-view information architecture or just a single page, the true user experience can only be validated to be excellent if we go out there and find out all the user and user group specific factors.
• Business targets – we often create or modernize digital B2B tools that are critical to customers’ business. We absolutely want to recognize the valuable spots that can bring in more bucks. This can be just making users’ workflow faster and more efficient, or that they are served better and fresh data to make better decisions. If we did not define them in the sales or start of project phases, we might have a hard time with this one, so we have to make sure we do it at the beginning of the project.

Collecting feedback is important

Time to get real for a second. Some projects are budgeted so that there is not a lot of extra spacing for after-launch work. Too tight a budget reflects negatively on the importance of longevity with any software project. After the production launch, verifying that we built something that is lovely to use, performs well, and returns the investment we’ve made is super important. We as designers attempt to get buy-in for after-launch feedback collection in ways of surveys, observations, or whatever suits the customer organization. Feedback collection is not always baked straight into the project roadmap and it is a place of improvement for us all.

We have a lot of knowledge and tools for different monitoring and reporting ways to make sure all not just technically runs smoothly, but that the users also find that their work life becomes easier and enjoyable. This is something that I personally hope we improve in our future projects and is added to the design sales part too.

Wrap up

Thank you for joining me on this journey inside my head as a designer at Zure! Our intention is to create digital solutions that are not just technically smooth, but also significantly enhances the user’s work life. Designers spend much of their time asking questions and working with customer to define what the user and business goals are. All of our designers want to learn as much of the users’ world, no matter what amount or type of design work they have on a project. The ever-changing shape of design in consultation-based work can be challenging yet thrilling and definitely a balancing act between many different people involved in a project.