Why creating valid user personas is Vital in Software Development

personas
Attrecto team

Attrecto team

Why creating valid user personas is Vital in Software Development

You’ve probably had some experience of user-testing or launching software that’s failed spectacularly. What may seem like an intuitive UX and useful functionality to you could fall apart in seconds when an actual user sees and uses your software for the first time.

But how can you anticipate how your users will think about and use your software before you reach the prototyping and testing phase?

User personas are the answer. By keeping the focus on the user experience during the design process, you ensure that every member of the development team is on the same page and working towards the same goals.

Download your free guide for development process in UX driven projects 

 

What is a User Persona?

User personas are an integral part of agile development and user-centered design. They enable the development team to think about the needs of the actual end users of their product rather than focusing on a set of features without considering if they’re actually wanted and needed.

Creating user personas for your app development company puts a human face on your users, making it easier to create software that suits their needs. Rather than trying to think about how to design for your users as a generic group, you can think about how you can make your app easier for “Bob” to use, or what features will be useful for “Sarah”.

source: Dribble.com

 

How Creating User Stories Helps the Software Design Process

Your user stories build on your user personas to describe what each user wants from the product so it fulfills their needs.

These user requirements become a list of features that form the basics of your app design and development. Each user story is a short sentence focusing on one aspect of functionality and usually has a “who + what + why” structure. For example: “Anna wants to organize her time so she can be more productive”.

source: Knowledge TRAIN

 

How to Create User Personas and Stories

As a mobile- and web app development company, we just cannot emphasize this enough: Start by researching your market – the end users who will actually be using your software or app. If there’s an app with similar functionality already out there, look at who is using it and what they’re saying in feedback on app stores.

If you’re developing something completely new, interviews with real people are the best way to gather this kind of intelligence. Concentrate on their needs and challenges rather than your proposed solution. If you work for a web development company, information from analytics and social media is useful too.

This research will give you a good basis for creating user personas based on real people. Some information you might want to include in your personas include:

      • Name

      • Background (career, educational experience, interests etc.)

      • Job title and responsibilities

      • Knowledge level (about the concept of the app)

      • Context (what are they using the app for?)

      • Environment (where are they using it? E.g. at work or at home)

      • Pain points and challenges

      • Goals and Motivations (what do they want to achieve by using the app?)

Based on our decade of experience with mobile apps, three to five personas are sufficient for most apps and software projects. Once your team is familiar with the personas, you can create user stories based on your earlier research.

 

The Risks of Not Using Personas

Skipping the important step of creating user personas and stories is a huge risk. Without a clear picture in your mind of who you’re designing and developing for, there is a significant chance you’ll end up creating something that’s not suitable for your users.

Even worse, you could create an app that might work well for you but doesn’t really meet the needs of anyone else.

Using personas and user stories helps to position your product better in the marketplace and ensures you’re creating software that your audience wants and needs.

Download your free guide for development process in UX driven projects

Share this post

Biggest UX flops in tech

15-useless-product-designs11
Attrecto team

Attrecto team

Biggest UX flops in tech

The Biggest UX Fails in Tech History 

Even great teams fail. 

Even strong brands miss the mark. 

When a UX design goes wrong, everyone loses: the brand, the business, your reputation, your revenues, and, most of all, your users. 

You know, the people keeping the lights on?

In 2018, Icons8 lost 47% of their users thanks to a badly informed UI/UX design.

Walmart lost $1.85 million because of a failure to examine user experience surveys. This data is central to validating the central hypothesis of a UX design. 

And it’s not confined to companies — in 2011, the UK government was forced to scrap a £12 billion project for a patient records management system because of repeated issues. The web development company and teams consistently failed to meet targets on usage, functionality, and benefits. 

The Health Secretary Andrew Lansley had this to say about the failure: 

“The program let down the National Health Service (NHS) and wasted taxpayers’ money by imposing a top-down IT system on the local NHS, which didn’t fit their needs.”

UX fails come in all shapes and sizes because UX is not just about how it looks. UX is just as much about how it works. And it’s about the actual process behind the design. 

As you’ll see from these major fails (and one truly frustrating flaw that we still encounter today), it’s not just that the timing wasn’t right — the entire process matters, from the details of when to launch and how to meet customer expectations, to whether users have actually tested the prototype.team.

Download your free guide for development process in UX driven projects 

Google Wave (2009)

In 2009, Google was hot on the need for a new kind of project management with collaboration at its heart. 

But the design was not so hot.

Let’s say that this was the first wave of its attempt to improve collaboration across teams. The result not only bombed, it totally languished. 

This is what the first iteration looked like. 

Never mind the dated design; the problem was that Google failed to “Keep It Simple Stupid.” The platform was much too busy and felt complex — too complex for an individual to even want to try and navigate. 

This unnecessary complexity popped up again in the fact that Google was focusing on too many projects at once. It decided to launch Google Buzz before Google Wave was fully integrated. 

Coupled with its limited user adoption strategy, the project gained zero traction and was an unmitigated disaster. 

Live and learn, right?

Windows 8 (2012)

Three years later, the Windows 8 debacle proved to mobile development companies the power and importance of continuity and consistency. 

One of the prime principles of UI/UX design is to keep a user’s expectations alive. What a user expects, a user should receive — not least because, through your previous iterations, you’ve likely spent time and money educating your users about how your interface works. 

When Microsoft first released Windows 8, it was a clear shot at Apple who was quickly eating up market share. 

First big mistake: Trying to ape another platform’s functionality. 

From here, things got worse. Because Microsoft abandoned their initial interfaces entirely, users were completely unable to find the most basic functions. 

Navigation was a nightmare and these major changes came at the expense of their users’ expectations. 

Anyone using a Windows PC knows that the desktop and the Start menu are the main points from which to operate tasks and access the file system. 

Instead, Windows 8 users were subjected to an OS that was trying to fulfill the duty of two: It was intended to be both click and touch-friendly

The problem was that, in trying to accomplish both, it did neither well. 

First, Windows 8 removed the Start menu and the default Desktop screen, completely pulling the rug out from under users who, over years of loyal and expected use, now had ingrained expectations. 

After the ensuing chaos and uproar, the customer experience was completely diluted. Sure, Microsoft re-introduced the Start button in version 8.1 — but not before many chose to downgrade to Windows 7.

Now, does this mean that interfaces shouldn’t evolve or that visual identity shouldn’t keep up with modern design standards? No. Certainly not. 

But that’s why changes in UI/UX design need to…

  • Be incremental
  • Keep the main functionality alive, even if the look and feel changes
  • Be based on the results of tangible user testing 

The USB

It’s not scientifically proven or anything but, about 50% of the time, USBs are inserted incorrectly. The user sighs, frustrated, then pops it in again, fingers crossed, hoping and praying to the powers that be that this time, it’ll actually stay in. 

We all know how this story ends. 

The USB is a very common tool and we still rely on USB connected devices every single day. 

To this day, we’re never quite sure whether we’ve inserted it right.

This serious design flaw has a pretty simple fix. To understand it, just look to its predecessor: the plug. Sockets and outlets have their own configurations that are visible to the user, neatly indicating how plugs should be inserted. 

Or you could completely eliminate the USB connector once and for all and opt for a design that doesn’t depend on the orientation of the plug. 

Apparently, designers for Apple and Android phones agree: the latter introduced the lightning connector, while Android phones have developed the C-type USB. 

Source: Dignited

Conclusion

UI/UX’s power is the fact that anything, given enough time and thought, is ultimately changeable. 

Sometimes, all it takes is for UX designers to put themselves in their users’ shoes and look at it from their perspective. It’s why the stages of design — such as prototyping or running sprints — is so crucial to the process of good design. 

Avoiding pitfalls is a collaborative process and it calls for iteration. This iteration shouldn’t be avoided. But there is definitely a way to do prototyping right — prototyping for pros. 

Learn more about how to rapidly prototype for software development and bring a sense of business value to your design team.

Download your free guide for development process in UX driven projects

Share this post

Three Keys to Digital Growth You Need to Know About

growth-strategy
Attrecto team

Attrecto team

Three Keys to Digital Growth You Need to Know About

There’s a fire in the building and you can only save two out of these three things: User experience/customer experience, business model innovation, or the technology-driven product/service underlying your whole raison d’etre. 

Which do you save?

(Note: This is a trick question).

Do you…

  • Keep the “good” business model and powerful tech but throw away CX/UX?
  • Harness an effective business model and prioritize UX/CX but forego tech?
  • Juggle UX/CX in tandem with tech but let the business model go?

If you guessed Secret Option Number 4, “All three,” you’d be right. 

You might be wondering: 

How the heck are we supposed to balance all three? 

Luckily, there’s an intrinsic relationship between the right business model, the actual tech product and the UX/CX design component that encourages and supports users in their adoption. 

An alignment of all three is a continuous but seamless process — if you’re making all three an equal priority. 

Lose a grip on just one and you might experience the following: 

  • Good business model and innovative tech/app product, but bad CX/UX? That means a lower number of users with no competitive edge.
  • Good business model and effective CX/UX, with poor underlying technology? The result is low efficiency with an unsustainable operation (ex. outdated or slow-progressing, cross-platform solutions).
  • Streamlined UX/CX and powerful technology, with a misaligned business model? You’ll miss out on a tangible value prop, a tech demo without any real value or purpose for customers. This means, once the novelty has worn off and the honeymoon period is over, user acquisition will decline and the company won’t be making any money 

Business success comes from a masterfully planned business model built on and responsive to real, flesh-and-blood, felt and experienced problems of your customers. 

Yes, you want to look for these problems — and then you want to respond to these problems with your web app product or solution. Your value proposition articulates this to your customers while the technology and overall CX/UX subtly convinces and converts them as committed users. 

So how do you balance all three? It’s not exactly “simple” but it doesn’t have to be complicated either. Often, digitization is the first step to transformation. 

Let’s take a look at three specific steps that will grow these transformative activities. 

1) Start With a Solid Value Prop and Business Model

If you don’t have a value prop, you don’t have a product. But if you don’t have a value prop, you can’t make a promise to your users. 

Your app’s value prop is the first and only thing that determines when your users will even find a use for what you’re selling — or if they’ll end up hitting the BACK button. That’s the customer-facing side. For you, articulating and outlining the value prop is an ongoing endeavor because this will be the main thing you’re going to test. 

This promise is not a static, set-it-and-forget-it statement either — your value prop needs validation on the market, via customer/user interviews and surveys, as well as measuring through user tests. 

Source: Uber

Uber’s value prop is a two-fold message and functionality. It clearly conveys to the two key pockets of users — passengers and drivers — what they stand to gain and, implicitly, how they can expect the app to work, based on this promise. 

From apassenger’s point of view, Uber delivers on the following: 

  • No need to wait for a taxi for long times
  • Free rides on certain occasions and discounts from time to time
  • Prices lesser than the normal taxi fares
  • Uber’s tagline says — “Your personal driver”, promising customers that they can not only travel in style but also on their own time
  • Fixed prices for common places like the airport, etc.

From the driver point of view, they stand to gain from: 

  • An additional source of income
  • Flexible working hours: Can work part-time, according to their own schedules
  • Easy (and dependable) payment procedure
  • Those who love to drive can earn money while pursuing their hobby
  • Uber pays drivers to be online, even if they don’t get any requests (i.e. “guaranteed”/base income)

And, then, Uber app developers and designers deliver on this promise through an app that functions at scale. Being able to create profit at scale is what helps determine the cost structures, margins, and even processes that will be required moving forward. 

Source: SCM World

In the case of Uber, identifying and then clearly articulating its two main user/customer bases and their promise to each through one app helps them make decisions on:

  • Key resources or assets that will be required to deliver on this value prop (people, tech, channels, etc.)
  • Key processes,which are the operational and managerial requirements needed to deliver this value in a consistent and scalable way (UX/CX, testing, development, iteration, sales, marketing, etc.)

2) Constantly Test and Refine Your CX/UX

Your value prop is connected to your business model, which, in turn, gives you partial answers for some key business decisions. 

But what about decision-making when it comes to the production and development of your app?

The second step focuses on the app’s process and will call on you to put yourself in your users’ shoes. Good thing you’ve already figured out who your main customers are, right?

To determine how easy, enjoyable and effective your built app is for your customers, you’ll need to define a clear and logical sequence of events that take your customer from “problem-aware” ( in this case, I need to find a ride and fast!”) to solution-use (“I have a ride-sharing app that I can access to cure this need!”)

UX/CX is not just a novelty or all about fancy screen transitions. 

It’s a measurement of how useful or effective your app or solution truly is in guiding the user toward their end goal. The question is if they’ll arrive at that goal easily or if the journey will be confusing, infuriating, counter-intuitive, clunky, or just plain frustrating?

The good news, as you can see, is that while there are many ways to go wrong, there is only one way to make it right. And that’s to constantly test and refine your app’s features, processes, and offerings, based on real users interacting with and using the app. 

Once you’ve gathered actionable data from user tests, customer surveys and interviews, you’ll need to translate this data into design and development imperatives ready to be prototyped. 

During the prototyping process, you’re going to be testing different layouts, solutions, and flows that respond to these customer use data points.   

Source: Uber Design on Medium

In the case of Uber, there are clearly themed screens that align with the goal for each step in the process:

  1. Requesting a cab for an address
  2. Searching and matching the passenger with a driver
  3. The arrival of the driver and the distance from the passenger
  4. Ride in progress…
  5. Payment & rating at the end of the ride

Source: Uber Design on Medium

All of these are combined with a fleshed out, well-refined UI/UX, which eliminates a lot of friction points in user acquisition and retention. 

3) Build a Powerful Base Product Using Innovative Tech as Both a Resource and a Driver

Okay, so you’ve got your profit formula, which is your value prop and aligned business model. 

Then, as a second step, you have the key processes, which are your customer and user experience design, iterations, and tests. 

Now, what about your key resource?

The underlying tech you use is the key resource or asset you’ll employ to drive digitization and successful digital growth forward. So, the technology should be both innovative and sophisticated.

Source: Uber Engineering

Uber’s engineering and development department, for example, had a very clear and succinct, actionable mission: 

“Uber’s mission is transportation as reliable as running water, everywhere, for everyone. To make that possible, we create and work with complex data. Then we bundle it up neatly as a platform that enables drivers to get business and riders to get around.” 

— Uber Tech Stack, Part One

Technology gives you an edge over the competition because it’s the tracks on which customer experience (UX/CX) runs its train. 

It’s the initially (seemingly) expensive investment that brings you long-term ROI because of how much hassle it saves and how successfully it onboards and retains your customers right from their first interaction. 

And you must deliberately craft a tech stack that responds to and serves this goal of digital growth. Uber’s engineering team certainly understands the power of this: 

Source: Uber Engineering on YouTube

As an app development company, we’ve seen that solid, native development right at the beginning is a business’s vote of confidence in its own long-term viability.

Plan to be around for decades to come? Then plan for growth. Plan for a huge amount of users. This doesn’t mean getting extremely fancy or implementing resource-sucking features your user doesn’t need. 

By all means, keep it simple. But prioritize these “simple” tasks by allowing your app’s development to perform them consistently, reliably, and excellently. 

The added bonus? When you do inevitably reach the envisioned number of users, you won’t have to rewrite the whole solution to handle a larger load. You’ll be ready for it.

“Uber’s maps teams prioritize the datasets, algorithms, and tooling around map data, display, routing, and systems for collecting and recommending addresses and locations.”

— Uber Tech Stack, Part One

Source: Uber Engineering

The Venn diagram we saw before, between internal and external impact, affects many interconnected decisions. As you can see, something such as maps, on the backend, requires the use of a powerful and aligned tech stack which is able to handle the task’s requirements. 

In this case, the Uber Engineering team chose a primarily Java-based stack. 

And don’t take for granted the fact that backend and user-facing activities need to align. What looks to developers and designers as data in the backend:

Source: Uber Engineering

…can (and should!), to users, easily translate into an experience like this:

Source: Uber Design on Medium

Conclusion

It’s time to look at growth in an entirely different way. Instead of a set of disconnected practices, the keys to digital growth are ongoing in nature. Because of increasing integration and interconnection, decisions in one aspect — the business model, for example — necessarily affect the level of technology innovations demanded or the development style used. 

The “bad” news: You can’t prioritize one over the other and expect to reach either business success or experience digital growth.

The good news: Any gains you make in one will naturally spread to and affect the others. 

Download your free guide for development process in UX driven projects

Download your free guide for development process in UX driven projects

Share this post

Prototyping for Pros — How to Rapidly Prototype for Software Development

ux-788002_960_720
Attrecto team

Attrecto team

Prototyping for Pros — How to Rapidly Prototype for Software Development

You usually don’t have to preach the perks of prototyping to designers — they’re in the know. It’s their process, their everyday expectation:

Have project, will prototype, goes their mantra.

But what about software development? 

According to CapGemini, prototyping for software can bring on 4 distinct advantages for teams looking for:

  • Clarity: using “throw-away prototyping” to get requirements right
  • Iterative thinking: using “evolutionary prototyping” to think and build in an iterative and progressive manner
  • Getting the customer involved early on: using “customer value prototyping” to focus on and discover a customer’s needs or expectations of the software solution
  • Concept visualization: using “rapid design and visualization” to communicate and visualize the projects to clients/stakeholders 

Why does this matter? For an app development company looking to stay competitive, there’s a distinct advantage to adopting a user-centric point of view.

Because so many app development teams and companies already operate according to agile methodology, often working in a scrum environment, prototyping can support the need for an ongoing form of customer and user feedback in development.  

Source: The State of Software Development 2018

So what does software prototyping look like? And what does a web development company stand to gain when harnessing rapid prototyping? 

Let’s take a look.

What is a Prototype?

Prototypes are…

“an initial or preliminary version from which other forms are developed. This provides you with insight into the functionality of your design and any changes needed in order to make your work a pleasure to use.” — Daniel Bramhall, “The importance of prototyping your designs

Prototypes can be as simple as sketches, drawings, and drafts, or more physical and complex like models, sculptures, and replicas. 

The idea behind a prototype is two-fold: 

  • To provide a simulation or a sample version that can also act as a convenient starting point
  • To use the incoming observed and measured data to test out the product from this sample and gain new ideas on what’s working and what needs to be improved upon

The whole point of a prototype, then, is to both plan for and precipitate change. 

Software development, as a discipline and as an activity, knows all about change. And this makes prototyping especially useful in the beginning stages of information gathering, requirements, and estimations. 

Source: Unsplash

Download your free guide for development process in UX driven projects

Prototyping is essential and inevitable

Here, we’re talking about prototyping the code that runs the show and/or the features that will be included.

Within software development, prototyping holds very concrete and distinct advantages. 

  • It can help resolve issues of usability by connecting the user to the software at an earlier stage in agile or iterative development
  • Building out a prototype before can reveal areas that need improvement or features that must be thought through more carefully
  • Real users can interact and use the final version, allowing developers to track whether there is enough simplicity and ease or if the code is too buggy, clunky or inefficient
  • In the beginning, a “rough” or “lo-fi” prototype can help elicit requirement as well as validate requirements your team might have forecasted
  • Prototyped programs can help transmit intent not just for the user but to the development and design team; moving from concept to visual model engages a different level of understanding and creativity
  • It can be seen as an essential risk reduction activity, especially in cases of the accuracy of estimations and the anticipation of the scope change requests down the road

Source: “Prototyping in a scrum environment“, CapGemini, Slideshare

Keep in mind that, besides the types of prototypes you can create, based on stages of development, there are also various modes of detail. 

“Lo-fi” prototypes are much less detailed, high-level, conceptual and simplistic. As a result, these designs are:

  • not entirely definite
  • used when the focus is on scenarios of use and user flows
  • intended to clarify the thinking process without too much clutter

Compare this with “hi-fi” prototypes, which are much more detailed and closer to the end model/concept, as well as:

  • used when you need to convince stakeholders who are looking for an investment from a VC, for example
  • used when the designs are nearly done
  • chosen if you’re only iterating or adjusting for functionality/features

4 ways prototyping helps you go pro

Prototyping, especially within the context of agile methodologies, is a stage by stage process. As we saw previously with the Cone of Uncertainty, the phases of a software project’s evolution, especially in the beginning planning stages, can be shrunk significantly. In lieu of this “quick” and “lean” start, development is spread out throughout the course of its growth, from the first conception to “final” iteration. 

Prototyping is highly conducive to this “iterative” nature as prototypes can be improved upon. Some formats of prototyping, such as wireframes, as we’ll soon see, are more flexible and relevant to the process of prototyping. 

It also helps hammer out four key elements of production and development, including:

  • Interaction: How does the user interact with the software? Take note of any expectations that were not met or, better still, completely disrupted. Was there enough guidance? Were the functions too difficult to discern?
  • Identifying the kind of prototyping required: Does the project call for “throwaway prototyping” (aka “rapid prototyping”), or will it be more successful with evolutionary prototyping wherein a robust prototype is built in a very structured manner and then consistently refined from there
  • Look and feel: Depending on which technique you’re using and whether you’re casting a lo-fi or hi-fi prototype, you can gain an insight into what that user experience should look like and feel like, using code; this is usually the moment designers and developers must work together
  • Potential problem spots: After getting the user involved and observing them interacting with the software, prototyping can help highlight major issues on interaction, glitches, and unexpected bugs

Source: “Prototyping in a scrum environment“, CapGemini, Slideshare

You can clearly see, by now, that prototyping and agile methodology is a very complementary and intersectional process. It can even allow you an iteration on every possible version of your design or feature.

The whole point of prototyping is to afford you, the developer, key insights that might have stayed hidden until the “final” version, causing major failures and skyrocketing costs to try and “fix” once a project has gone live.

Source: Unsplash

 

Traditionally, there are various methods of prototyping, for both software and design. As we’ve seen above, some forms of prototyping are more conducive to a particular “stage” in the development process. 

But there are various tools and methods you can use to prototype for apps and software. 

So let’s focus on the trifecta of paper, digital and wireframe prototyping, taking a look at the advantages and disadvantages of all three. 

Paper Prototyping

Perfect for “rapid” or “throwaway” prototyping, paper prototypes are perfect for brainstorm sessions, working well during the early stages. Paper is easily accessible and ideas can simply be placed on a page. Paper prototypes are also quite “lo-fi” — though there is an app out there known as “POP” that turns sketches into interactive iOS and Android prototypes. 

Source: Prototyping On Paper

Simple screens are drawn on paper and configured to mimic a digital interaction, switching the sketches according to user behavior

Advantages

  • It’s fast to get ideas down
  • It’s inexpensive, which is beneficial during the initial planning stages
  • These lo-fi sketches can be used later on as the basis for documentation

Source: Unsplash

Disadvantages

  • At this stage of ideating, you could be gaining false positives, there’s a risk of confirmation bias where your ideas essentially remain untested.
  • Not realistic (yet).
  • Because your paper prototype has no connection with its users, it cannot forecast user flows, it’s not interactive and so there is no sense of anticipating reactions — how do screen transitions work? What is the functionality behind each static drawing? Reactions are missing and this is crucial, especially when approaching development from a user-centric point.

At the end of the day, paper prototyping is only useful for the early stages, when most of a project is still abstract. The further you get into the design process, the bigger the gap between paper prototypes and the final product.

Digital Prototyping

Digital prototypes are the most common form of prototyping and are realistic enough to accurately test most interface elements.

Digital prototypes can be built using apps and software made specifically for prototyping. You can even make simple digital prototypes using presentation software like Powerpoint or Keynote.

Advantages

  • Can incorporate realistic interactions and animated transitions
  • Are extremely flexible: it’s easy to edit, enlarge, refine and share
  • Speed: Paper prototypes have the edge on getting the idea down but digital prototypes with a computerized interface can do more, faster — they can be transferred, marked up and widely shared and distributed

And while speed varies from app to app, most have user-friendly interfaces and features like interactive elements or drag-and-drop.

Source: Unsplash

Disadvantages

  • There is a learning curve: Before you can build your prototype, you’ll need to learn the software. According to the survey results showcased below in the State of Software Development graph, 17.58% of developers say the most limiting factors of new tools are the amount of time it takes to learn it.
  • Transitioning to code: Depending on the software, translating your designs into code can be a hit or miss and incompatible elements might get lost in the transition. At some point, you’ll have to address these and code these from scratch.

Source: The State of Software Development 2018

Wireframes for prototypes

Wireframing software is a kind of digital software or app also made specifically to outline the elements of a new development project. It can be as “hi-fi” or “lo-fi” as you’d like. However, wireframing gives designers and developers the greatest amount of flexibility. 

Using wireframing, you can employ evolutionary prototyping, which is all about building a solid blueprint up front and then constantly refining as the project brings in more user data. 

Wireframes are a graphic structure of a website or app. However, they also include details on transitions, buttons, animation, user flows, features, screens and more. Wireframes can incorporate multiple situations of usage and so they’re perfect for A/B testing. 

It’s a graphic structure of a website or app containing the content and elements.

Source: Axure

As a kind of layout design and a master blueprint, rather like the plans for a house or a building, wireframes have three broad levels:

  • Contains the main information
  • Draws the outline of structure and layout
  • Incorporates the visuals and descriptions of the user interface

Source: Axure

Experiment now or forever hold your peace — that’s what prototyping is supposed to be all about. Prototyping gives both designers and developers the license to ideate, create, test and refine. 

Lather, rinse, repeat because this is when things are allowed to “go wrong”.

Download your free guide for development process in UX driven projects

Share this post

Business Value of Design

wallpaper
Attrecto team

Attrecto team

Business Value of Design

Boosting Your Business Value With the Power of Seamless Design

Companies with a greater emphasis on design seem to win out in every sphere. From revenue to customer satisfaction, greater levels of growth and more predictable long-term sustainability, the power of seamless design is doing more to boost business value right now than any other singular investment. 

It may have something to do with the fact that better design starts with a customer-centric approach and culture. An alignment, in other words, with internal and external priorities. And while numbers don’t necessarily give the whole picture, like scaffolding, they help support decision-makers as they take a closer view into the details of the structure. 

Certainly, that’s what McKinsey’s groundbreaking study on design for better business value shows both shareholders and company executives, allowing us to examine:

  • Why companies with design-led experiences are on the up-and-up in every way
  • What the elements are that are absolutely integral to bringing business value
  • The specific, actionable principles each company can incorporate to experience the promised land of growth-revenue-brand-longevity through something like design that, when it’s working well, is supposed to quietly move into the background 

Let’s take a look.

 

Convergence is Upon Us


Two minutes into a conversation at a networking event, a UX designer who’s asked what his work actually consists of struggles to come up with just one neat little phrase that might cover the breadth of value that design brings to the company’s business. 

If he were doing an AMA session at a conference, he might stay silent and simply pull up this oversized Venn diagram to try and succinctly respond to the question:

Design Disciplines creating business value

Source: Visual.ly

Research by McKinsey reveals a very clear reasoning for incorporating, enhancing and focusing on the way in which design is actually the purveyor of professionalism, productivity, and profits. 

Of 100,000 design actions surveyed from the design practices of 300 publicly listed companies within a five-year period, Mckinsey found that good design equals “superior business performance.”

Known as the “McKinsey Design Index,” top performers were those that showed the greatest improved financial performance, in accordance with four broad design principles. Companies with top-quartile MDI scores outperformed the standard industry benchmark “by as much as two to one.” 

Design focused companies generating more revenue

Source: McKinsey Design Index  

To understand why design is so integral, let’s go back to that Venn diagram. The most obvious takeaway is that the lines are blurred between disciplines, and each intersects and converges — to a greater degree than ever before. 

The reason that companies with specific design practices perform significantly better than their competitors is because:

  • Excellent user interfaces and customer experiences are a standard expectation (with tangible benefits like increased user retention, more targeted marketing budgets, greater levels of profitability due to customer satisfaction and brand loyalty, etc.)
  • There is a major level of convergence going on, not only in the operational “backend” of companies but in the physical and digital worlds (think omnichannel shopping experiences and QR codes), along with a blurring of lines between products and services (think Microsoft’s branch into cloud services, under Satya Nadella, responsible for the greatest profits in Q4 of 2017)

 

Elements of the Design Process Integral to Outstanding Business Results


The design process, in the context of direct financial performance and revenue generation, comes down to four broad but essential components. 

  • Analytical leadership: Being able to implement the software, tools, and technology that measure the drivers of design performance with the same rigor, focus and deliberation as revenues and costs
  • Cross-functional talent: Nurturing teams of designers and developers that work together, along with the structures — like running sprints — that make user-centric design part and parcel of everyone’s focus or job, rather than being siloed to one department
  • Continuous iteration:Making the development process a risk-reduced process by continually listening, testing, and iterating with end-users
  • User experience: Bringing together the disciplines and measurements of physical, digital and service design, especially breaking down the internal or operational walls

We’ve already seen “data-driven” decisions. But what about “design-led decisions” in improving business value? 

This matters now more than ever because of the opportunity that businesses have to tackle their processes from a standpoint of cost-efficiencies, rather than cost-cutting. 

You see, large- to medium-format enterprises can learn a thing or two from the behavior of lean start-ups, which must rely on prototyping and iterative learning in order to keep their development fiscally responsible and sustainable. 

Business value focused design

Image source: Unsplash

Design-led decisions will also become increasingly important as we rely more and more on large swaths of user data and AI as sources of new insights. These advances and technologies will call on new techniques that are themselves guided by design, such as computational design and analytics. 

We’re already seeing that rapid access to a multitude of interactions with real customers means a better ability to reach out at just the right moment, or present just the right offer, and create a conversion.  Now, these interactions are fractured through multiple channels, especially over social media and “smart” mobile devices. 

These pivotal developments are ongoing. Nearly all of them call for the user remaining at the very center of all process and design considerations. But that also means they’ll need to be at the heart of business decisions because user design is driving priorities forward. 

Five Principles of Design-Led Customer Experience


How do we make elements like analytical leadership, cross-functional talent, continuous iteration and user-experience across disciplines guide customer experience? What are the actual practices that businesses looking to enhance their value will need to focus on?

1. Understand the customer’s needs and perspectives

Design is the differential that makes all the difference to the customer. Their delight at novel experiences and their satisfaction derived from an app that not only anticipates their needs but simplifies the process and delivers them the end result they’re looking for — these all translate into a heightened user experience, a preference for the product or service the company offers. 

Every software development or web app development project begins by creating a repository of a customer’s needs and perspectives that come from the goal of the app itself. What needs does the development fulfill?

A customer’s needs and perspectives are not just the starting point. In agile development and design-led customer experience, it’s the guiding principle of all future changes, versions, and patches.

Customer needs focus in business value analysis

Image source: Unsplash

2. Draw inspiration from other industries

While design-led experiences have been in play for a long while now — think, Apple’s obsession with beautiful type and font faces evolving to beautiful user interfaces — the way to stay innovative and question the norms is to draw inspiration from other industries. 

Consider, for example, the nature of “biomimicry.” It’s an approach where designers and engineers look to nature’s most fundamental mechanics — the scales on a fish for protection and light reflection, or the photosynthetic process of plants to understand and “mimic” energy conversion — in order to solve complex human problems through design.

3. Get a glimpse of what’s on the horizon

Because design-led experiences are half experimental and exploratory, half guided by actual customer need to develop a real solution, the resulting solution (in the form of a product, service or even feature) can be creative enough to actually pave the way for a new iteration on an upcoming trend. 

This is also why iterative approaches to design and development are so useful — they harness the power of a collective team, through structures like sprints, in order to find a solution but pave the way for something entirely new. 

4. Empower multidisciplinary teams

Design-led experiences call on the convergence of expertise, of more than one function to build something as robust as an app, enterprise software or an interface. 

There is also a convergence between the physical and digital worlds, as well as products, services, and environments. 

A great example of this is augmented reality, virtual reality, and artificial intelligence. The software “AdMind,” for example, uses predictive analytics and artificial intelligence to manage and deploy more strategic Adwords campaigns.

This convergence calls for an evolution in the way that teams work. Remember that, in order to use design as a boost to business value, it must not be siloed off as a singular department’s priority — instead, it must remain at the fore, with cross-functional teams making it a point of focus in their own respective disciplines. 

Designer team's role in creating business value

Photo credit: Campaign Creators

5. Use agile techniques to prototype experiences and business models

Agile development for an app development company syncs quite effortlessly with design-led customer experience. 

It’s a methodology for development projects that not only empowers teams to work together in an iterative and innovative manner, it’s also a process that puts the user right at the heart of all its actions. 

This iterative approach also offers a better way to incorporate customer feedback and research into the project. It’s never quite the “end” with Agile because development is ongoing. And at the heart of this development must be the user. 

Besides a design-led approach to customer experience, there’s one more thing that McKinsey’s top successful companies have realized: the boundaries between products, services, and environments are necessarily blurred. 

An “integrated” and cross-functional view is not only necessary in order to design valuable end-to-end experiences for customers, but it also gives businesses the competitive advantage they need. 

Convergence is, in fact, completely changing the rules of the game. The best way to keep stable business profits is to bring business value through design that focuses on what the customer needs. 

 

Download your free guide for development process in UX driven projects

Share this post

SCRUM Master vs. Project Manager – Who to hire?

Designer team's role in creating business value
Attrecto team

Attrecto team

SCRUM Master vs. Project Manager – Who to hire?

The Manager and the Master: Choosing Between A Scrum Master and Project Manager

What’s in a name? When it comes to Agile software development, does differentiating between a Scrum master and a project manager really matter?

To be brief, yes, it absolutely matters, and no, they are not the same. 

Understanding the differences between a Scrum master (SM) and a project manager (PM) requires us to clear up a few things first:

  • They might be “similar,” but they’re not interchangeable; Scrum masters and project managers are mutually exclusive
  • One person cannot (and should not) fulfill both roles. 
  • It’s way more than just a title — The “SM” and the “PM” are actually psychologically and professionally conflicting
  • If transitioning from a Waterfall method of development to Agile, don’t expect roles to simply move over in a one-to-one alignment
  • Without a Scrum master formally assigned, management has more of an incentive and ability to veto any optimizations or Agile behaviors that might challenge their vested interests

Source: Unsplash

While both operate from a similar base of knowledge, their roles and functions are different, so their focus and their vested interests are different too. 

To quote Ghostbusters: “Don’t cross the streams!”

Why the mix-up?

Because Agile project management is the noted industry standard today, associated rules, roles, and practices have not only exploded, but they’re being adopted across the board — often, without a sound understanding of the 12 Agile development principles in practice. 

Similarly, the term “Scrum master” has become a buzzword. And it’s not just customers who want to see it in action — plenty of teams are following the trend of instituting a Scrum master. 

But what we want isn’t always what we need.

The new-and-shiny-object syndrome afflicting the Scrum master seems to have left the role of project manager in the dust. Often the latter is now seen as archaic, “old-fashioned,” and constantly at risk of slipping into obscurity. 

But this perception is far from the truth. 

In fact, this “perception” fails to understand the important distinction between the two roles. 

There are moments where only a Scrum master can do what needs to be done, and there are functions that only a project manager should be handling. 

Let’s take a look at what these specific roles are, when teams should rely on each, and what operating in the “zone of genius” for each role really looks like. 

What does a Scrum Master do?

Between the project’s development and the customer’s requirements sits the Scrum master. They are coaches, facilitators, guides, defenders, protectors and nurturers of ideas and processes within the Scrum.  

Within Agile project management, the responsibility of the Scrum master is narrower than the project manager. 

The Scrum master supports the product owner (who is the supervisor and could very well be the project manager as well) by guiding the Scrum process, its proper implementation and the optimization of its benefits. 

As part of a larger team, Scrum masters are responsible for daily standups and the tasks related to this. 

It’s up to the product owner to refresh and maintain the product backlog, which describes the product, its requirements, the customers it is serving and more. 

The Scrum master then handles the operative tasks that respond to the product backlog and these requirements. They also handle the development tasks surrounding the changes in requirements, which naturally evolve as more information comes to light and the project progress and evolves. 

In this support and facilitator position, the Scrum master can help “dodge bullets,” so to speak, keeping developers focused on their main priority: developing and problem-solving to iteratively create the best product they can. 

Source: Unsplash

When the product owner adjusts and re-prioritizes the backlog to fit changes and steer the project, it’s the Scrum master who, working as a ship’s first mate, guides the operation, looking at the project from all angles. 

The ultimate decision-making power, however, rests with the product owner — it’s their responsibility to ensure the project is moving ahead. 

However, when in doubt, and for clarification, they’ll turn to the Scrum master to help answer questions about user experience, deal with issues on functionality, to gain feedback and insight from users and when they feel the need to realign development to fit with business changes. 

If a customer provides a skilled project manager or product owner on their side, then the Scrum master will be someone on the development team who will need to handle these kinds of operative tasks. 

Luckily, the role of the Scrum master is to help this individual understand better how to effectively manage the work of the team using the product owner’s own product backlog, planning, and running review meetings.

What does a project manager do?

You might notice that, while describing the role of the Scrum master, we ended up defining the role of the project manager. Oftentimes, the product owner is the project manager, and they are responsible for communicating with the customers on a daily basis, identifying the concrete development tasks.

The project manager then returns to the development team and must constantly and consistently outline and feed the team with these tasks. 

Decision-making is ultimately (and firmly!) in the hands of the project manager, and they must finalize the feasibility of the development along with the customer, then break it down into concrete and executable tasks for the development team.

Source: Unsplash

It’s also within the project manager’s purview to prioritize these tasks while working with the Scrum master about the deadlines, used and remaining resources (which are, most likely, development hours).

The project manager is responsible for maintaining and running all functions, approval, and task-management related to a project management tool like Jira, Trello, ASANA, etc. They validate change requests (CR) with the customer, having a stronger customer viewpoint (and, thus, a stronger interest) than a Scrum master.

When to choose which?

So how do you know which you need? 

You need a Scrum master if:

  • You have a product owner in-house, and you are breaking down the development into small tasks
  • You are using Agile methodology exclusively
  • Your developers can work without strong supervision

You need a project manager if:

  • You want to give higher authority (e.g., decision making) to a designated person
  • You are using mixed methodology (elements from Agile and Waterfall)
  • You need someone who can maintain your backlog, your task list, and the administration

It should be clear why the two roles cannot cross: They have fundamentally different focuses. To cross them would produce a conflict of interest. Their operations also require vastly different viewpoints. 

Source: Unsplash

The project manager liaises with the customer and the project, actually handling its progression, keeping the customer’s interests and needs in mind. However, the Scrum master must focus singularly on the operations, the “meat and potatoes” of the development process, going between the project manager and the developer team. 

Download your free guide for development process in UX driven projects

Share this post

The truth about the accuracy of software estimations

Programmers working on computer program
Attrecto Team

Attrecto Team

The truth about the accuracy of software estimations

Have you ever heard of a “Standish Chaos Report”? Trust software developers to come up with fantastic terms for an otherwise prescient trend occurring in development projects: the incidence of project failures and the factors that contribute to them.
The failure records of software projects in the United States alone is quite staggering. According to the Chaos Report

  • 31.1% of projects will be cancelled before they ever get completed
  • On average, across small, medium and large enterprises, over half of projects will cost 189% of their original estimates
  • While companies in the U.S. spend more than $250 billion each year on IT application development, spanned across approximately 175,000 projects, only 29% of these are ever counted as “successful
  • Meanwhile, Tricentis estimates that software failures cost the U.S. economy up to $1.7 trillion in financial lossesSource: Chaos Report 2017

The truth is that poor estimation can lead to a score of issues, besides simply a time or cost overrun.
It can lead to changing requirements, poor testing practices, software vulnerabilities, glitches, bugs and overall “challenged” projects doomed to reproduce technical failures if launched merely to meet cost and time budgets but not quality standards.

Source: Software Fail Watch — 5th Edition

In a survey of the negative effects and the “erosion” of value on a brand, Tricentis found that, in 2017, consumer tech companies were most vulnerable, with software challenges spanning everything from cost overruns, failures and recurring bugs.

So why aren’t estimations more aligned with the project’s development and parameters?

If failures are occurring consistently, costing companies more than just money — crossing the boundaries into brand equity and power territory — then why can’t we aim to use better estimation methods on projects?

The Cone of Shame

Dog-owners will know how much their furry friends resent the cone of shame.

Software development and estimations are not too fond of the cone either. In our case, it’s the Cone of Uncertainty that hangs, like a dark specter, looming above the commencement of every single project.

Where there should be enthusiasm and anticipation, there is dread. Even though we’re eager to roll up our sleeves and learn from our “past mistakes,” there’s still an edge of uncertainty when we recast our estimations for projects.

In almost 30 years of software development project studies, expert research has concluded that initial estimates on a project can vary as much as four times more or less because neither the estimating team nor the client can yet fully define the scope of the project right at the outset.

In the “waterfall” method (which is the classic approach to development), the Cone of Uncertainty tracks the variance in these estimate-versus-reality scenarios.

As time progresses, a greater amount of the project reveals itself and the scope narrows — which then trickles down to a tighter estimate and a reduction in uncertainty.

Source: Envoc Glossary

But — you knew there was a “but” coming, right? — can we reduce uncertainty to a greater extent and even earlier in the process? Notice that a “reduction” doesn’t have to be an elimination in order to make the project successful.

There are three specific aspects of software development that the brooding Cone of Uncertainty affects:

Consistently “good” products — Maintaining a product or project’s quality requires a particular standard to be set and achieved in a short period of time. Software projects usually have changing features, according to customer needs, and this calls on either a greater level of agility (towards deployment) or more certainty, earlier on in the project’s development.

The requirements of “custom” built software The Cone of Uncertainty undercuts the amount of foresight and planning that custom software development requires. The latter is more about engineering, where even the foundational building blocks must be custom-built. Integrating these building blocks then initiates multiple possibilities and logical paths to be covered so teams will need to constantly refine these concepts.

The ongoing nature of development  —As the Cone of Uncertainty progresses over time, the variance in estimation versus reality reduces. But using the waterfall method also significantly bloats the time that teams spend in the phases of “What are we building?”, “How does it work?” and “What will it look like?”

So we know what those failures look like — but what about success?

In its survey of IT executive managers, the Standish Group’s “Chaos Report” found that, besides user involvement and executive management support, a “clear statement of requirements” (i.e. scope maturity), tied into proper planning can yield overall consistently successful project results.

Source: Chaos Report 2017

The Cone of Uncertainty, however, seems to make even these success criteria seem less than certain.

How can we hope to have more accurate estimations in an ever-changing environment?

Because the consequence is not only a possible failure or a particularly tricky bug that could, as in the case of Provident Financial, a U.K.-based sub-prime loan company, result in a £1.7 billion loss, the largest one-day share price plummet and a CEO resigning over the fiasco.

Factors Affecting Estimations
Now that we know what failure looks like (and, worse yet, feels like), let’s take a look at the factors that affect the estimations on a project.

Massaging the scope into proper maturity

Scope maturity is tied into estimations on software projects. During the planning phase, the development team will need to finalize requirements and think through the requirements from a few different angles.

But the Cone of Uncertainty almost guarantees that designing and anticipating everything up front is almost an impossibility — especially with proper depth.

So what is the solution?

Favoring the incremental approach helps smooth out the development process, making it much more responsive, shortening the initial phases of variance within the Cone of Uncertainty. That’s because the “responsibility” of accurate estimations is spread over the whole development.

In our own experience with developing a web app that models a Digital Transformation Company’s internal processes, we had two parallel goals: to lay down the foundations of a long-term project and to deliver features within hard deadlines.

The custom solution needed to be the only app/tool the business used for internal researching, analyzing and planning. So we allowed the scope to evolve to maturity along the way, using our automated deploy-and-build process.

This bias for agile development is also what enabled our QA team to provide the best quality code for the client.

Concept elaboration
Estimation accuracy relies on more than just scope maturity — it also calls on the elaboration of the concept.

With custom-designed software projects, there is an opportunity, as with digital transformation projects, to use the principles of continuous and iterative building and deploying in order to mature the project in a way that costs less time and cost up front.

But this also calls on developers to have a firm grasp on the concept or specification up front.

This is one factor in estimations that provides more control than others. Teams will no doubt have to perform sprints and rely on breakout sessions to really get to the heart of the concept.

The details uncovered therein for the requirements on a project — such as problem, solutions, features, technical requirements, marketing requirements, etc. — can help anticipate a more aligned budget.

The point is to get as detailed as possible because details uncovered after tells the development team that an estimation was based on basis of flawed assumptions.

Change requests

You may have noticed by now that time is the wily variable that can bog down or uplift a project. Certainly, development teams are always racing against time to capture the right scope and concept.

It’s a reality our team has come across in our over eight years of development and one that especially pitted us against time during a project for Mitt Telenor’s official iOS and Android app.

If the product is set to launch at a specific date, we need to keep CRs at bay and be transparent with the client about how their ever-changing concept puts their project at risk of running well beyond the estimated project numbers.

CRs may well be warranted — but if they’re not anticipated, as agile SCRUM methodology allowed us to do with Mitt Telenor, the project can quickly become “challenged.”.

Source: Chaos Report 2017

Change requests and re-writing code are tasks that fare best in shorter, more responsive sprints.

In the case of Mitt Telenor, these short sprints are exactly what allowed us to uncover issues at an earlier (and more critical) point in development. This then allowed us to keep the development lights on, so to speak, continuing in a more self-aware (or, rather “software-aware”) manner.

The Place of Estimations in the Agile Methodology
To handle these changes and deliver a successful project, both parties (Client & Developer team) are better off with an agile methodology.

Agile allows us to be incremental, responding to a change in business as well as project needs in a more natural way. It’s also easier and more realistic to estimate and then implement changes in small increments, at closer intervals.

Software development is all about change, by its very nature. It is not now, nor has it ever been, a static undertaking. This is why development cannot employ a templated approach, especially in the landscape of digital transformation.

Source: Envoc Glossary

Notice how the Cone of Uncertainty here is significantly leaned out, from its original bloated physique. The result of a consistent diet and exercise? Not in this case. This is the benefit agile methodology brings to the table.

You’ll notice that we’re not claiming that we can simply eliminate or mitigate the Cone of

Uncertainty — no. To do that, we might as well not embark on a development journey at all.

What agile does allow us to do, however, is to drastically reduce the time spent at the initial stages, those questions of:

  • “What are we building?”,
  • “How does it work?” and,
  • “What will it look like?”

And the rest of our time? Well, instead of hemming and hawing, thinking and scratching our heads, only to come up with shaky estimations that are flawed at best and wrong at worst, we can spend our time in our zone of genius: Development.

Indeed, the “development” zone is where our initial estimates are proven or adjusted, requiring less upfront and overall time, and with greater accuracy.

A more aligned estimate and a smoother planning process.

That’s the advantage of agile

Download your free guide for development process in UX driven projects

Share this post